Gtk4

[tknopp]

Gtk4 has been released: https://blog.gtk.org/2020/12/16/gtk-4-0/

This issue is meant for discussions on what is needed to support that release in Gtk.jl. Certainly we will need help of @giordano for the generation of binaries. Not sure if there are huge changes in the building procedure of Gtk.

[jonathanBieler]

https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html

Seems like there's been some changes with events :

https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html#id-1.7.4.3.14

[tknopp]

Nice, that seems to be very helpful

[giordano]

I built Gtk 4 in JuliaPackaging/Yggdrasil#3915

[giordano]

First very quick example based on the documentation:

using GTK4_jll, Glib_jll

function activate(app::Ptr{Cvoid}, user_data::Ptr{Cvoid})::Cvoid
    window = @ccall libgtk4.gtk_application_window_new(app::Ptr{Cvoid})::Ptr{Cvoid}
    @ccall libgtk4.gtk_window_set_title(window::Ptr{Cvoid}, "Window"::Cstring)::Cvoid
    @ccall libgtk4.gtk_window_set_default_size(window::Ptr{Cvoid}, 200::Cint, 200::Cint)::Cvoid
    @ccall libgtk4.gtk_widget_show(window::Ptr{Cvoid})::Cvoid
end

cactivate = @cfunction(activate, Cvoid, (Ptr{Cvoid}, Ptr{Cvoid}))

app = @ccall libgtk4.gtk_application_new("org.gtk.example"::Cstring, 0::Cint)::Ptr{Cvoid}
@ccall libgobject.g_signal_connect_object(app::Ptr{Cvoid}, "activate"::Cstring, cactivate::Ptr{Cvoid}, C_NULL::Ptr{Cvoid})::Cvoid
status = @ccall libgio.g_application_run(app::Ptr{Cvoid}, 0::Cint, ""::Cstring)::Cint
@ccall libgobject.g_object_unref(app::Ptr{Cvoid})::Cvoid

---

Other example with "hello world" button:

using GTK4_jll, Glib_jll

print_hello(widget::Ptr{Cvoid}, data::Ptr{Cvoid})::Cvoid =
    @ccall libglib.g_print("Hello World!\n"::Cstring)::Cvoid

c_print_hello = @cfunction(print_hello, Cvoid, (Ptr{Cvoid}, Ptr{Cvoid}))

function activate(app::Ptr{Cvoid}, user_data::Ptr{Cvoid})::Cvoid
    window = @ccall libgtk4.gtk_application_window_new(app::Ptr{Cvoid})::Ptr{Cvoid}
    @ccall libgtk4.gtk_window_set_title(window::Ptr{Cvoid}, "Window"::Cstring)::Cvoid
    @ccall libgtk4.gtk_window_set_default_size(window::Ptr{Cvoid}, 200::Cint, 200::Cint)::Cvoid
    @ccall libgtk4.gtk_widget_show(window::Ptr{Cvoid})::Cvoid

    button = @ccall libgtk4.gtk_button_new_with_label("Hello World"::Cstring)::Ptr{Cvoid}
    @ccall libgobject.g_signal_connect_object(button::Ptr{Cvoid}, "clicked"::Cstring, c_print_hello::Ptr{Cvoid}, C_NULL::Ptr{Cvoid})::Cvoid
    @ccall libgtk4.gtk_window_set_child(window::Ptr{Cvoid}, button::Ptr{Cvoid})::Cvoid

    @ccall libgtk4.gtk_window_present(window::Ptr{Cvoid})::Cvoid
end

cactivate = @cfunction(activate, Cvoid, (Ptr{Cvoid}, Ptr{Cvoid}))

app = @ccall libgtk4.gtk_application_new("org.gtk.example"::Cstring, 0::Cint)::Ptr{Cvoid}
@ccall libgobject.g_signal_connect_object(app::Ptr{Cvoid}, "activate"::Cstring, cactivate::Ptr{Cvoid}, C_NULL::Ptr{Cvoid})::Cvoid
status = @ccall libgio.g_application_run(app::Ptr{Cvoid}, 0::Cint, ""::Cstring)::Cint
@ccall libgobject.g_object_unref(app::Ptr{Cvoid})::Cvoid

[IanButterworth]

Disappointed there's no baboon

[giordano]

Yeah, the first examples I found in the documentation didn't show how to display images 😬

[tknopp]

@jwahlstrand: Now we "just" need your Gtk3/4.jl re-design ;-)

[tknopp]

This is huge Mose! I can't thank you enough for that.

[jwahlstrand]

@jwahlstrand: Now we "just" need your Gtk3/4.jl re-design ;-)

I've gotten bogged down with GBoxed type issues but I'll submit a PR on what's working (for Gtk3) soon!

[Boxylmer]

Sorry if this is an ill-thought-out-question, but do you all expect to make GTK4 work seamlessly in GTK.jl like GTK3.XX do? i.e., where you can simply load in a template from Cambalache (instead of Glade) and the functions that interact with the widgets will work seamlessly (once everything is implemented, of course)? I'm just curious about the roadmap and what I should expect to plan for in development using GTK.jl. I understand none of this is a guarantee or promise! :)

[jwahlstrand]

I think it will look a lot like Gtk.jl. My goal is to support all widgets and have a bunch of auto-generated methods, with a layer of more Julian functions (1 based indexing, array interfaces, etc.) based mostly on those methods rather than ccalls. GtkBuilder support will hopefully work like it does in Gtk.jl. Also, Gtk.jl will be able to be installed in parallel -- it's not going away.

[Boxylmer]

Thanks so much for the reply, and I look forward to seeing it! I'm currently using this library to build a GUI that'll go through packagecompiler to have something which can collect and display data in our lab.

[needlesslygrim]

Is there any news on GTK4 progress?

[jwahlstrand]

Yes, see https://github.com/JuliaGtk/Gtk4.jl

On Linux x86_64, it works about as well as Gtk (with the caveat that this statement is purely based on my own experience). On a Mac it works pretty well but I have noticed annoying bugs. For example, new windows are placed in odd locations, often partially offscreen. On Windows I've noticed a lot more bugs. Some of these are known issues and will hopefully be fixed in future versions of GTK. Some might be fixed by upgrading GTK4_jll to 4.6.5, which unfortunately will require upgrading one of its dependencies (I'll submit a PR).

Worse, because GObject introspection data is generated on a x86_64 machine, some of the autogenerated methods don't work on 32 bit architectures. That could be fixed by including GObject introspection data in JLL's, which is super ambitious, or we could take a step back and convert the most essential broken methods to handwritten ccall's.

[needlesslygrim]

Ooh, that's interesting. Does it support libadwaita?

[jwahlstrand]

No, but with introspection it wouldn't be much work to make a package for libadwaita.

[tknopp]

This is pretty impressive @jwahlstrand. I just tried it on my Mac and it just worked.

Not sure how large the actual API changes are. I have a larger Gtk.jl App that I could try porting at some point. Or we try something like https://github.com/timholy/ProfileView.jl

[jwahlstrand]

Thanks, that's good to hear. The API changes for most applications shouldn't be that big. The removal of GtkContainer and GtkBin is hidden by the Julia interface because push!, getindex, etc. methods are defined that point to C functions for the different widget types. Drawing via Cairo in C is different, but GtkCanvas looks pretty much the same from Julia. Events are handled very differently, but porting will involve tweaking names and removing lots of calls to showall().

BTW I ported most of GtkObservables over to Gtk4 and have done some work on ImageView too:
https://github.com/jwahlstrand/GtkObservables.jl
https://github.com/jwahlstrand/ImageView.jl

[tknopp]

Perfect. I created JuliaGtk/Gtk4.jl#4 to gather information about the ports. Winston.jl was easy.
My larger (non-public) Gtk.jl app still does not work since I need to port the builder files somehow and need to find binaries for the gtk4-builder-tool on mac.

[tknopp]

@jwahlstrand: I propose that we do a "roadmap" issue over at Gtk4 and there have a list of known regressions over Gtk.jl, which need to be fixed before making the grand package switch. There can of course be dedicated issues for each point but I think it is better to move the discussion over to Gtk4.jl.

What has become clear for me yesterday is that Gtk4 and Gtk3 are two different libraries. The porting effort is manageable but it should not be neglected. IMHO once Gtk4 is stable enough, works on all three platforms, we should just switch and abandon Gtk.jl.