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
The policy on how we would proceed from here:
- 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.)
and nothing else. This means we can think about implementing new HIDs
more easily.
- 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 GTKN 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.