Skip to content
This repository has been archived by the owner on Jul 22, 2024. It is now read-only.

WIP: GtkApplication Experiments #116

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 8 additions & 2 deletions src/application.jl
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,14 @@ function splice!(app::GtkApplication, win::GtkWindow)
app
end

app_menu(app::GtkApplication, app_menu::GObject) =
ccall((:gtk_application_new, libgtk), Void, (Ptr{GObject}, Ptr{GObject}), app, app_menu)
set_menubar(app::GtkApplication, menubar::GObject) =
ccall((:gtk_application_set_menubar, libgtk), Void, (Ptr{GObject}, Ptr{GObject}), app, menubar)

set_app_menu(app::GtkApplication, app_menu::GObject) =
ccall((:gtk_application_set_app_menu, libgtk), Void, (Ptr{GObject}, Ptr{GObject}), app, app_menu)

run(app::GtkApplication) =
ccall((:g_application_run, libgio), Cint, (Ptr{GObject}, Cint, Ptr{Uint8}), app, 0, C_NULL)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:gtk_application_run ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats strange


@gtktype GtkApplicationWindow
GtkApplicationWindowLeaf(app::GtkApplication) = GtkApplicationWindowLeaf(
Expand Down
6 changes: 3 additions & 3 deletions src/events.jl
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,9 @@ function __init__()

# if g_main_depth > 0, a glib main-loop is already running,
# so we don't need to start a new one
if ccall((:g_main_depth,GLib.libglib),Cint,()) == 0
global gtk_main_task = @schedule gtk_main()
end
#if ccall((:g_main_depth,GLib.libglib),Cint,()) == 0
# global gtk_main_task = @schedule gtk_main()
#end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

additionally, it is already duplicating the call to gtk_init anyways

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :(

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

end


Expand Down
54 changes: 54 additions & 0 deletions test/gtkapplication_tests.jl
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
using Gtk, Gtk.ShortNames, Gtk.GConstants

app = @GtkApplication("org.julia.example", GApplicationFlags.FLAGS_NONE)

const builderstr =
"""<interface>
<menu id="menubar">
<submenu>
<attribute name="label">File</attribute>
<item>
<attribute name="label">Quit</attribute>
<attribute name="action">app.quit</attribute>
</item>
</submenu>
<submenu>
<attribute name="label">Help</attribute>
</submenu>
</menu>
<menu id="appmenu">
<section>
<item>
<attribute name="label">New</attribute>
<attribute name="action">app.new</attribute>
</item>
<item>
<attribute name="label">Quit</attribute>
<attribute name="action">app.quit</attribute>
</item>
</section>
</menu>
</interface>"""

signal_connect(app,"activate") do a, args...
w = Gtk.@GtkApplicationWindow(a)
G_.title(w, "GtkApplication Test App" )
G_.default_size(w, 400,400)
builder = @GtkBuilder(buffer=builderstr)

menubar = G_.object(builder,"menubar")
appmenu = G_.object(builder,"appmenu")

Gtk.set_menubar(app, menubar)
Gtk.set_app_menu(app, appmenu)

#quitIt = G_.object(builder, "menu_item_quit")
#signal_connect(quitIt, :activate) do widget
# exit()
#end

showall(w)
end

Gtk.run(app) # enters main loop