WIP - Add ccall API for missing GtkRadioMenuItem, GtkImageMenuItem, GtkCheckMenuItem

[miguelraz]

This is an upstream fix that is causing precompilation woes for the Ahorn package.

I definitely need some help in order to make the Ahorn code call into the Gtk ccall API properly.

Direct instruction is needed and welcome on how to add these

• GtkRadioMenuItem
• GtkImageMenuItem
• GtkCheckMenuItem

into Gtk.jl/src/menus.jl.

[tknopp]

This requires the generator scripts to be run. I have not done this for a long time and I actually don't know if that works at all, currently. For instance GI.jl does not work anymore. IIUC it requires to use Clang.jl though.

@jonathanBieler do you have any experience in that area?

[jonathanBieler]

I'm not sure we really need to run the generator script here, it just adds methods to https://github.com/JuliaGraphics/Gtk.jl/blob/master/gen/gbox3 right ? It would be nice to have but it's not necessary.

If you just need the type, constructor and a few methods then adding them manually is fine. You can just copy paste your code into Gtk.jl/src/menus.jl remove the Gtk. prefix, export the functions and it should work.

Maybe you need to change the names a bit so they match better the style of this package though, but you can already try it with your names to make sure it works.

[tknopp]

That is kind of true, but there are some getters/setters that could be desired: https://developer.gnome.org/gtk3/stable/GtkImageMenuItem.html

@miguelraz: Do you require the dedicated getters/setters? If not, does all work what you wanted to do? If yes, could you add a test?

@jonathanBieler: Still the question: have you run the getter/setter/constant generator in the post 1.0 area?

[jonathanBieler]

I actually never ran it. It looks pretty ancient but maybe it's still working.

[tknopp]

It is something we need to get going. For background these functions generate all the functions automatically the have a get or a set in their name. First only Clang was used for that but at some point parts(?) were also done by the GI.jl package. Unfortunately, the later is not working anymore. I tried to convert it to 1.x at some point but had no luck. But as I said, I am not 100% sure if we need both GI.jl and Clang.jl.

In the long run, the plan was actually to move much more into these scripts and convert much more. The Python bindings are done in that way. But in the short run, it would help if we could at least bootstrap this package.