Reply
Thread Tools
explit's Avatar
Posts: 592 | Thanked: 1,603 times | Joined on Apr 2010 @ Berlin / Germany
#11
Originally Posted by Android_808 View Post
There's nothing stopping you using some parts of the Mer userland tools and implementing a light weight GUI on top. I'm currently playing with it (repackaged for Debian Jessie) to look at feasibility of updated Maemo/Hildon GTK3.

Mer/Nemo MCE still has a legacy package for LED control etc. statefs is a little bit trickier as it requires Qt5 IIRC so may present a few issues in terms of performance but may actually solve some of the issues in Maemo port (eg xcb).
But you are not allowed to share your repackaged images? (copyright/license issues)
 

The Following User Says Thank You to explit For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#12
Firstly, a correction. StateFS doesn't require Qt. Build depends on some boost libraries but runtime is just fuse. Nemo then have statefs-qt on top.

Most, if not all of the code I have looked at is LGPL so there should be no issue repackaging it as long as I acknowledge upstream. The issue would be branding. If I release I can't call it Nemo/Maemo etc.or use artwork/themes. This is where there is an issue at the moment as some packages can't handle having certain theme elements missing. IIRC it's either the hildon desktop backgrounds or the window decorations. GTK side just falls back to Adwaita so thats ok for now. As one of my aims is to remove some unnecessary hildon specific tweaks, I'm trying to remove hildon-only icons and replace with stock gtk equivalents.

Current setup, as posted elsewhere, is AMD64 Debian Jessie with mce, dsme, libdsme, oneshot and statefs (plus dependancies like cor, check, tut) all repackaged from Nemo. On top of that are my GTK3 variants of matchbox, libhildon, libhildondesktop etc. either derived from Cordia sources or community-ssu.
 

The Following 8 Users Say Thank You to Android_808 For This Useful Post:
Community Council | Posts: 685 | Thanked: 1,235 times | Joined on Sep 2010 @ Mbabane
#13
@Android_808 - would be interesting to know how this panned out in the end, and maybe even sharing some (old?) code
__________________
RX-51
 

The Following 2 Users Say Thank You to sicelo For This Useful 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:
Reply


 
Forum Jump


All times are GMT. The time now is 21:16.