GtkApplicationWindow would only update its list of captured accels
when realizing the window. This meant that keyboard shortcuts added
after the window was realised (for example, added by plugins) would
be non-functional.
Solve this by updating our accels every time the accel map changes,
not only when realizing the window.
https://bugzilla.gnome.org/show_bug.cgi?id=700079
Instead of reparenting the content, use input-only windows to
set cursors and capture clicks on the window frame. This avoids
some of the problems that were introduced by content_window, such
as black flashes and non-working opacity.
Update the documentation and users of this function to handle
the future case that that we have some internal decorations to the window and
useable allocation is thus smaller.
By having a separate out parameter there is no need to have an in/out function
and allows for greater robustness.
The current implementation simply returns the allocation provided.
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
Add an API to GtkAccelLabel for hardcoding the accel key to be displayed
(ie: allowing us to bypass the GtkAccelGroup lookup).
Use that from the GMenuModel-based GtkMenu construction code instead of
passing around the accel group.
This makes accel labels work in bloatpad again.
This patch effectively removes any hope of automatic runtime accel
changes in GMenuModel-based menus without additional application
support but it leaves the door open for this to be supported again in
the future (if we decide that it's important).
https://bugzilla.gnome.org/show_bug.cgi?id=683738
There are no remaining users of the GActionMuxer in GtkApplicationWindow
because they've all been ported over to using the one on GtkWidget (via
GtkActionHelper, for the most part).
There are no remaining users of the GtkApplicationWindow API to create
GSimpleActionObserver or to get the GActionObservable (ie: muxer) for
the appwindow. Drop those APIs.
Drop the explicit passing of GActionGroup into the GtkMenu(Bar)
constructors and operate from the action context instead.
With GtkMenuItem implementing GtkActionable, this turns out to be pretty
easy (and most of the code can be removed from GtkModelMenuItem,
including the GActionObserver implementation).
Each GtkWindow with an associated GtkApplication should add this as
"app" to its action context. Each GtkApplicationWindow is its own
GActionGroup, and it should add itself to itself with the prefix "win".
There is now some duplication here because we have the new GActionMuxer
hierarchy managed by GtkWidget, but GtkApplicationWindow still carries
its own muxer. The redundancy will be removed in a future patch.
GApplication now makes the session bus and object path available as a
public API on the application instance. Use that instead of trying to
guess values for ourselves.
This causes this version of Gtk+ to depend on GLib 2.32.2, so bumping
version dependency accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
Try to fetch the name from the application desktop file for the
fallback menu if possible, instead of forcing applications to use
g_set_application_name or hardcoding "Application".
https://bugzilla.gnome.org/show_bug.cgi?id=673882
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
GtkApplication adds to the global accel map using the prefix <Actions>
which is also used by GtkAction. This causes GtkApplicationWindow to
try to parse GtkAction-added accels as if they were its own (which
fails).
Switch to a different namespace -- <GAction>/.
https://bugzilla.gnome.org/show_bug.cgi?id=668367
When finding the width for a given height, we can pass the full
height to both the menubar and the content. Instead, give the
menubar its minimum height, and give the rest to the content.
The code was not properly removing the menubar height from the
height given to the content, causing the statusbar to drop off
the bottom of the window in some examples.
Replace all references to g_application_set_app_menu and
g_application_set_menubar by their gtk variants, which
actually exist. Pointed out in bug 667546
This is the interface for GtkWidgets that can be associated with an
action on a GtkAppicationWindow or associated GtkApplication.
It essentially features 'action-name' and 'action-target' properties
with some associated convenience API.
This interface is implemented by GtkButton and GtkToolButton.
https://bugzilla.gnome.org/show_bug.cgi?id=667394
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
Deal with remote action invocations correctly by implementing
GRemoteActionGroup in the same way that GApplication does and pushing
remote activations through the before/after_emit functions of the
GApplication associated with the window.
This is the last part of getting the threading situation right.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
We want accelerators to work, even if the menus are not shown
locally, so we can't rely on the GtkMenu code to set them up
for us. Currently, this code only installs accelerators when the
window is realized.
Put this in a separate file and substantially refactor it.
Move handling of submenu creation into gtkmodelmenuitem where it
belongs.
Improve our handling of when to show separators or not.
