I just tried, and although LXDE can in principle be usable at 480x288, most applications aren't.
But if you scale the desktop by divisor 2 (xrandr --scale 2x2), you get a desktop of 960x576, which is similar to netbooks and on the lower end of being usable.
The display won't be crisp anymore, but it should still be good enough in most situations.

I'm not saying it would be super easy, but given what I have so far I think a h-d GTK3 port would be feasible and would probably be easier in the long run because of the amount of touch work that it is now integrated in upstream GTK (goodbye GTK2 maemo patches!). Its really at the point sometimes where you wonder if its worth keeping some of the Hildon classes/widgets.

HildonPannableArea for example should, as touch is integrated in GtkScrolledWindow, only need hildon_pannable_area_jump_to/scroll_to. It actually needs a little more because we can't directly tell it to animate to a certain point. All the toolbar edit/long press stuff can be simplified (or removed for now ) The smaller libhildon, the less we have to maintain in the long run. If libhildon used CSDs for the app menus instead of h-d you could potentially swap the window manager for anything.

I could be using profiled, mce, etc etc from cssu in my GTK3 work if only I knew how to RE one closed library (libsystemui IIRC). As it is I'm often relying on the Mer/Nemo counterparts/upstream versions and either using the existing Debian packaging rules or churning out my own set. The one problem with this is that then brings in statefs. It's a lovely idea, but Nemo/Sailfish are using Qt, so their solution for modules don't fit with GTK based desktop as nicely. Unfortunately there are a few points in the code for h-d where even attempting to build without mce etc still tries to use it. Fix these and you could theoretically use it as a desktop OS.

I can't say anything about battery life because I haven't tried any of it on a real device yet, only in amd64 Jessie vm.

As far as desktop environments go...
I realize it has been a rough path getting enlightenment to run (but it is very configurable and slick looking)
Past "E"
My best suggestion is wmaker or wm2 for the flexibility of the minimal screen real estate on the n900.
wmaker worked quite well on the n8x0 and I enjoyed using it ...
I'm sure it would suffice for our needs on the n900.
It may not be "pretty" and polished ... but it is very very configurable and very functional for the purpose of the n900...without icons, fonts, etc disappearing on the n900.
I am sure there are other de possibles which would do as well.

As a side note.. obtusely... I have been very pleasantly surprised at the options in antix ...with the (now antiquated) options for de's... just don't find the cool stuff anymore preinstalled.

So, it made create this post: http://talk.maemo.org/showthread.php...64#post1509664

There's really no use in planning right now, when we don't know how many people are willing to work on it. Two people won't work the same way as 10 people. So I'll stray for the in-depth discussion of the technical issues. We need to start from the HR part here.

I changed the OP to reflect the reality: such a project could be
1. a replacement for Maemo 5/MeeGo - for those who need it
2. a real GNU/Linux Maemo-like operating system - for those running Android
3. a mobile OS - for those running GNU/Linux-powered devices
4. a Fremantle like refuge - for the Jolla/Ubuntu users who don't like their OS

The project should be hardware-agnostic.
We should run upstream kernel - if you run upstream kernel, you should have the proper hardware. No further requirements (ok, you can't phone without proper hardware, but it's not the point)

If you mean systemui, I can (and will) RE it, if needed, it is about 25k binary.

Battery life depends on the kernel, in 4.8 we should have all the devices fully supporting PM and deep idle states, there is just a script needed to tell UART to autoidle (just google for it)

It would be a great help down the line.

The replacement osso-* packages in cssu (devlock, tklock, powerkeymenu etc) will need it when I get round to porting them (http://maemo.org/packages/package_in.../0.2.0.18+0m5/).

Rethought things, all the problems raised are completely on topic. Removed that useless comment from posts #1 and #14.

There's still one problem, even if we port h-d to gtk3. Apps.

As of today Debian lacks decent mobile apps. We have many of them, but many of them'll use libhildon+gtk2/qt4.

And if what we create is source-code incompatible with the old Maemo apps... we're screwed.

Besides - the Qt Components. But I'd see this as a second priority.

There is the potential possibility of being able to maintain some gtk2 apps for now by building maemo gtk2 and cssu libhildon.

Don't want to hijack thread by talking more about GTK3 stuff, but a lot of the work porting isn't too bad. Renamed classes/functions, GtkVBox/GtkHBox to GtkBox with orientation param. GtkTable to GtkGrid to avoid depreciation. Clutter is a nightmare along the lines of "Oh! Thats depreciated, use this. Oh, but we've replaced that with this. My bad, that's depreciated as well, use this one no one has got round to using yet".

I'm not as interested in maintaining apps though. As you state GTK mobile apps are few and far between. The stock apps (closed) obviously need replacing. MicroB we all know needs work to replace. If we create pure(r) GTK apps, they might get picked up by other projects. My plan has always been to use as many stock/upstream/standard packages as possible, just maintain our UI and let upstream handle as much of the base as possible.

Qt is a different issue that I'm yet to tackle. My ideas dating back to Qt5 talks were to make an external qt module for the custom classes. You've got the GTK/QT comatibility theme so as long as as much GTK stuff uses stock theme rules (ie not hildon specific) it should be able to use stock Qt5. I also have the souce for qmantle2 floating around for a potential experiment of a Lipstick based WM, and a Hildon UI based on a rework of Marxians componenets. Part of the idea here was that Nokia acquired Qt 18 months prior to Maemo/Moblin merger and used it in Harmattan. If this was the direction that they felt they wanted to take Maemo, maybe I should try to honour that instead.

Ok, I'll start REing it in 2 weeks from now.