GTK Class Subclassing

[Xliff]

Martin,

Is it possible to subclass using any of your GNOME:: classes?

[MARTIMM]

For some classes, subclassing is possible but not all. The important ones are leaf-like, such as Window, Grid, Label, Frame, Button, etc. So you can say class MyWindow is Gnome::Gtk3::Window { … with some whistles added.

However, The classes are all behaving like a wrapper around native objects. These objects are handed over to the subs. One cannot expect when building a raku object using a returned native object from an event call that the Raku object will be the same, i.e. the attributes will not have the same values as before.

There is a trick to transport variables along with the native object, as long as it is a GObject. The native subs are g_object_set_property() and g_object_get_property()

The documentation of what is available can be found here. A few docs are becoming outdated like the tests done on Travis-CI on the first page or maybe tutorials need to be reviewed. Anyways, now working to get the reference pages in order to iron out old usage,

P.s. This answer belongs a bit to the version 3 gtk repo, Because I do not yet know if the behavior of this repo, version 4 gtk, will be the same.

[Xliff]

@MARTIMM - Thanks! I'll let you know if I'm able to work something out on my end.

[MARTIMM]

Btw, Just thinking. There are now several Raku repos that are around version 4 of gtk. You already have raku-GTK4 forked from somewhere else I believe, @finanalyst is also thinking about making a version 4 for GTK::Simple. Mine would be the newest. The status of the usability is not clear to me yet and I am still building a scaffold.

Although, the implementations differ, would it be wise for me to also engage in the making of Gnome::Gtk4 and Gnome::Gdk4. The largest of them being the Gtk4 will be again a lot of work but still can build upon the other Gnome modules because they are separated in the first place.

[Xliff]

@MARTIMM - Only you can answer that question. My raku-GTK4 is not a fork, however. It is an original work based on the same source as my p6-GtkPlus work: the header files belonging to the libraries.

At this point, I believe that we all have an itch we want to scratch. Raku is too young for us not to scratch it. When the dust has settled and we're all comfortably relieved, maybe we can start merging our work.

However I think it's too early to tell.

I am about a month away from finishing raku-GTK4, and even then, I still have not been able to release anything I have done due to a perceived shortcoming in CompUnit::Repository::Installer which is my next destination.

Good luck!

[MARTIMM]

@Xliff Thanks for the time to answer this. So, maybe I'll scratch a bit on the version 4 surface in case I will implement the package.

Interesting that you mention CompUnit::Repository. I was wondering why it wouldn't do just by using zef to install it all, and then I thought, is it maybe faster to load a module this way than to use the require() statements? This might be a nice addition to spread compile time. I would like to have some comments on that.

regards, Marcel

[Xliff]

My largest problem with anything using Compunit::Repository is its lack of output to the user. For something that has anything more than 20,000 lines of code, Raku's existing installers do not scale properly when it comes to wait times and the notification of installation progress.

[MARTIMM]

@Xliff Ah, I see what you mean. When a fresh program is made based on these large packages or a fresh install, it takes a lot of compile time and you don't know which module it is working on. A lack of progress info sometimes makes you think you have something along the line of 'do we have a hangup here?'.

Let's scratch on and hopefully, we can help each other with some problem

[Xliff]

@MARTIMM - You have the right of it! Thanks for understanding