[WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

Awesome!
We need more like this-

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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

Re: [WIP] Fremantle GTK3 Experiment
 

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

Re: [WIP] Fremantle GTK3 Experiment
 

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?

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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 :p

Re: [WIP] Fremantle GTK3 Experiment
 

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?

Re: [WIP] Fremantle GTK3 Experiment
 

libmatchbox2: Merged missing CSSU commits.
hildon-home: Realised repo was missing/local not a git repo :o 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.

Re: [WIP] Fremantle GTK3 Experiment
 

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 :) )

Re: [WIP] Fremantle GTK3 Experiment
 

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?

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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

Re: [WIP] Fremantle GTK3 Experiment
 

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

Re: [WIP] Fremantle GTK3 Experiment
 

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.

Re: [WIP] Fremantle GTK3 Experiment
 

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

Compile-tested only, I guess it has bugs

Re: [WIP] Fremantle GTK3 Experiment
 

after the latest commits, it seems we have fully working REed systemui

Re: [WIP] Fremantle GTK3 Experiment
 

and libdevlock

https://github.com/community-ssu/libdevlock

Re: [WIP] Fremantle GTK3 Experiment
 

@Android_808 - ok, what now?

Re: [WIP] Fremantle GTK3 Experiment
 

I think the only other blob that comes to mind is iphb for libhildondesktop. This was mentioned by someone a few years ago in irc chat. If I remember the sources I'm using at the moment (Mer) are not the same. Think it was something about merging bits with dsme IIRC.

Hildon-desktop, if you are still using libclutter0.8 needs libcail (Clutter Accessibility Implementation Library). Newer versions of clutter seem to have integrated ATK support via cally.

mce I think should be blob free now. It only wants the osso-systemui-...-dev packages for the dbus signals etc. I think we already most if not all of them and the actual modules/UI elements in CSSU. I think you said we had libconic sources somewhere.

BTW, CSSU repo is missing libhildondesktop from what I can see. Source is definately available because Cordia and my repo have it.

After addressing iphb I think I should be able to build hildon-desktop using Maemo userland with no binary blobs. For you, it would depend on what version of clutter you're targetting.

Had to take a week off from coding/project. Way to many hours at work the last few weeks. Worked out I've had 6 days leave so far since January :( Got some time off later this week but have family plans. End of next week and especially all the week after I should finally have some more free time again.

Re: [WIP] Fremantle GTK3 Experiment
 

https://github.com/community-ssu/iphbd

daemon is yet to be REed, but library should be enough for building.

I wonder if I can use cally as a drop-in replacement of cail.

http://repository.maemo.org/pool/fre...libc/libconic/

That means there was no need to change/fix it. Use the one from the repos.

Great. Lets see how your (clutter1.0) h-d is going to behave, I may give up on 0.8.

Sure, anyway I'll need some more time to RE iphbd binary.

Re: [WIP] Fremantle GTK3 Experiment
 

great news. i think libiphb should be enough.

h-d clutter 1.x still needs cssu fixes assessed and merged. might be easier in the long run to take cssu version and merge clutter1 code into that. on the whole it is "working" ok atm.

it has an issue with window thumbnail not being correctly drawn inside container, probably just a coordinate issue as it leaves a transparent bar.

the other issue is switching between window/switcher too fast causes xwindow/client disconnect. theres a similar issue documented in the source file. iirc you can't use source as it was in 0.8 due to deprecated/removed features. it crashed to start, after a few fixes it would display but not react to events and is now in its almost working state.

as for cail to cally, I'm not too sure. if cally is in 0.8 i don't see why not. just not sure how they compare feature wise.

i was hoping to get some time before then but got hit by another bombshell when i got to work. someone goes on to maternity friday and none of her shifts are covered. as one of the only people on site who can do her job, guess who they want to come in earlier and on days off to cover.

Re: [WIP] Fremantle GTK3 Experiment
 

Ok, small progress made.

iphb built fine. libhildondesktop rebuilt against "new" version.

libdevlock: build fails if libcal.pc is missing. Compared to original, the CSSU RE'd version appears to be missing libcal related depends and build-deps.
After installing libcal-dev and libcal1:

Turns out that CSSU libcal is missing dh_makeshlibs call in rules (currently commented out).

Re: [WIP] Fremantle GTK3 Experiment
 

osso-systemui: I'm hitting conflicting type errors. DBus8ByteStruct and DBusBasicValue defined in systemui.h are already defined in dbus-types.h.

osso-systemui-powerkeymenu: Needs GTK3 port. Set up a repo ready to work on when I get some time.

Re: [WIP] Fremantle GTK3 Experiment
 

Sorry, I forgot to push https://github.com/community-ssu/oss...f9f45fea2c6606 :(

just pull and rebuild, it should be ok now

Re: [WIP] Fremantle GTK3 Experiment
 

Will fix that.

Re: [WIP] Fremantle GTK3 Experiment
 

thanks. didn't have much time to look into it yesterday.

I think i just need to rebuild dsme and libdsme, then build osso-systemui, libconic and then i can replace mce. then i just need to revert the hildon-desktop mer hack commit. i might have a play with dsme and mce to see if i can add optional support for systemd as mentioned earlier.

i have also freed up some space on the laptop for another build. as my working version is built on amd64 jessie, i'm going to set up x86 stretch to test for issues going forward and give me a way to work on ports when away from home.

Re: [WIP] Fremantle GTK3 Experiment
 

iphbd is fully REed and mostly tested, make sure to pull before playing further as there were some fixes in libiphbd0

https://github.com/community-ssu/iphbd

Re: [WIP] Fremantle GTK3 Experiment
 

iphbd built fine.

Did you have any issues with libdsme-0.60.30+0m5?

I'm getting the following error message. It's an autogenerated file. The line in question in the .depends file is "-e ", the first of two. It almost looks like it is writing the param from the echo statement from lines 232-246 from Rules.make.

.depends content, lines 154-160(EOF):

Re: [WIP] Fremantle GTK3 Experiment
 

yes, dash echo doesn't understand -e echo parameter :(.

I had to edit rules.make file and remove "-e" from all the echos

EDIT:
it seems we can workaround that by using /bin/echo, something like

if [-x /bin/echo]
ECHO=/bin/echo
else
ECHO=echo
fi

(I am not very good at scripts, but I guess you get the idea)

Re: [WIP] Fremantle GTK3 Experiment
 

yeah. I tried it that way earlier with some success. A lot of consensus is to replace echo with printf. My initial attempt to do this though caused the .a and .so sections to have no contents after the library name.

Funny thing is it seems to work ok on 1 of the 3 lines. I'll play with this a bit in the future but for now just want to get compiled and running. x86 stretch image is ready to start building packages so i'll try to pull some repos in the morning to build whilst out tomorrow.

Re: [WIP] Fremantle GTK3 Experiment
 

Apparently further from maemo mce support that I thought.

osso-systemui failing at the moment. The Cordia based libhildon has removed some HildonBanner related code for hildon_banner_show_information and hildon_banner_set_timeout. The later should still be achievable via setting property, but the first requires code to be reinstated or changed.

Several other packages (osso-systemui-powerkeymenu, osso-systemui-tklock to name but 2) require GTK3 port.

Every time you think your getting closer you find more packages, depending on more packages.

osso-systemui-tklock requires libalarm-dev (have sources) which requires libtime-dev (libtime0 is AFAIK another blob).

Finished setting up Stretch container this morning and pulled in a few repos to start building whilst I was out. It's not as straight forward building packages as it is for Jessie, but that has been my target environment for a while.

Maemo/Stretch Related Issues:
General:
gtkdoc-mktmpl (or similar) deprecated. Used in libhildon and libhildondesktop.

Packages:
icd2-osso-ic-dev: change compat 4>5

libcal: already reported, uncomment dh_mkshlibs or whatever its called in rules.

libconic: #if !GLIB_CHECK_VERSION(2,36,0) g_type_init(); #endif needed in test-*.c
change compat 4>5

libdsme0.2.0: change compat 4>5

libhildondesktop: gdk_window_set_background_rgba deprecated. Add CFLAGS+= -Wno-deprecated-declarations. Function removed from GTK as of ~16th Oct 2016

libosso: 4>5

libosso1-dbg: missing /usr/lib/debug/*.so*. Temporarily renamed libosso1-dbg.install

mce-dev: change compat 4>5

osso-systemui-dbus-dev: compat 4>5

profiled: change compat 4>5

Re: [WIP] Fremantle GTK3 Experiment
 

ok, going to RE clockd/libtime0

Re: [WIP] Fremantle GTK3 Experiment
 

My bad, it does exist. osso-systemui's dbus.c has WITH_HILDON include before including config.h. From what I can tell, the configure sequence is detecting hildon so is not running the check for gtk3 the check for it will only be run if hildon is not found.

This isn't something I'm confident on dealing with but I think it should be like this:

That gets it a bit further, but we then hit libcanberra DSO errors. $(CANBERRA_CFLAGS) and $(CANBERRA_LIBS) are missing from src/Makefile.am

Finally, -ldl appears to be missing from the same Makefile.am.

I don't know if the lib changes are exclusive to GTK3 or not at the moment.

Re: [WIP] Fremantle GTK3 Experiment
 

Oh, I see, my bad, sorry about it.

Right, this should be fixed.

Please clone systemui repo on github, do the required modifications and request back a merge. I am first to confess I don't feel comfortable with automake spaghetti.

I'd like to keep one and the same code for both CSSU and hildon-gtk3 as much as possible - it really doesn't make sense to make forks for hildon-gtk3 when a couple of #ifdefs will do the job. Esp if we have a cooperative package maintainer to deal with (myself) :)

Re: [WIP] Fremantle GTK3 Experiment
 

I was thinking about this earlier. How do we manage the gtk2-dev/gtk3-dev dependency in the control file? The trouble with that is you could then end up trying to build with gtk2 headers and gtk3 hildon. Not sure if Debian control has a & option. If not it might be a case of dynamically generation the control file.

It will get a bit messy when it comes to libhildon and the rest of them because of the size of the code base compared to osso-* libraries.

The automake spaghetti is above me. I just took a guess based on a few quick google results. For the missing libraries, would it be useful to try using pkg-config to pull them in as needed?

With regards to the Jessie port, osso-systemui is built. I had to go back to osso-af-utils and make a few hacks to anim-shower to bypass some outdated code. I'm not sure where/if the executable is used so it might come back to haunt me later.

Finally for today, upstart-dev. It doesn't exist in Debian, we have libupstart-dev. The Maemo version has dh_installxsession in it which is needed to finish building the rest of the osso-* pieces before I can install them. I need to look into how best to go about this, whether to just package the needed files


I have to be totally honest, using Mer userland seems sooo much easier :)