Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GtkApplication #64

Open
tknopp opened this issue Feb 9, 2014 · 10 comments
Open

GtkApplication #64

tknopp opened this issue Feb 9, 2014 · 10 comments

Comments

@tknopp
Copy link
Collaborator

tknopp commented Feb 9, 2014

@vtjnash: Do you see any way that we could wrap GtkApplication (https://developer.gnome.org/gtk3/stable/GtkApplication.html)? The motivation is that it allows to get the proper global menu on OSX and Gnome. The issue is that it seems to initialize the gtk main loop. If I understand this correctly, this is a problem right?

@vtjnash
Copy link
Contributor

vtjnash commented Feb 9, 2014

I hadn't seen that API before. That is awesome. (note that GApplication is a Gtk+ 2 API also!)

GApplication tells you exactly what you need to call to emulate g_application_run (it consists of calling g_application_register() then g_application_activate() or g_application_open(), then exit if g_application_is_remote() otherwise run the mainloop. (although it's unclear how you would trigger the command-line signal).

(Alternatively, now that JuliaLang/julia#5687 is merged, we could flip the ownership of the mainloop so that Gtk is the primary and Julia is triggered from a timer.)

@tknopp
Copy link
Collaborator Author

tknopp commented Feb 9, 2014

Ah yes I see. I had only read the information text to GtkApplication and thought that gtk-init is called in the constructor. I also had not seen that all this depends on libgio.
So it seems that we want to wrap these application parts of GIO and then add GtkApplication window on top of that.

I am not so sure about whether we should flip the ownership of the mainloop. The other way around seems to be more natural for Gtk bindings. But if I get it right we would loose the possibility to construct Gtk widgets on the REPL, right? Or, more concretely, we could only construct them but the callbacks would not be invoked until gtk-init is called, which would block.

@vtjnash
Copy link
Contributor

vtjnash commented Feb 9, 2014

That's the fun part about flipping it correctly -- it would be completely transparent to the user.

@timholy
Copy link
Member

timholy commented Feb 9, 2014

I love how stuff gets tackled on a "deep" level in this community, and how it opens up new possibilities.

@vtjnash
Copy link
Contributor

vtjnash commented Feb 9, 2014

It's definitely helpful to both maintain a package and be deeply into the core of julia.

@timholy
Copy link
Member

timholy commented Feb 9, 2014

Try that with Matlab 😄.

@vtjnash
Copy link
Contributor

vtjnash commented Jul 28, 2014

@tknopp feel free to submit a pull request for this. I've now switched the mainloop ownership on master (aside from being mildly sketchy that we do a stack replacement while inside a Gtk callback). But now you can do whatever you want with the main loop!

@tknopp
Copy link
Collaborator Author

tknopp commented Aug 1, 2014

@vtjnash I am not entirely sure if I find much time for Gtk.jl development in the near future so I won't commit myself to this.

My main motivation here was to get a global main menu on OSX when I was developing Julietta. I have not yet ported Julietta to the new Gtk.jl API. In general I think it is a quite nice testbed for Gtk.jl.

@vtjnash
Copy link
Contributor

vtjnash commented Aug 1, 2014

No pressure. Just thought I would point out how the situation has changed recently, making this much easier to play around with

@tknopp
Copy link
Collaborator Author

tknopp commented Aug 1, 2014

Yes, thanks for the hint. I am really looking forward playing around with this when I find time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants