Wrote out a reply earlier over 1-1.5hrs and posted but apparently it didn't work.

In terms of functionality, what specific bits do you care about the most? There is a massive commit in Cordia tree that removes deprecated items. As they were deprecated prior to their work I guess they chose to go ahead and remove them. Some of it I agree with, it makes some elements cleaner as a result (hildon-entry), but some of it I may look to reintroduce at some stage. I'm open to any suggestions.

The two parts causing problems I notice straight away are the FileChooser, not customisable unless you edit libgtk AFAIK and GtkCalendar supports displaying week numbers but not clicking to show week view, again AFAIK.

With regards to the code itself, the GTK touch patches are unnecessary and as a result mean a lot of libhildon needs reworking. mov_mode, toolbar editing need to be adapted to start. HildonPannableArea is the best example of how much can be stripped out and leave something that does the same job. If you had access to GtkScrolledWindow animate_to you could remove it completely and have two functions instead. Not even sure if TouchSelector is really needed but it's still in at the moment beacuse it is needed by some apps.

Hildon-Button and derivates also break compatibility as the fullscreen and halfscreen width feature is broken by the new height-for-width/width-for-height implementation.

I will warn that hildon-caption is having one of its broken spells at the moment (segfault). Seems to change everytime something else other than hildon-caption is changed! It needs reworking or replacing for GTK3 with a GtkBuilder ui based implementation as when it does work it only shows the child, not the caption so it is a little pointless.

Finally, hildon as it currently stands looks and feels slightly dated in terms of appearance and features. With GTK3 port I think we should address that where possible.

As the Cordia libhildon tree is IIRC pretty much up to date with the CSSU version, would it not be easier to take my version as a starting point and add the needed functionality back in as required?

I think the first stage should be to work out what functionality you feel needs to be in it. I started this as an experiment to see what is possible so new features or updated old ones are more than welcome. Up till now it has just been about me getting what we have available up and running. I don't have the same skills as you, Pali or some of the other CSSU/Maemo devs. I'm open to suggestions/fixes. I do have one minor request though, although Devuan doesn't use systemd, I want it to be an build option. For those who choose Debian/Arch/Whatever base I don't want them left out.

I tend to refer to the WM as hildon-desktop as we don't actually use the matchbox2 executable, just statically link the library.

My overall approach/thoery is to see where GTK Maemo would go after Fremantle. I refer to it that way here as the Qt introduction and subsequent chain of events in demonstrated by the UI evolution of the Qt/QML path from then on dealt with Harmattan and Sailfish. Same as the Meego switch to RPM instead of DEB (I only really have experience with Debian packaging anyway). My goal is about seeing what the evolution fo the GTK variant is. If they marked features as deprecated, I would like to try to honour that decision where possible. The MB>Mutter switch is part of a possible long term goal based on this but as Wayland doesn't support _NET_WM atoms AFAIK it is currently off the table, hence the St/GtkHeaderBar idea.

Hell, I'm not far off 100% deprecated feature free so maybe GTK4 and a GSK based WM is a future option

Following with interest. Perhaps when libdevlock is REed I'll be able to disable the 'Switch Off Device' popup that comes up on the lock screen and causes my phone to switch off after an alarm, reminder, or (possibly) phone call pops up, causing the lock screen to appear.

Soon after the phone will often switch off (at least once or twice per week for me, normally) when 'Yes' button on the Switch Off Device prompt is clicked somehow while the phone is in my pocket.

Do other people not use the lock device option? Or not experience this?

libmatchbox2: Merged missing CSSU commits.
hildon-home: Realised repo was missing/local not a git repo Started to clean the original patch ready to upload at a later date.
hildon-control-panel: Initial 3.14 port.
status-menu-applet-profiles-gtk3: Initial 3.14 port. Not commited yet, need to confirm something first.

freemangordon: I have a few queries about what your targetting.

• What version of Clutter are you targetting? Nokia 0.8 or upstream 1.x?
• What about components like profiled, iphb that have had work done upstream? My build is still using Mer components at the moment so I have a few packages that using the updated defines contained within them. Profiled has ditched some of the backup code by the looks of it so if that is a real issue, I'll switch back to the Maemo version.

Why not use the one in CSSU?

I'd like to keep as much Maemo (read Nokia) components as possible. The reasoning - all those had been through thorough testing. Not only that, but those were meant to be run on mobile devices, so they had been highly optimized. I am not sure the same applies to the so-called upstream.

I'd like to keep dsme, mce, etc from Maemo - all those have source code available, so I don't see a reason to not use them. At some point "we" can diff Maemo and Mer components to see if there is something in Mer that is worth forward-porting.

Another reason - imagine tomorrow we have all the hildon stack up and running based on Mer components. Great. Only that there will be almost no applications from Maemo repos that can be simply recompiled - they'll need porting to the new API, whatever it is.

(Yes, forward-porting, I assume Maemo CSSU as upstream, not Mer )

libmatchbox2 was originally from Cordia. It should now be the same as CSSU but with GTK3.

hildon-home was started from CSSU zip snapshot, can't remember why, but there was a good reason at the time. It doesn't exist in Cordia AFAIK. The initial work was actually a quilt/patchsys set of patches against Cordia/CSSU before it got to large and just started forking repos.


I can rework what I've got to use Maemo components (mce, dsme etc.), thats not a problem. One commit to undo for hildon-desktop iirc and rebuild other packages. Then I can commit missing package from earlier as well.

Only package thats a little awkward is hildon-desktop due to Cordia/CSSU difference. I'd like to stick to Clutter-1.x as it is still actively maintained and according to http://maemo.org/packages/package_in...-0maemo66+0m5/ only used by hildon-desktop and libmatchbox2.

Whats your view on the deprecated libhildon elements?

Do we have Maemo sources for iphb? I see it was discussed back in 2013 (https://mg.pov.lt/maemo-ssu-irclog/%...01-03.log.html) but the Meego sources didn't match. Wondered if anyone looked at this closer since then.

It is required by libhildondesktop (hd-heartbeat.c) to avoid binary blob.

Libxsp0 is needed by xset770 in osso-af-utils, which is required by osso-af-startup, required by osso-app-killer, required by hildon-control-panel....phew. I don't know what the state of libxsp0 is in regards to building against current X11. http://wiki.maemo.org/Game_development states:

If thats the case, can we remove xset770 and the libxsp requirement?

Additionally anim-shower.c is using gdk2/gvfs etc so needs to be changed for GTK3.

systemui RE is done, now it just needs debian packaging and some testing

ls -al /usr/bin/iphbd
-rwxr-xr-x 1 root root 16628 Jun 7 2010 /usr/bin/iphbd
Nokia-N900:~# ls -al /usr/lib/libiphb.so.0
-rw-r--r-- 1 root root 4808 Jun 7 2010 /usr/lib/libiphb.so.0

shouldn't be hard to get that REed, after I have finished with systemui packaging and libdevlock RE

TBH, I have no idea (even what it is ), but I guess it could be removed now and dealth with if needed later on.

from the wiki, it appears it was used for pixel doubling and tweaking keyboard. unfortunately my first and only Nokia tablet device was the N900.

I'll upload source to my github, remove the related stuff from Makefile and update the anim-shower.c file. I don't have a clue where that's used but it should build without needing to add any depenencies not used by the other GTK3 ports.

https://github.com/community-ssu/osso-systemui

Compile-tested only, I guess it has bugs