Towards GTK4 - a plea

Hello GTK devs in particular, but also GTK users in general.

First - I wrote this in my GTK-based editor. I can’t stand the online
editor discourse uses. Perhaps this works on smartphones, but on my
oldschool desktop system, using a “classical” GTK based editor is
sooooo much more efficient for me, time-spent-wise. Anyway - I
mention this because I end lines usually at around ~80 chars or so,
so you may see some line breaks in discourse (perhaps). It all
looks great if you were to look at my monitor though … :wink:

This here is mostly a “plea”, a request. It’s along the lines of
“please don’t forget us hobbyist hackers!”.

I will explain this soon, and provide the context.

I am a ruby-guy, that is, I have been writing ruby code since
almost 20 years by now. Even though I am not as active anymore,
I still write ruby code almost daily. Mostly, I just maintain
my projects these days though.


Part of the code I wrote is in ruby-gtk. That is, I work with
the “inofficial” bindings here. These work quite well, but for
various reasons I am stuck with gtk2. (ruby-gtk3 unfortunately
does not offer the same functionality, and “monkey patching”
is also not easily possible due to the weird way how gobject
introspection appears to work, but this is NOT the main point
I want to make for this here).

I think I started to write ruby-gtk code since 2005 or so.

During that time, I noticed numerous projects, but also ruby
users, vanish and disappear. Now: this does not have much
to do with GTK itself, and this happens in most languages,
even python. But still it is sort of sad when you notice
that there is a decline in how many people write code.

A decline is not good for any programming language or project.
But this note is not about a decline, either.

For those of us who STILL write, and maintain code, e. g.
ruby-gtk, they would often like to CONTINUE doing so.

And the note here is ultimately about that part.

Again, for many reasons, transitioning into ruby-gtk3 would
bring specific disadvantages for me. I may still do so in
the long term, but I have to invest a lot of time, with the
end result of reduced functionality in my applications (which
I don’t want to do, for obvious reasons … think you invest
20 hours, and then you have fewer features than before.
Time well spent? Hmmmmmm.)

This is where I hope that GTK4 will actually really improve
the situation overall. At the least I project hope - perhaps
this is just wishful thinking. :slight_smile:

The thing is, to me … the better GTK4 will be, the more
successful it can be, the better for the WHOLE gtk ecosystem,
including downstream bindings (e. g. ruby code).

One thing that I have found over the years to be EXTREMELY
important is … documentation. The docs for gtk are not
great, IMO, but they are not terrible either. Still,
documentation is really important. It allows downstream
developers to make their own code work better, and their
own implementation be better too (since they can read the
official docs).

So, what is this note about, then?

Well. I am following the GTK4 development blog here.

GTK4 seems to look to really improve on many things GTK3
did not get right; and perhaps GTK4 will finally be
better than GTK2, or at the least be as good as GTK2
was (again, from my point of view, in regards to the
ruby-gtk bindings, the gtk2 bindings are better than
the gtk3 bindings).

So my plea is really quite trivial: please don’t forget
us! The better GTK4 will be, the more polished it is,
the better the documentation, the better the whole
ecosystem will end up as well.

As I am right now, with the importance of the www in
general, I wonder whether it is still worth my time
to write any ruby-gtk specific stuff. I still do it
because ruby itself is awesome, and I have a lot of
ad-hoc code and extensions for ruby-gtk2 too, so that
part is fun. But I feel like deadlocked into the past
since transitioning to ruby-gtk3 already would bring
in disadvantages. So to me this is a question of how
good gtk4 will be. And if it is “not good enough” then
I think I’ll have to follow the trail of literally
everyone else, and enter the abysmal world of
javascript - simply because I am less restricted with
the www-stack than with “oldschool” GUIs. (That is
also valid for qt, by the way; just that the ruby-qt
bindings died past qt3, also in parts because qt
got sooooooooo big that no hobbyist is going to
maintain that really. Even ruby-qt4 is incomplete,
and qt6 is going to be released probably next year?)

I am not sure if this note has a point or not, but if
one or two upstream GTK dev reads it, and at the least
considers this too, this may help.

PS: I am aware of gobject-introspection being praised
as the perfect solution for everything, but in regards
to the ruby-gtk bindings, the old handwritten bindings
are so much better than the gobject-variants. I simply
don’t have the same feature parity; my monkey-patched
“module Gtk” works fine on ruby-gtk2 but does not work
AT ALL on ruby-gtk3. I could expand on this but the
more important thing is that the “gobject-all-the-things”
does not automatically mean everything REALLY has gotten
better. And in that particular context, it actually would
make a whole more sense to just be done with it, use
javascript and Google’s adChromium monopoly, even
electron, no matter how much RAM and babies it eats …
all of which is the “logical path” to pursue. But before
that, I really want to be hopeful and think of GTK4
being a REALLY great GTK, even better than gtk2. So
please don’t forget on awesome upstream documentation
AND downstream hobbyists coders. (In regards to
documentation: I also include examples. I learn best
with examples of working code.)

1 Like

I started with Ruby-GTK around 2007. Used the A. Krause C book, the few available Ruby tutorials. Then when GTK3 appeared and there were partly working Ruby bindings I switched to GTK3, maybe in 2011. I wrote a CAD like tool with cairo drawing and GtkDrawingArea.

While Ruby is a fine language, and I was really thankful for the people working on the GTK bindings, I got some serious problems. Using C docs was hard, as many stuff was done differently, and there were not many Ruby GTK3 tutorials. And Ruby is not that fast, for my DrawingArea code and other time critical code that was a problem.

So finally in late 2014 I considered switching to another language and/or another GUI toolkit. Well for FOSS there is mostly Qt that is coupled strong to C++. But I don’t like C++, and Qt is really bloated.

For languages I considered Rust, D, Go, and some more and finally found the tiny language Nim, that time still called Nimrod. Nimrod had GTK2 bindings. As I wanted to use GTK3 I created low level GTK3 bindings, with a tool called c2nim which could process C header files. But GTK headers are hard, took me 600 ours totally. And finally I found out that low level bindings are really not nice.

So in late 2015 work on high level GTK3 bindings using gobject-introspection started. Maybe starting from scratch was not the best decision, but at that time other bindings projects like Rust, Go, Crystal were all also on early stages. The high level bindings including the provided GTK3 examples took me 1600 hours until now. We have also GTK4 support now.

So you see that making high level bindings is some effort. When you should have still hope for Ruby GTK4 you should best ask the devs on gitlab or github, as I have never seen that devs here. They are from Japan as Ruby is. As Ruby is similar to Python, and Python has good GTK gobject-introspection bindings, maybe Ruby devs can take advantage from Python bindings generators?

But you may know that Ruby is not in a great shape any more. Compared to GTK it may appear still very well supported and active, but it can not compare with the popularity of Python.

So what is my conclusion?

  1. Ask the Ruby GTK devs about status.

  2. If you are not too old and sick already, consider another language or toolkit. Learning something new is always a good idea.

There exists many new nice languages. Rust seems to offer much GTK activity currently, Mr. Droege from the Rust GTK team is friendly and helpful.

If you want to stay close to Ruby there is Crystal. But I have not followed its development closely in the last years and know not much about its gobject-introspection GTK bindings. See

And finally there is Nim. I made some progress with the GTK4 book recently, it should be a useful introduction already.

I have to be honest: I don’t understand what you’re asking in your rambling “plea”. It’s not helped by the fact that you’re literally breaking the formatting for your own convenience, forgetting about the convenience of the people who need to read it—but let’s leave that particular can of worms closed, for now.

If you’re asking for better Ruby bindings, you will need to ask the people who maintain them. GTK developers do not maintain the bindings for the library. We only provide the C ABI and a machine parseable description of our API; what others do with it, it’s entirely up to them.

There’s also no technical reason why introspection-based bindings need to have limitations compared to the hand-written, static ones; in general, that’s a decision made by the bindings developers. Python, Perl, JavaScript developers have the ability to write and load overrides in their native languages, to make the introspected API more idiomatic. You may want to ask the Ruby bindings developers to look into that.

As for the documentation: yes, we don’t forget about it. We have an entire set of examples and demos shipped by GTK itself. Of course, it helps when people send merge requests, or open issues asking clarifications. GTK is a volunteer-based free software project; it’s not a black box, and should never be treated as such by “downstream coders”, hobbyists or not.

Finally, if you’re soul-searching for a new language with better bindings, there’s an embarrassment of riches available to you, between Python, Perl, JavaScript, Rust, D, or even Go. We have an entire section on the GTK website.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.