Definitely, too much stuff in those private structs needs to be accessed, esp for GtkTreeView/GtkIconView (but not only), it will become an unmanageable mess at some point if I have to LD_PRELOAD almost all exported GTK functions, while copying all of the GTK code. So we had a discussion with Wizzup and parazyd (the guys that I am expecting to create devuan-maemo repo) and we decided that GTK fork is the only sane option.

The biggest problem I see is with GtkTreeView and GtkIconView code, they are heavily patched in maemo to bring the beauty of those widgets there and to provide touch support. On the other hand it might be that it will be easier in GTK3 as aiui it has touch support already implemented.

Making API incompatible library will somehow make the effort pointless IMO, as there will be no code that will compile without major rewrite. On the other hand it is inevitable because of GTK2/3 incompatibilities. Dunno.

I am not sure I understand what you mean, could you elaborate.

On a side note - I am having very big problems with hildonfm - it turns out I have to rewrite it almost fully to be compatible with gio. What I have done so far is maybe 30% of the needed changes. But...

i'm thinking building libhildon3 and shipping it as an optional file for fremantle-gtk2. Like running a gtk3 app under xfce or any other gtk2 desktop. it should work with gtk2 h-d as it specifies an xatom for matchbox to handle app menu.

This way it can be an optional, experimental component focused on getting gtk3 apps hildonized.

That one was tough https://github.com/fremantle-gtk2/li...8e7b0b69bf4af7

Still lot to do (implement mounts/volumes support, move to GFile from GtkFilePath, implement tracker support, ...), but at least I am on the right track finally

EDIT: add screenshots

Been playing around with some ideas lately, hence no update.

I'm currently working on an idea for a replacement of HildonWindowStack and HildonStackedWindow in a stock build of GTK3, making the functionality free from requiring matchbox/hildon-desktop. I just need a way to change the close icon at the moment. If I remove the default close icon and replace it with a custom button I seem to lose the WM theme based style. I'll post a basic working example when done.

Is this to get Hildon apps running in other environments?

Not sure if this is the right topic to post this, but I wanted to sum up some ideas and experiments I had on running Fremantle UI on relatively modern phones

I used Arch Linux ARM rootfs with custom PKGBUILDs for packages in fremantle-gtk2 repo (I will upload them after some cleaning up if anyone is interested) in chroot under SailfishOS. Arch Linux in part because it was easy to setup and I’m more familiar with its packaging compared to Debian/Devuan, but it shouldn’t be a problem to do the same once Maemo packages for Devuan are built.

Testing under SailfishOS allowed to skip initial boot issues, such as properly starting Android bits, but this isn’t required of course. There is Halium project effort by Plasma Mobile and UBPorts devs which can be useful to built proper distro when needed.

Android uses different graphics stack compared to normal Linux: SurfaceFlinger acts as display server/compositor and talks to Hardware Composer (HWC) API, while gralloc is used for memory buffer allocations. libhybris has the code to provide Wayland integration to Wayland compositor (which then speaks to HWC instead of SurfaceFlinger) and Wayland EGL clients.

hildon-desktop is Xorg compositor/window manager instead and uses clutter, which requires OpenGL (ES) acceleration. The problem is that there is no intergration provided for X server windowing platform in libhybris. There are some ways to workaround that.

• Using native graphics drivers
  Qualcomm SoC devices: there is open-source driver for Adreno graphics found in Qualcomm SoCs - Freedreno. It should work just fine for Xorg OpenGL acceleration, but it requires either using fairly new mainline kernel (isn’t the case with Android devices) or backporting DRM subsystem to older one. It’s mostly used with Qualcomm development boards, such as DragonBoard. The only phone there were efforts to get it working with is Nexus 4, which is old by now.
  
  MediaTek SoC devices: most MediaTek SoCs come with Mali graphics, which provide Linux userspace binaries, but it seems they need to be built for each specific SoC and only silicon manufacturers have license to Mali DDK for that.
  
  There are also some SoCs with PowerVR graphics and lately they appeared in Chromebooks with mainline kernel support for DRM/modesetting, but this can’t be easily backported to phone SoCs either.
  
• Adding X server platform integration to libhybris
  It should be doable to add X server integration as EGL windowing system in libhybris the way it was done for Wayland compositors/client, but I’m not familar enough with Xorg architecture to understand how to do it right. I tried doing it based on the idea/code for Raspberry Pi, which involves offscreen rendering and using XPutImage/XShmPutImage to output result. While don’t need to use glReadPixels(), since gralloc provides access to graphics memory buffer, it’s still slower than it needs to be and involves doing extra copies. My implementation in libhybris works as proof-of-concept, but seems to suffer from race conditions and surely can be improved.
  
  I wonder if there is an easy way to assotiate XPixmap with arbitrary value (gralloc buffer handle) and modify Xorg server to access pixmap data through it when available (via some kind of extension?). This way extra copies could be avoided.
  
• Partially using Wayland
  Proper wayland integration would require moving to GTK+ 3 (GTK+ 2 apps don’t support Wayland, but can be launched via XWayland integration) and either rewrite of hildon-desktop to act as display server/Wayland compositor, or using different compositor/window manager, such as Mutter from GNOME Shell or KWin.
  
  Instead I tried to make a hack of xlib Cogl windowing system integration to make it connect both to X server and Wayland compositor. This way hildon-desktop can still act as X (Xwayland in this case) compositor, but OpenGL will render to Wayland compositor and be overlayed on top of Xwayland output (I modified QtWayland example to act as such compositor).
  
  It works fastest on devices I could test (Xiaomi Redmi Note 2, OnePlus 2, Moto Z Play), but is pretty quirky to say the least. Screen capture by X server apps won’t work, unless it’s mixed with previous approach, and I’m not sure what to do with other X server clients using OpenGL, unless they also run fullscreen.

I tried to cover only graphics for now. Other subsystems adaptations could be probably reused from SailfishOS/UBPorts, since they bind Android drivers to pretty standard Linux components (for example ofono/telepathy-ring for telephony, PulseAudio, gstreamer for hardware decoding/camera access).

some update http://46.249.74.23/devuan/out-1.ogv

still stuff to be done (esp in tklock), but ...

After fmg/my experiments with GtkModule didn't work out, in my case due to public/private API/member access, I decided to take a step back and look at other solutions. As it stands at the moment, in terms of GTK3 support, I think the best plan would be to go down the Cordia based route I started with but get it running on top of fmg's Fremantle-GTK2 port. It should provide enough basic features to allow some GTK3 apps to be Hildonized. The plan would be to use it as a transition to convert some Hildon code to stock GTK. At the moment work on this side is on hold until I can sit down and get a working Fremantle-GTK2 environment up and running.

My other project was, as you said, to move away from requiring hildon-desktop for a future libHildon applications. Elements like stacked windows and menus are the main parts I am looking at. Taking my GTK3 port, it will run under XFCE for example but features are broken. This experiment was looking at replacing HildonStackedWindow and related functionality with a GtkWindow featuring a GtkStack. After fighting few issues (pop 2 windows and it showed window @ 0 instead of the top of the stack, tracking actual stack size) I did get it to a point where it was almost what I wanted. The problem is the close button. You can listen for close button messages and pop windows until you have only one where you actually close but you can't change the icon as it is themed by the window manager. Next option was to hide default button and use your own, but you can't make use of window manager close icon on your button. Third option is to make a variant using both wm and a GTK button and show/hide the relevant one. It's a messy solution. This was going to form part of a Hildon/Weston-based Wayland experiment.

Just checked out the video. Looking good so far.

Sorry for not being as active lately. A combination of frustration with code and the still on going medical issue have meant I've not been spending as much time working on any side projects. Still not 100% convinced with diagnosis but at least I know its nothing major.

Anyway, I've cleaned up some of the work I started on an idea for a HildonWindow/ HildonStackedWindow replacement. The basic idea is to replace the vbox in the original HildonWindow with a GtkStack. It has a set of callback functions listening for items added to or removed from the stack. On adding a single item to the stack it will react just like a plain old window. Instead of having lots of HildonStackedWindows we could just add the contents to a container and add that to the GtkStack. There are some notes within the hildon-window.c source file. On compilation it will produced a tut_prog file in the hildon folder. You can run this to see a quick example. I am definately not great with Makefiles so for some reason it is now appearing as a shared library when last time it built it was an executable...with no changes??

Going forward, the Hildon menu code that currently depends on hildon-desktop and X11 could be replaced with a standard menu item in the GtkHeaderBar. What about for stacked windows? Maybe the HildonStackedWindow could become a container class, say HildonStackedContent. You could assign a menu to the container through hildon_stacked_content_set_menu. On changing the stack contents, you could check if a menu is present and display as necessary.

I don't think any of this will work correctly under the existing hildon-desktop due to the way that GtkHeaderBar is drawn (it ends up under the status area iirc). You can force it to render the window manager title bar and it should display correctly at the top and draw the GtkHeaderBar underneath, but you'd lose lots of space. The real purpose of this test was to try getting the stacked window concept working without hildon-desktop and without relying on directly using X11 functions.

Sorry if the explanation is a little confusing. It's been a while since I started this.

I believe this is the same reason why current Gnome apps use client-side window decorations with Gnome Shell: basically the app then can decide how to render its menu, what to draw on its title bar, etc.

Yeah. By moving the menu code client-side I wouldn't have to worry about requiring hildon-desktop and avoid using X11 code within libhildon itself. I can't remember the env variable off the top of my head to force it to draw server-side decorations to possibly fix the overlap issue. On a desktop it wouldn't be an issue but on something like the N900 screen size is limited already.