I thought it about time to start an actual thread for my little pet project to keep people updated on what I'm doing..very slowly. The basic idea was to take Debian Jessie and try to get some upstream packages from Nemo to see if I can get Hildon running on a GTK3 stack, derived from the earlier work on Cordia.

Luckily some Nemo packages still include dpkg rules files, others I've just had to make or update as I went. As for the work inherited from Cordia, initial builds were failing due to a load of deprecaited/removed functions. After much googling I managed to get it to the stage where several component actually built so have gone ahead, very very slowly in trying to bring more of it up to date.

Current status is that hildon-desktop, hildon-home, hildon-status-menu and status-menu-applet-profiles "run" in a amd64 test environment using systemd-nspawn.

For hildon-desktop, you have multiple desktop panning, menu/launcher and task switcher. Menu is lacking blur effect (tidy>mx & clutter 1.20 changes), task preview is cropped (probably an error on my part converting to draw signal) and dialog boxes lack title bar background. Animation code is a nightmare as the replacement to the deprecaited code is depreciated, with the newest API lacking decent examples.

hildon-home is lacking features due to other packages not being available, it pretty much only shows desktop customisation menu with option to change wallpaper and set the number of desktops available.

status-menu-applet-profiles and hildon-status-menu were ported to just test them out. There is a layout issue in the status bar's dropdown menu where it lacks padding around the buttons and no icons due to theme.

libhildon itself is on a bit of a diet. A lot of the code is to put touch support into GTK2 elements, so that isn't needed. HildonPannableArea is still having stuff taken out, literally all it needs over GtkScrolledWindow is a way of tracking its own Gtk{V/H}Adjustments to allow scroll_to and jump_to. There's one function I need to add back in and a lot of unused variable to remove. Some widgets like the calendar that Cordia IIRC removed I may have to reinstate in some form or replace to retain functionality.

Todays work has been to start removing more depreciated clutter code from hildon-desktop, particularly ClutterTexture from hd-clutter-cache replacing with ClutterImage/ClutterContent & GdkPixbuf. This is in preparation of fixing the missing dialog title bar background. Need to rework the reload callback and test further.

Most of the code is in my repos:
https://github.com/android-808?tab=repositories

You need to import a theme manually and setup correct links in theme directory for hildon-desktop to even start at the moment. You may be able with some fiddling be able to use the actual debs but to avoid dependency issues I wouldn't bother at the moment.

Cordia's terminal app is partially ported but no repo yet.

Awesome!
We need more like this-

Quick update.

Not done a great deal coding wise lately, instead I've been looking into the Nemo or Maemo userland idea again. I still want to keep the project so that as little code Hildon wise needs maintaining as possible, using upstream versions wherever it's an option.

Maemo wise, we keep compatibility with our CSSU MCE if we either rely on a binary package for libdevlock (we have headers) or reverse engineer it. On a downside, we would have to rework to use systemd and udev instead of hal and upstart.

Nemo wise, I have dropped StateFS (+Qt depends) as it's not needed by anything at the moment. It also solves FUSE not working with systemd-nspawn because now we don't need it. We wouldn't have to rework for systemd/hal using this but we would have to work out how to use osso-systemui-*-dev packages into the upstream version. Thats going to be next thing for me to look at.

Known Issues:
MCE from Nemo causes timeout on boot. Seems to be a difference in service order between Debian and Nemo, IIRC dbus is started later. As a dirty hack, editing the mce.service file and commenting before:basic.target "cures" it for now.

Had a rubbish time lately at work so haven't wanted to do much at all when I get home. Mix that with Forza, Tomb Raider, too many new TV shows etc. and it explains a lot. The project isn't dead, just reallllyyy sloooowww.

This weeks activities have been focused on looking at future directions, as is the whole plan for this work. In particular this week has been Wayland. If libhybris is going to be the only way we can see Hildon on a future mobile device (Neo900 excluded), what do we need to change? Starting right from the top we can't even make a HildonWindow at the moment (xid, xatom). That's pretty easy to solve but the atoms are how matchbox knows to add window menu symbol to the title bar. Let alone the fact matchbox doesn't obviously support Wayland, but without it the majority of Maemo apps won't function correctly as they won't have a menu or stacked windows! This has led me to wonder what could we do to make libhildon not require window manager hacks? I quite like the idea of extending/ adapting weston's desktop_shell.

GTK3 3.10 introduced two features that I think *could* help the solution, GtkStack and GtkHeaderBar. The basic, non stacked window menus, just add a button to the header bar..done. GtkStackedWindow and friends are a little more involved. We could create a "base" window which just contains a GtkHeaderBar and a GtkStack. We remove the close button in header and replace it with a custom one so we can i) change the icon at will (arrow and cross) and ii) overide the action. The stacked windows would then just be the contents of the GtkStack. If the stack has >1 contents , show the back arrow, if it has 1 or none, show the close symbol and act accordingly. Each stack item can be named so we could listen to visible-child/ visible-child-name and set the main window titlebar or revert to the base window title if there is no name supplied. The menu would need a little work to show/hide button as needed but is doable.

Any thoughts or suggestions would be greatly appreciated.

That being said, I do not plan on abandoning the current hildon-desktop work. I will try to push some updates to git at some stage...honest. I've got several changes ready to upload, just need to commit them when I'm happy. Additionally I realised that as the project is based off the Cordia repo the work doesn't have any of the cssu fixes for the last few years. Libhildon is ok, but hildon-desktop and possibly matchbox, libhildondesktop etc have quite a few fixes not applied, some relevant, some not. I need to go through them at some stage.

Hildon-Desktop: The current repo version of hildon-desktop is missing a few changes in the task switcher that prevents it from working. I will say now before I even upload it that the commit for that is going to be a real mess. Why? That's the part where the clutter API we have in Maemo 5 has been replaced by an API that's been replaced at least once more for which there is very little in the way of working examples. There are 2/3 ways of achieving the same thing but short of reworking the entire file none are a perfect fit at the moment. There's a few samples in place in the code. I've been holding off on commiting anything for this reason but the current repo version is broken and I'm trying to consolidate 3 code bases (my test version, the repo version and a snapshot that I use with ArchLinux on the Eee when travelling) into just 1 to make it easier for me to work with.

LibHildon: HildonPannableArea has more old/unused code removed. There's a few fixes in my test code to replace some calls to stop GTK3.18 warnings.

Hildon-Desktop/ Matchbox: I've been playing with the idea of automatically displaying/hiding cursor based on last known input device. Plenty of examples out there (inc. Cordia). I have one test version but nothing to test it on yet.

Virtualbox: 5.16 requires 3D acceleration option to be disabled. Don't know what was changed but now all window contents are black. Hildon-desktop renders fine, the apps open with the buttons/textboxes etc are there and working but you can't see anything. It's also decided to no longer remember the size of the virtualbox window on each boot.

Strange update today. Dialog window title bars apparently now have correct backgrounds. Strange as AFAIK the code I thought handled the repeating texture (https://github.com/android-808/hildo...tle-bar.c#L295) is commented out. I think it was the changes made to texture cache (https://github.com/android-808/hildo...r-cache.c#L355) that have fixed it. Only noticed today when playing with the profiles dialog.

Few more commits lately. The messy task switcher bits in hildon-desktop have been commited (https://github.com/android-808/hildo...44852af6ef5c56).

For libhildon, it's down to only a handful of warnings on 3.14. There's some fixes for new GTK versions commited and a few more in the pipeline. I need to drop gtk_widget_override_* on newer versions for example. hildon-pannable-area has even more dead code removed (still more left though). The hildon-pannable-area-tuning-example generates a few warnings regarding GtkStock during build and doesn't work. As this is unneeded due to the touchscreen support in GTK3 it will eventually be removed.

hildon-status-menu needs some margin/padding fixes in the drop down menu.

status-menu-applet-profiles needs layout fixes.

Regarding ST: Had a quick look at source files and the ones I checked looked like they would drop in quite nicely. Unfortunately it needs Makefile edits so I tried some of them and managed to get a but further. The real kicker is it needs libmutter-clutter, a specialised version of clutter thats integrated into the mutter source tree. Maybe down the road if Matchbox is replaced with Mutter it would be viable.

Why do you use mce/dsme/etc from Nemo instead the ones from Fremantle CSSU?

The initial reason was to try to offload some of the maintainence of the packages by relying on the work done for Mer/Sailfish. Same reason for trying to use as many stock Debian packages as possible. This is the same reason why some of the translations have been changed. Why track and translate common statements such as Done, Okay, Cancel etc when they are already available in GTK? This is still a WIP so some are done some aren't

The second reason is binary blobs.

As stated earlier, using CSSU MCE would at the moment rely on a binary package for libdevlock (we have headers in CSSU) or we would have to reverse engineer it. Unfortunately I don't know how to do that. I do want to be able to support the CSSU version but I don't want to rely on blobs.

The same is true for osso-systemui. CSSU has packages for the different modules such as osso-systemui-modechange and osso-systemui-modechange-dev at the moment. Although they should all build ok, the modules depend on osso-systemui.

Finally I need to see what the state of libconic0 is.

There is one commit that was purely about getting hildon-desktop to build using Mer userland. All it does, with the exception of the first changed line is comment out or mess with the #defines to remove some of the code. When I get round to it I need to add a configure option for using Mer userland (it will default to Maemo) and then rework the code in the commit so as to support both.

The commit in question is this one. Ignore the stupid #define names, I was probably having a bad/frustrated day.
https://github.com/android-808/hildo...81ea578b43ab13

Yeah, makes sense. On the other hand, how much is Mer/Nemo maintained besides what jolla does?

IIRC I promised to RE systemui. I already did some job, will try to finish it in the incoming days.

Next will come libdevlock, there is 12k .so file and 7k executable, should be easy to have them REed.

Source code is available through maemo repos, though it needs libosso

I have some kind of a "plan" to run CSSU Fremantle hildon-desktop(or something as close as possible) on devuan, unfortunately it seems I can't reuse much of the work in Cordia, as it doesn't seem to keep much (if any) compatibility with Fremantle.

The final goal so far is to have Fremantle CSSU h-d running on a tablet (Allwiner seems to be fit for the purpose), as pointed on wicket's debian thread they have great SDK to build ARM packages. If something working can be shown to devuan maintainers, I hope that we can convince them to make devuan-fremantle a kind of devuan's tablet distro .

However, I would like to have you thoughts on the above - do you think it might work? Do you want to cooperate on that, even if it would mean you'll have to drop part of your work so far?

In terms of Nemo/Mer maintainence, if someone's doing it I haven't got to . Honestly though, it's hard enough to find the time and focus for me to work on this. All my Nemo/Mer components are out of date because they moved all the upstream code off of github and I haven't got round to changing all the upstream locations, pulling in changes etc etc. The other real kicker is that they use bash as the default shell, so a lot of the scripts (eg oneshot) won't work unless they you either install bash as well or edit and maintain all the scripts. The only thing keeping me in current position is the binary blobs.

libosso I think I already have packaged. I think I have both the Maemo and Meego/Mer version. I needed it for one of the header files IIRC.

With regards to the CSSU Fremantle/Devuan idea, how feasible is it to update the Maemo5 componenets? In it's current state (GTK2 version etc), personally, I wouldn't endorse it as a Devuan project purely because of the outdated components in terms of security and not meeting minimum version for a lot of apps. If you can update some of the core components (eg GTK2 version) whilst keeping compatibility with Maemo I think it would be in for a better shot.

It's been a while since I went through the Cordia GTK2 parts, but other than being miles behind now in terms of tracking CSSU, there didn't appear to be much different. I'd stick with CSSU and just merge any desirable patches, much easier than the other way around. IIRC there are some for GLX support that might be worth looking at. I have the fun at some stage of going over all the CSSU updates since the last Cordia update to see what ones are needed. The GTK3 version strips out a lot, like home widgets and file chooser for example.

The version I'm working on has a different .so name for libhildon so it might be possible to install side by side if I rework the installed include directory. That way you might be able to run legacy Maemo5 apps using GTK2+maemo patches whilst using the GTK3 version of hildon-desktop. I may have to give it a go at some stage. If I can get that working it might be a more viable direction, once I clean up that darn Clutter code. Some of the stacking code is just using _NET_WM_.. atoms and the window menu icon is another atom so that should be OK. Just not sure how/if GTK2 window menu would work with the GTK3 window manager.

Whilst I remember, building hildon-desktop without MCE fails, as it is still trying to access the headers. Not sure if it is just Cordia GTK3 derived version or CSSU as well. Thats what got me into the whole Maemo/Nemo/Mer userland mess in the first place.

Oh, seems I was not clear - I don't want to keep hildon-desktop GTK2, rather move to GTK3, whilst keeping the other stuff intact in terms of functionality (as much as possible).

It might be that I am getting lost, but aren't we supposed to use matchbox as WM?

Building mce should be fine, as soon as I RE those 2 missing binary blobs.

So far I have successfully build, in devuan-jessie chroot fremantle:
upstart
dsme
libosso
clutter
libcal
libmatchbox2
mce-dev
icd2-osso-ic-dev
ofc there are lots of warnings re deb compat level etc, but this is easy to be fixed

libhildon fails, but this is to be expected as I am missing the maemo specific patches to GTK.