View Single Post
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#14
@sicelo - This was the basis of my very first attempt at porting Hildon to GTK3. I wanted to implement it on to the current (at the time) Debian version so as to reduce the amount of package maintenance by relying more on upstream Debian. The GTK work on Hildon started based on Cordia version by Smoku, where he chose to remove anything that has been marked as deprecated in Fremantle.

The Mer/Sailfish userland tools were used to meet the dependencies but rebuilt and repackaged as Debs rather than rpm. This was for the same reason as sticking to Debian, make use of upstream more. For some packages it was a straight build as the Debian packaging still existed in the git repo or could be copied from a previously commit. Any dependency not from Mer/Sailfish/Debian was pulled from the last commit for Maemo or Meego.

This did bring some new packages like cor and tut that were no trouble. Updated MCE, DSME and Statefs were a bit more work. One would build easy but then get stuck during boot until you worked out another piece of the jigsaw. I remember at one point one failing at boot and having to wait until it timed out and skipped every time trying to work out a solution.

Development was done in a Debian image with Xfce using VirtualBox. I can't remember exactly but I think I must of then done a minimal debootstrap into a folder and then used nspawn to get a somewhat scratchbox style build environment. GUI was tested using Xephyr to start with, as you would with scratchbox. When it got further, the folder containing the "install" I think was shared via NFS so that Qemu could use test a "proper" boot.

Work stopped when I started another version using my GTK3 work from above but with Maemo userland and systemd. Freemangordon worked with the same GTK3 code but sticking to Upstart. This too was benched when we both started a GTK3 port that retained the deprecated code from Fremantle and both used Upstart. I can't remember why but I think we had issues with some code that relied on the modified gtk in Maemo. I think it was something that's private that gets patched to allow access in the input classes. There was also the Clutter changes.

Work switched to building an updated GTK2 version, I think originally without modified GTK2. Later fmg switched to latest GTK2 with patches. I think this is now in Leste.

Some of the code from Mer version is on GitHub. It didn't get a lot of testing/checking though. It's more a proof of concept of what at time (pre Leste) could have been an option for Maemo. I started it thinking next Maemo could be a simple GTK3 port and retain GTK2 for legecy apps. I wanted to use as much upstream resources for development and maintenance so as to reduce work for Maemo team.

I have a few ideas floating around and some sitting on a drive waiting for me to continue them (libretro frontend based on DrNokSnes UI) but I'm struggling with enthusiasm at the moment. I get annoyed when I get stuck and put off working on it.

Last edited by Android_808; 2021-04-19 at 08:12.
 

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