Hello, author here. This was discussed here on Lobsters a few months back; at that time, GTK started but it was nowhere near ready for production use. Since then, it has matured quite a lot, and now both it and the GTK3 port based on it are in the default Haiku package repositories, along with GIMP, Inkscape, and an increasing number of GTK applications.
This work was mostly done as part of my ongoing development contract with Haiku, Inc., so if you find this and the other work I’ve been doing in and around Haiku the past half-year fascinating, please consider donating (or even set up a recurring donation) :)
Internals are another matter, we don’t have a lot of documentation for that unfortunately (we try to follow “the code is its own documentation” but of course that doesn’t always work out.) I can try to answer whatever questions you might have about that or point you to the source for more details.
Thanks! I was really only after a very rough overview because I know literally nothing about it. Like, does the interface or implementationit resemble Wayland or X11 or Win32 GDI or a raw framebuffer or anything else a reader might be familiar with? :)
Like, does the interface or implementationit resemble Wayland or X11 or Win32 GDI or a raw framebuffer or anything else a reader might be familiar with?
The interface, being a standard “widget-based” user interface toolkit written in C++ has some similarities to Qt or maybe gtkmm, but of course it is heavily tied to one platform and thus makes use of OS features (the Be/Haiku IPC ports and messages system, area-based shared memory, etc. etc.)
It also has some significant differences with other “high level” toolkits in that it’s simultaneously a “high level” toolkit (like Qt or GTK) and a “low level” toolkit (like Xlib or Wayland) at once, because there’s nothing else below it like Wayland or X11 below Qt or GTK even on Linux, so there are options and flags that can be used which most other toolkits do not bother exposing or don’t support at all.
The other thing is multithreading – some toolkits allow it loosely, some disallow it altogether, but on BeOS and Haiku, multithreading is mandatory; each window gets is own thread, and its own communication ports to the display server. All rendering occurs server-side, which makes it a bit like “classic” X11, but only rendering (control layouts, resizing, etc. are computed on the client side.)
You can, of course, just request a shared-memory bitmap buffer and copy pixels into that and make a window’s contents be just the bitmap, which ported toolkits like Qt that want to draw things themselves do.
Not to disparage the effort, but I’m curious why the author has chosen to implement an X11 compatibility layer and not a Wayland one, since X is rapidly approaching obsolescence in the Linux space.
Hello, author here. This was discussed here on Lobsters a few months back; at that time, GTK started but it was nowhere near ready for production use. Since then, it has matured quite a lot, and now both it and the GTK3 port based on it are in the default Haiku package repositories, along with GIMP, Inkscape, and an increasing number of GTK applications.
This work was mostly done as part of my ongoing development contract with Haiku, Inc., so if you find this and the other work I’ve been doing in and around Haiku the past half-year fascinating, please consider donating (or even set up a recurring donation) :)
that’s awesome
I’m curious about what the graphics layer in Haiku (and BeOS, since I assume they’re real similar) looks like.
Do you mean API, or internals?
You can read the old Be Book (https://www.haiku-os.org/legacy-docs/bebook/TheInterfaceKit_Overview.html) for a basic overview of the API, which indeed Haiku has all of (and then extended with more controls and drawing modes, some of which are documented in the newer API docs: https://www.haiku-os.org/docs/api/)
Internals are another matter, we don’t have a lot of documentation for that unfortunately (we try to follow “the code is its own documentation” but of course that doesn’t always work out.) I can try to answer whatever questions you might have about that or point you to the source for more details.
Yes. ;)
Thanks! I was really only after a very rough overview because I know literally nothing about it. Like, does the interface or implementationit resemble Wayland or X11 or Win32 GDI or a raw framebuffer or anything else a reader might be familiar with? :)
The interface, being a standard “widget-based” user interface toolkit written in C++ has some similarities to Qt or maybe gtkmm, but of course it is heavily tied to one platform and thus makes use of OS features (the Be/Haiku IPC ports and messages system, area-based shared memory, etc. etc.)
It also has some significant differences with other “high level” toolkits in that it’s simultaneously a “high level” toolkit (like Qt or GTK) and a “low level” toolkit (like Xlib or Wayland) at once, because there’s nothing else below it like Wayland or X11 below Qt or GTK even on Linux, so there are options and flags that can be used which most other toolkits do not bother exposing or don’t support at all.
The other thing is multithreading – some toolkits allow it loosely, some disallow it altogether, but on BeOS and Haiku, multithreading is mandatory; each window gets is own thread, and its own communication ports to the display server. All rendering occurs server-side, which makes it a bit like “classic” X11, but only rendering (control layouts, resizing, etc. are computed on the client side.)
You can, of course, just request a shared-memory bitmap buffer and copy pixels into that and make a window’s contents be just the bitmap, which ported toolkits like Qt that want to draw things themselves do.
Thanks, this is awesome to read, and I’m not even the person that asked the question(thanks to the question asker too!).
Thank you
Not to disparage the effort, but I’m curious why the author has chosen to implement an X11 compatibility layer and not a Wayland one, since X is rapidly approaching obsolescence in the Linux space.
This is said a lot, but it isn’t really true.
But it should be. X is …… old. It should be resting.
Linux is only about seven years younger than X. I guess it must be approaching obsolescence too.
For that matter, I was released in 1986….. oh dear, I don’t think my retirement account is ready for that :(
Personally I can’t believe lobster.rs is served primarily via TCP and UDP. They are 42 years old and should be put to rest.
</s>
You’re right. We should be using SCTP instead.
The author explained this here.
Even if Wayland does finally replace Xorg for Linux users, it doesn’t necessarily mean people will stop wanting to run X11 applications.
X was obsolete, full stop, a decade or two ago. Whether or not a thing is obsolete has little to do with how ubiquitous or useful it is.