GAccessor Module

[tknopp]

I would like to discuss the GAccessor or G_ module. Here are some thoughts/questions:

• Is this really limited to the accessor functions or can't we have a larger module, where we basically drop all auto-generated functions in? Or on other words: Why are the accessors special? The Gtk API has non-accessor functions as well.
• From a user perspective G_ seems to be an unnecessary implementation detail. If its about namespacing, I would find Gtk.set_... more natural than G_.set_....
• Might it make sense to see G_ but automatically create wrapper functions in Gtk, which handle the 1-based indexing. This should be doable with some macro-code-gen magic.
• I am somewhat unsure about the explicite get/set in the name. It's somewhat unjulian but it helps making the connection to the C API.

[jwahlstrand]

The G_ module already contains all the auto-generated functions. If you look at the main Gtk4 module, there are very few ccall's -- it's largely based on calling G_ methods.

For G_, I'm sort of aiming for the pygobject experience, where once you know the pattern, you can pick a C function from the GTK docs and predict what the python function will be named (and how to use it).

I'm totally open to changing things, but here was my reasoning for not putting the autogenerated methods directly in Gtk4:

• The autogenerated methods use 0-based indexing and don't follow Julian conventions like using an exclamation point for signifying that arguments are modified. To avoid polluting the main module with unjulian methods, I thought it made sense to put them in their own submodule so that users know these are the autogenerated methods.
• In the Gtk4 module are julian functions, many of which just call G_ methods but have names that, for example, match Julia's array interface method names and translate the G_ methods to use 1-based indexing.
• As for the explicit get and set in the accessor methods, I kept these in the name because it's consistent with the rest of the G_ module. It helps users connect to the C API, as you wrote. It would be easy to define accessor methods that call the get/set methods in G_. These could go in the Gtk4 module or in a new GAccessor module. What do you prefer?

This all needs to be documented far better than it currently is...

[tknopp]

Ok thanks for explaining. For me it totally makes sense to group the autogenerated stuff in G_ and keep the get/set names. But then we probably should not make this the official API but rather the low-level one, which only should be used by experts that know what they are doing. For the official one we IMHO should create wrapper types in Gtk4 namespace. I don't see a reason to put them in an extra GAccessor module. Ideally one loads Gtk4 and has everything in place.

[Boxylmer]

What would be an argument against wrapping Julia-friendly function names besides the time input of doing so?

[jwahlstrand]

Sorry for my silence -- I've been busy. I will implement accessor functions like title(w) and title(w,str) that point to G_.get_title(w) and G_.set_title(w,str) in the Gtk4 namespace soon. I think @tknopp and I agreed on that approach in the discussion above. Do you have any arguments against that?

One thing that I think is clear is we won't be able to export all of these accessor functions because of name collisions with other packages.

[jwahlstrand]

OK, this is now done and I just updated the docs. The vast majority of the accessor functions are not currently exported, but a lot of them could be. There's >500 of them so it seems a bit excessive to export all, and some will collide with other packages. So I'm inclined to export just the most important. Sound reasonable? If so, we should discuss which are the important ones.

[tknopp]

I think this is reasonable. One might even think about not exporting any of them. My main point was just to get rid of Gtk.G_ as the public interface.

[Boxylmer]

Apologies if this is an irrelevant point, but would wrapping these functions explicitly allow you to provide some protection against some of the c-stack corruption issues faced in GTK3 with certain calls? We faced issues with GtkCombo in particular, and never quite figured out what was causing it, opting to just lock the user away from it when it wasn't needed. It's also possible these issues are moot in GTK4, but I figured I'd ask for the sake of discussion.

[jwahlstrand]

The autogenerated wrappers do some checks but are pretty much as unsafe as ccalls. I think it should be possible to create wrappers for GtkComboBox that are relatively safe to use, but I have no experience with that API in C. You might try looking for examples with the pygobject bindings...