View Single Post
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#12
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.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post: