Moving GTK::Simple to GTK 4

[finanalyst]

GTK 4 has finally been launched see Blog post Doc on website a link in blog post is wrong. It seems to me that rather than working to expand the GTK::Simple widgets set to cover GTK 3, it would be best to move to GTK 4

In addition, my intuition is that the people at GTK will be far happier to help with providing Windows dlll for GTK 4 than for GTK 3

But before going down the rabbit of converting GTK::Simple to GTK 4, I'd appreciate feedback.

My thought is that it would be better to create a new module GTK4::Simple whilst leaving GTK::Simple as GTK 3, then renaming GTK::Simple to GTK3::Simple when GTK4::Simple has achieved the same coverage as GTK::Simple, them making GTK::Simple an alias of GTK4:: rather than GTK3::S.

Feedback?

[Xliff]

That sounds like a plan to me.

Of course there is also use GTK::Simple:ver<4>, yes? I do believe that if the tagging is done now, then both sets of modules can live alongside each other.

[finanalyst]

This is a better plan. Something like it occurred to me after I wrote the above.

Also, I have been looking for the gtk4 libs, and I couldn't find any. May be I am looking in the wrong places.

[MARTIMM]

What version do you get if one is forgetting to add :ver<>

[finanalyst]

We are still using GTK3. At the time, I thought progress towards GTK4 was further along and I could not easily find how to install GTK4 on my Ubuntu box without messing up the GTK3 libraries. Perhaps now, a year later, there is a bit more clarity. I have done most of the work on GTK-Simple to follow the stop to make the transition to GTK4.

[polyjitter]

On Ubuntu, it is now libgtk-3-* for gtk3 and libgtk-4-* for gtk4!

[finanalyst]

@polyjitter Thank you. But this is a bit far down my TODO chain at present. Any help would be appreciated.

[Xliff]

@finanalyst - What kind of help are you looking for?

[tbrowder]

Can you give an example of putting a photo image in a frame or other suitable widget? Thanks.

[Xliff]

@tbrowder - For GTK3 or GTK4? (although I can't imagine it would be much different).

GTK has a class called GTK::Image. You would load the image using GTK::Image.new_from_file, which create the object. You can then put that object in any widget you want it displayed. For the main window, you can just use the add method. A more common way is to create a GTK::Box and use pack_start or pack_end to place it inside.

If you would like an overly complex example, please see this sample. My GtkPlus inherited its beginnings from GTK::Simple, so hopefully many of the concepts remain the same.

[tbrowder]

Thanks. For either module, on Linux, is there a way to put $app.run in the background so the widget stays in view while the CLI window is cleared for another entry if desired?

[Xliff]

@tbrowder - Not sure I understand what you mean. Can you show me a screenshot. Feel free to email me if you want detailed help for this.

[tbrowder]

That's okay for now--not too important. Thanks for the help.

[ab5tract]

I'm wondering whether the shift to GTK4 might be an opportunity to use Raku's versioned API functionality.

I also have some ideas on re-organizing the library that could live behind such an API flag.

[Xliff]

@ab5tract - I'm already working on something along those lines. Would love some help. raku-GTK4

[finanalyst]

@ab5tract and @Xliff
I tried using the api functionality with my Pod::To::HTML module. But the api did not work well and I eventually had to change the module name to P/T/HTML2. For some time, the older versions messed up older repos. So, I think the GTK4 development should start using raku-GTK4 to begin with. When we have a working distribution, then we can start using GTK::Simple:api(4).

[polyjitter]

I don't know if doing all this by hand is future proof or maintainable. GTK has ballooned in widget count, and with libadwaita, it's going to just get even larger. Why is gobject introspection not being considered?

On Fri, Jan 20, 2023, at 5:26 PM, Richard Hainsworth wrote:

@ab5tract https://github.com/ab5tract and @Xliff https://github.com/Xliff I tried using the api functionality with my Pod::To::HTML module. But the api did not work well and I eventually had to change the module name to P/T/HTML2. For some time, the older versions messed up older repos. So, I think the GTK4 development should start using raku-GTK4 to begin with. When we have a working distribution, then we can start using GTK::Simple:api(4).

— Reply to this email directly, view it on GitHub https://github.com/finanalyst/GTK-Simple/issues/103#issuecomment-1399027987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKJYQHGTDZ64RGDLTUWEO3WTMGKVANCNFSM4VHGLK5Q. You are receiving this because you were mentioned.Message ID: @.***>

[Xliff]

@polyjitter - Unfortunately, I'm not well versed in GObject Introspection.

I work from code generators, and I have over 25 GNOME repositories that use this approach. I'm able to get through most bindings in a matter of a month or so. GTK4 will probably take a total of 4 months to finish. I'm halfway through.

I've already handled the v3 version of Adwaita (aka raku-Handy), and I'll probably take a break and handle that after finishing GTK4.

[ab5tract]

@finanalyst @Xliff

Thanks for the clarifications makes sense. That's a shame about API versioning not working very well though. I had a feeling that might be the case and was hoping to explore it enough to find out. But no need to go down a known-difficult path when there are other options available.

[finanalyst]

@ab5tract I am not sure about the current state of :api. It was not working, but that might have been worked on. I think we should try to get it working and use GTK::Simple as the test case.

@Xliff I dont have any experience of code generators or GOobject introspection. I am the maintainer of this module because I use it regularly and have to fix it. I admit to less knowledge than either of you have. (I am also a bit distracted with my work on the Collection software for building a website)

GTK::Simple does leverage some of Raku's concurrency syntax. However, GTK::SImple has an ad-hoc feeling to me. It does not completely cover all widgets, or all functionality.

With the move to api(4), I was wondering whether we could try a different, automated approach, thus allowing integration of other GTK cool bits, such as the kits which demonstrate all the widgets.

Lets try to get some ideas sketched out for the development of the api(4) module.

[Xliff]

@finanalyst - Sure, I'm game. Please let me know the aspects of my work that you would like to be familiarized with, and I will try and get something written down.

[MARTIMM]

To put my two cents in, I am also attempting to build version 4 Raku libraries for Gtk and Gdk. Because many parts are separated e.g. Glib, GObject, and Gio, I only have to concentrate on the Gnome::Gtk3 and Gnome::Gdk3 libraries to create the Gnome::Gtk4 and Gnome::Gdk4 counterparts.

The setup and use of the C-libraries are different in our packages but maybe some details can be of use to you. At the moment, there is not much to see at my repositories but here are the links to them anyway; gtk4 and gdk4.

[MARTIMM]

In the meantime, I have made something usable although not yet published. The distro is a generator to generate the Raku modules. In that distro, you can find a directory gnome-api2. The generator of the modules also makes use of the object introspection but does not use the libraries. It uses the XML files at /usr/share/gir-1.0 instead. I found out that there are still some inconveniences like, for instance, that the versions of those files are a bit behind the latest version of Gtk 4.

Because of my previous attempts, I also make use of the :api<2> adverb. The older version is now set with :api<1>. The adverb is tacked on every class, role, and structure, as well as mentioned in the META6 file. The user of the software must import all the modules using this adverb, otherwise, raku will only look at the version which might select the wrong module.

You can find the generator at github skimtool and a first test to try out several parts of the library at github puzzletable. A screenshot; The application tests, besides the obvious like buttons and labels, an about dialog, shortcut keys, menus using Gio, builder XML UI descriptions, and program argument handling in an application. For the table, there is a string list, multi-selection, grid view, and a signal list item factory needed. Very interesting stuff. I hope you can somehow make use of that.