Hi, I’ve been watching “Port your widgets to GTK 4” by Matthias Clasen.
He says we should prefer delegation over subclassing.
My app will have 2 kinds of labels, and I want to create 2 classes that will extend the label class.
I am wondering what is the correct approach: If I use delegation and create a class that has a label as a member, I will have to wrap a lot of methods that Gtk::label has, which would have come automatically if I used inheritance.
Perhaps this is case for subclassing after all?
No, not really.
You have the option to expose the label through the delegate, e.g.:
GtkLabel *my_widget_get_label (MyWidget *widget);
or you can wrap the API you definitely use most often, as I doubt you consume the entirety of the GtkLabel functionality.
You can look at how the various text entries in GTK4 use GtkText as the text entry widget.
What about parent-child relationships? How do I catch parents events like resize and visibility changes?
What about those?
If the parent widget is hidden, then it won’t render its children; this applies to GTK3 as well, so you never had to care about it.
My suggestion is to actually implement this, and then raise issues if you find any. Talking in the abstract isn’t very helpful.
1 Like
I think this may refer, to some extent, mostly towards C/C++, and their
variant of OOP, including “specializations”.
In Ruby, for example, there are two basic means for that:
- subclassing (class1 as child of class2)
- module (including modules into your class)
The second approach, in ruby, is more flexible. So within the ruby ecosystem,
“extending” via modules (similar to “delegatation”) is quite common. You can
see this in the rails ecosystem, and the various active* gems (ActiveRecord) and
such, making use of these features a lot.
Oddly enough, I personally still use subclassing a LOT. The ruby-gtk parts also
use subclassing mostly - base widgets, then subclassing for the more specialized
variants. I think while I also concur with Matthias, I think subclassing is still
very popular in general since it is quite simple. It’s not perfect, not as flexible,
but simplicity is a great thing usually. Obviously C but also C++ will differ a bit,
but for ruby, even if Matthias did not refer to it, it’s still very similar.
For example, the C API that has things such as:
gtk_window_new(); # just as an example, from memory … not sure how the API really is
would then be:
Gtk::Window.new
in ruby.
This is quite short already. I wrote a small module just to save typing
stuff, so I then just use “gtk_window” instead. So my ruby code looks
almost like a shorter variant of C! 
Porting in general is a lot of work, though. Some time ago I finally
started to go into ruby-gtk3. And while that goes forward, it still
is so much work … working with C or C++ would be even more
work, as they tend to be more verbose than “well-written ruby”
or “well-written python” I suppose. That is also a reason why I
hope that gtk4 will REALLY be great. I know the gtk-devs want
to release it next year, but to me personally it is more important
that gtk4 will garner and generate a LOT of momentum and
leverage. It would have so many positive “trickle-down effects”
for making the whole ecosystem better, the better the upstream
code base is - including documentation. (The vala-generated
documentation is a bit awkward … I am actually reading a book
about pygtk now, and this is, oddly enough, actually REALLY
good for ruby-gtk too … the small differences in syntax are
not a big deal really. In many ways python and ruby are quite
similar, at the least the code is clear; clearer than e. g. perl
code).
Here is hoping that gtk4 will be great.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.