pcb-rnd knowledge pool
HID: the future of GTK and other HIDs
| hid_gtk by Tibor 'Igor2' Palinkas on 2019-03-15 | Tags: insight, hid, policy, gtk, gt3, gtk4 |
Abstract: A major problem with the GTK lib is that it is huge and is changing a lot, in ways we don't really need. This article describes our strategy on GTK versions and alternatives. It also discusses the possibility and practical requirements for more HIDs to happen.
Imported from the mailing list archives.
For a project like pcb-rnd, keeping up with new versions of GTK is rather expensive. We spend a year or more to be compatible with a new version (e.g. GTK3), but then in 5..8 years we have to start over (e.g. for GTK4). Not because we need any of the new features the newer GTK version offers, only because of the "trends" or because of the fear of the older version getting no support from distributions.
In return: GTK is huge, slow, requires glib and C99 and is not easy to port. For example technically speaking GTK cross compilation breakage is the only reason we don't have a working windows port - of course our target audience is not on windows, so there's no much motivation either, but last time I cross compiled pcb-rnd, only GTK broke.
TL;DR: I think GTK is generally an unsustainable technology.
Up to this point, we were experimenting with GTK3. But in practice it didn't result in production quality HID. Because of the above theoretical reasons plus that I do not want to loose too much time on features of minor importance (GUI eye candy), I finally made the following decisions:
- we keep maintaining the lesstif and GTK2 HIDs, independently of whether/when popular Linux distros stop supporting GTK2 and motif, to make sure pcb-rnd works on old systems
- [del]we keep GTK3+cairo HID as an experimental plugin, but it will not be officially advertised. It will not get configured automatically, it will not be listed in the documentation and we will recommend against using it. As long as it gets enough maintenance it will be possible to use it when explicitly configured.[/del] The main problem with GTK3+cairo was rendering speed, and that could not be improve (cairo is just too much overhead). As of August 2019, hid_gtk3_cairo has retired.
- I finally pronounced the GTK3+gl effort dead, I have removed that plugin. It doesn't work, so don't worry, we did not lose features
-
once I finish the HID API cleanup (hopefully this year), our HID API
will be much simpler and implementing a new HID will become a much smaller
task than ever before. In fact it will be reduced to:
- a generic menu system engine (menus filled in by core)
- rendering engine (driven by core)
- input (pass over to core)
- DAD dialogs engine (actual dialog boxes created and maintained elsewhere)
- a file selection dialog and a few smallish utilities (file watch, beep, etc.)
- I will definitely implement an SDL based HID. I wanted to do that since about 2010. I used SDL in a few projects already; compared to GTK it's very small, very fast, and very portable. Looking at the project history, it's also very stable: libsdl1.2, first released late 1990's, is still accessible in major Linux distributions. Which suggests if we write sdl2 code today, that has a good chance to run in 2035 without a rewrite for sdl3.
- we are considering implementing other HIDs too, more on this later, when we get those project started
- if a newer GTK version is very important for someone, he will need to volunteer to write a GTK4+gl HID. This requires serious dedication: the candidate really needs to be able to spend at least 8 hours a week on this and fully accept pcb-rnd's HID policy (which does include that we are not writing a GNOME application but just one more HID to a modular multi-HID pcb-rnd). I said GTK4 because I don't see the point in investing much time in a new GTK3 effort if then we will need to redo it for GTK4 a few years later. I said gl, because cairo already proved to be too slow (even on the scale of software renderings) and GTK versions from 3 don't seem to provide a simpler sw render, even a single pixel is drawn through cairo.
- ... but I don't mind if a GTK4 HID (or GTK5 or GTK N HID) won't happen at all - I believe long term we should settle with more sustainable alternatives.
- ... especially with their great idea to solidify API instability of gtk3 and turn it officially into the normal development method. I mean scheduled API break every 6 months while not being able to install and use 2 versions from source in parallel? Really, for a lib whose main task is drawing buttons? They propose that 3rd party applications can stick to a specific version and that version will be shipped by distributions forever. Good then, pcb-rnd has picked a version: gtk2.
- Qt: not possible, as we won't support a C++-only lib
- athena widgets, tk, fltk, native win32 and other toolkits: if there is a developer with considerable dedication and full acceptance of pcb-rnd values, we can go for it. Please request them only if you have the time to code them.