I know this has been talked about before (last year iirc), and may get a pandora box result but anyway, imma discuss about this.
This is not going to turn the os into a linuxed version/competition or whatever, it’s bringing apps here which may be wanted for the end users, nothing more nothing less. I would accept both yays and tomatoes to the face :P.
I have been working for the last days on the dependencies of the gtk2 and gtk3 libraries, twinkering with the cairo and pango libraries.
As many of the dependencies were already covered through the depot (many thanks to the porters), it was mostly a try and error process, checking against deprecated and mismatching code for gtk2 and our quite modern glib libraries. As there are no usable backends for us (apart from the X11 compatibility, but without server) in gtk2, i went into the gtk3 route.
I have succesfully ported gtk3 (latest stable version,3.24.1, from Gnome), using the broadway backend, which is just a webserver that receives the data from gtk and renders it to a canvas through cairo. The apps still run “natively”, as all the computation is done on the Haiku OS, but the interface is drawn on a web browser canvas (on Haiku or an external os browser).
It didnt work with the code downloaded from Gnome, as one cairo surface use was done with an invalid pointer, which put me in angry mode, until i found out that the bug was not in my cairo version, nor gtk but the broadway server code (one of those non-checked return values )
Note: this time, code is not cannibalized, it’s mostly as-is, reviewing and fixing functionality
Here is a sample of running the statically linked gtk3-demo demo application in Terminal:
App window in open status (not maximized)
App window maximized
App showing a window popup, pixbuf example:
There are a lot of problems with the gnome theming system dependencies, that you would have too in a linux system without gnome packages installed: icons, themes, setting paths, …
For example, this example requires the fallback theme hicolor for gnome, that you have to download separately and place in one of the 6 paths that gtk3 looks for (asuming that the source code is untouched). For testing purposes, i choosed /boot/home/.icons
Still some failures on the gtk part, some crashes on exit or during functionalities that might need revision. As someone said on this forum, all around GTK is a nightmare.
Logical step would be to remove the dependency of the browser and run the drawing part into a canvas application, that’s launched with the gtk program in use with some library like SDL(like Extrowerk proposed in 2017, a fake xserver/rootless xserver like) .
Draw the cairo surface in a haiku native gui app. As i have not dived yet into the Haiku UI kit, can you have a “blank” window with a cairo surface to draw/receive pixel data?
Modify the step 2 backend to more native widgets, if possible, but having apps running already.
I’m still working on doing out of haikuporter test (aka doing make’s on my own folders), but the experimental recipe may be up soon.
@extrowerk Gtk versions above 3.x require a cairo library that’s satifisfied already by the haikudepot version of cairo (1.14.12) but the recipe doesnt have some packages required for the code to detect cairo-gobject . I have tuned the recipe, based on revision 1 and enabled that feature and it’s available on my github (Cairo-gobject recipe ) for expert review. Since the changes shouldnt affect other packages, can it be updated on the official repo/depot someday?
Also, a newer version of pango (1.41.0) is required for the gtk3 code, so i made a recipe for it too and it’s on my github repo, but it’s not so final as the cairo one, because i might need to compile gobject-introspection and generate a recipe to be used in gtk3 and pango as dependency. Right now, the recipe has a patch to disable it in pango 1.41.0. Could this be updated too in the depots when i check that go-introspection issue?