WIP: GtkApplication Experiments

[tknopp]

Ok I had a look at GtkApplication and got a simple example running including a global menu on OSX. Yay.

But this raises questions how to move forward. Much of the functionality around GtkApplication is implemented in GIO. So is it possible to autogenerate the accessors for GIO types as well?

To get the menu actually working one has to implement the GAction interfaces. All this looks a little complicated and I wonder if one could define this using the regular GtkMenu in code (without GtkBuilder) with regular callbacks.

[vtjnash]

you can just delete this, or I'll get around to it sometime. might be good to open an issue to remind me

[tknopp]

The question is if we want to allow to automatically call it when being on the REPL, which would be nice for interactive usage but would be not so nice because one could not use GtkApplication from the REPL.

[vtjnash]

For that, I have no idea (#100 (comment))

Is it OK to start the GtkApplication main loop from inside gtk_main?

[vtjnash]

additionally, it is already duplicating the call to gtk_init anyways

[tknopp]

Not sure. Have not tested this yet. The documentation says one should not call gtk_main when using GtkApplication.

[vtjnash]

I'm not really sure either. I think gtk_init might be a no-op if called twice. And those fixes also let you call gtk_main multiple times, across multiple tasks -- although julia's COPY_STACKS corrupts the stack if you try that :(

[tknopp]

Indeed, the gtk_init does not seem to hurt when using gtkapplication. when scheduling gtk_main in __init__ and afterwards calling Gtk.run(app) I get a crash though

signal (6): Abort trap: 6
??? at ???:202552579
??? at ???:202544405
??? at ???:-1907329622
Abort trap: 6

So it seems that gtk_init can stay but gtk_main should be removed and the user simply has to call it.

[vtjnash]

i checked the glib code again, and realized the concerning code i had seen in the 2.34.1 source has been removed in 2.40.0 (i'm running the newest version, but had older code lying around). now that Keno has fixed the backtrace printing, could you run it again and see if it prints a more meaningful stack trace?

[tknopp]

tobias-knopps-macbook-2:test knopp$ julia  gtkapplication_tests.jl 
**
GLib:ERROR:gmain.c:3069:g_main_dispatch: assertion failed: (current->dispatching_sources == &current_source_link)

signal (6): Abort trap: 6
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Abort trap: 6

But if gtk_main is scheduled first and afterwards Gtk.run(app) is called, do you really expect that this would work.

[vtjnash]

yes. this indicates you are running on a version of glib prior to 2.40.0 with COPY_STACKS in julia. it also potentially indicates that I'm returning from the jl_yield callbacks in the wrong order, but I thought i fixed that in 0a63ea7#diff-8c2b506e7179e52e816713686d731068R248 (although rereading that code, i see i'm missing a try/catch block)

[vtjnash]

yes, can definitely add GIO objects to the autogenerated code database

[vtjnash]

:gtk_application_run ?

[tknopp]

That does not exist. its the g function that has to be called

[vtjnash]

oi! apparently it existed in 3.0, then disappear before release? https://developer.gnome.org/gtk3/2.90/GtkApplication.html#gtk-application-run

carry on then.

[tknopp]

Thats strange

[tknopp]

Regarding GIO we won't need anything from it but to make gtkapplication useful the following submodule should be wrapped:

https://developer.gnome.org/gio/stable/application.html

[vtjnash]

some of the others look useful too:
https://developer.gnome.org/gio/stable/icons.html
https://developer.gnome.org/gio/stable/gdbus-lowlevel.html
https://developer.gnome.org/gio/stable/icons.html
https://developer.gnome.org/gio/stable/settings.html
https://developer.gnome.org/gio/stable/permissions.html
https://developer.gnome.org/gio/stable/gdbus-convenience.html

[tknopp]

I added some initial support for GActions. It almost works but I get an error

ERROR: Could not convert GValue of type GVariant to Julia type
 in error at error.jl:21
...

when the quit callback is invoked. So we need support for GVariant (and GVariantType also for GSimpleAction)

[vtjnash]

can you open an issue? i hadn't implemented support because I didn't know what a GVariant would look like

[tknopp]

I have faked a gvariant implementation and now I can quit the application from the menu. This native OSX menu integration is great!

[vtjnash]

haha. Excellent! I was just contemplating how much would it would be to write a proper wrapper for it

[tknopp]

Serious support will be implemented in #117 which seeks for an assignee... ;-)

Just added a simple support for accelerators and it just works. Starts to make fun.

[malbert137]

First, thank you to all who looked into this.

I suspect it's easier generally to not use the "application" thing, but for what it's worth, this seems to work for me:

#!/usr/bin/env julia

import Gtk

function on_clicked(w)
  @info "clicked!" # println() doesn't work here?
end


function activate(app)
  window = Gtk.GtkApplicationWindow(app)
  Gtk.set_gtk_property!(window, :title, "Hello")

  button_box = Gtk.GtkBox(:v)
  push!(window, button_box)

  button = Gtk.GtkButton("Hello world!")
  push!(button_box, button)
  Gtk.signal_connect(on_clicked, button, :clicked)

  #Gtk.showall(app) #hangs here?
  #@info "showall() ok..?"

  Gtk.showall(window) # without this, no visible window
end

# execution starts here
app = Gtk.GtkApplication("stuff.fun.my", 
        Gtk.GConstants.GApplicationFlags.FLAGS_NONE)

Gtk.signal_connect(activate, app, :activate)

Gtk.run(app)