Ported GTK3 [Live]


#1

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

Broadway example on a Ubuntu (random youtube person)

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

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:

Drawbacks

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.

Further Steps

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.

Recipes

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?


#2

Probably kinda copy what the QT port does (it does setup a canvas using the BeAPI search for proxy in the QT port code) that QT then draws into, its probably a bit different but there should be some ideas there.

You would just give cairo that canvas and pass back through clicks and such back to GTK from the canvas.


#3

Nice job, create a PR for all of the recipes and let we go trough it. You will get help and ideas for sure.


#4

This means one day will have apps like Inkscape? :open_mouth:

This would be a +1 checked on my shopping list to switch to Haiku as my unique OS


#5

Mmmm yes and no. I tried to compile a real app to showcase but apart from gtk3, they have several dependencies that are and are not on the depot (more porting required), so i stopped on the sample already compiled apps.

Also looked on Darktable (read about it on this forum), and I think that once gtk3 recipe is up, and the other dependencies are met (missing ones are one or two libs), it could be run on a browser. Unless some things like file opening fail or so.

I am already working on the recipe so other software can find the libraries and go on compiling :thinking: But found some issues that need to be solved and yadayadayada.


#6

All right people.

Recipes

Cairo recipe with cairo-gobject is up.
Gobject-introspection recipe is up
Pango recipe with updated version is up (needs a fix on recipe to use gobject-introspection, for revision 2, i hope)
Python with recipe config for x86 is up
Gtk-3 2.7(3.24.1) with broadway backed on recipe is UP!

Recipes on my github


Binaries

Gtk3 takes a big chunk of your time to compile (30mins?1hour?), so I prepared a release party pack with all the hpkgs (normal and devel) to play with gtk demo(s).

You should follow Pulkomandy’s recomendation (common sense) of not open/use downloaded binaries from unknown sources of the internet in a blind way, even if that source doesnt stop talking about gtk3. Download and use at your own risk. If you have time and some coffees and haikuports configured, and motivation to solve possible issues and run Haikuporter while life goes on, go for the sources,

Github gtk3 binary release

Manual install order (if required):

  • Cairo
  • Pango
  • Gtk3

Python in x86 is only required for gobject-introspection and GI is only required if gtk3 has introspection enabled (this build has not).

Manually opening the gtk3 hpkgs should trigger the dependencies, and give you a system with binaries like “broadwayd” , “gtk3-demo” and so on.


How to run

Unzip the hicolor theme in your home or where you think that’s safe and move to your home folder then. The final path should look like /boot/home/.icons/hicolor

Failure to install the theme first prevents gtk3 apps to run (it’s the fallback theme).

Start one terminal (x86) and run the command:

broadwayd

This will start the backend for one app. Despite working in port 8080, the log always says 127.0.0.1:9090 (internal server for the apps).

Start another terminal/tab (x86) and run the command:

gtk3-demo

This will launch the native gtk3-demo and connect to the broadway server internally

Open a web browser in your Haiku or another computer and go to Haiku’s ip address at port 8080, where you will see the app running (have fun with the tests!).


#7

Nice job. Wondering if tcl/tk (which is used by Python’s missing modules tkinter and ttk) is missing because of the lack of gtk. Do you know if it somehow related?


#8

Nope. probably because tkinter itself is not ported (tcl is). Not related to Gtk apart from both being toolkits.

But i guess it’s the same as all the graphic libs here, you need a backend, most of the time it’s X11 or so, and would need to be ported to Haiku or the BeAPI or yakyakyakyak…


#9

There is a GCI task about porting an SDL-based version of Tk (apparently also used to provide support on Android). This may help, we’ll see.


#10

I have 2 or 3 experiments on the bag for sdl things. But in any case, having a SDL backend in Android doesnt matter for apps, because they are “always” full screen with OS or hardware keys to change to other activities or apps.

But in Haiku, how would that be done without full screen? We could have a X11 server in SDL but would look “weird” in a black window, where apps are drawn, like having a smaller desktop over normal desktop.

Is that what we’r targetting to achieve?


#11

SDL2 can do multiple native windows.

But in fact, yes, as far as X11 goes, I would make the integration as bad as possible to make sure people don’t want to use it :stuck_out_tongue:

Then make sure GTK is ported with a minimal native backend, setting up BWindows and drawing to them, as it was done for Qt.


#12

Loled here, haha.

I plan to override calls in broadway client code to a native version, so the cairo surfaces are drawn there. Aka fake broadway to not modify all the makefiles above. Let’s see if it goes OK for a revision 2 of the package.