AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
9dbd137ec8
gtk2/gtk/gtkmenutrackeritem.c

1071 lines
34 KiB
C
Raw Normal View History

add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
/*
* Copyright © 2013 Canonical Limited
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the licence, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Changed obsolete FSF portal addresses to web address Fixed https://bugzilla.gnome.org/show_bug.cgi?id=721530
2014-01-12 12:56:49 +00:00
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
*
* Author: Ryan Lortie <desrt@desrt.ca>
*/
#include "config.h"
Rename a bunch of private headers We want to follow the convention that all private headers have names ending in private.h
2019-06-10 03:10:13 +00:00
#include "gtkmenutrackeritemprivate.h"
Rename GtkActionMuxer's private header Follow the naming policy for private headers.
2018-02-02 09:13:10 +00:00
#include "gtkactionmuxerprivate.h"
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
#include "gtkdebug.h"
Some more interning This avoids more strdups at startup.
2017-11-18 13:18:11 +00:00
#include "gtkintl.h"
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
#include <string.h>
docs: mark gtkdoc blocks as private for internal only API
2014-01-22 02:47:34 +00:00
/*< private >
menutrackeritem: Remove SECTION This is private
2021-03-02 03:51:55 +00:00
* GtkMenuTrackerItem:
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
*
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* A GtkMenuTrackerItem is a small helper class used by GtkMenuTracker to
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
* represent menu items. It has one of three classes: normal item, separator,
* or submenu.
*
* If an item is one of the non-normal classes (submenu, separator), only the
* label of the item needs to be respected. Otherwise, all the properties
docs: use proper apostrophe https://wiki.gnome.org/Design/OS/Typography
2014-02-07 18:01:26 +00:00
* of the item contribute to the item’s appearance and state.
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
*
* Implementing the appearance of the menu item is up to toolkits, and certain
* toolkits may choose to ignore certain properties, like icon or accel. The
* role of the item determines its accessibility role, along with its
* decoration if the GtkMenuTrackerItem::toggled property is true. As an
* example, if the item has the role %GTK_MENU_TRACKER_ITEM_ROLE_CHECK and
* GtkMenuTrackerItem::toggled is %FALSE, its accessible role should be that of
* a check menu item, and no decoration should be drawn. But if
* GtkMenuTrackerItem::toggled is %TRUE, a checkmark should be drawn.
*
* All properties except for the two class-determining properties,
* GtkMenuTrackerItem::is-separator and GtkMenuTrackerItem::has-submenu are
* allowed to change, so listen to the notify signals to update your item's
* appearance. When using a GObject library, this can conveniently be done
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* with g_object_bind_property() and GBinding, and this is how this is
* implemented in GTK; the appearance side is implemented in GtkModelMenuItem.
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
*
* When an item is clicked, simply call gtk_menu_tracker_item_activated() in
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* response. The GtkMenuTrackerItem will take care of everything related to
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
* activating the item and will itself update the state of all items in
* response.
*
* Submenus are a special case of menu item. When an item is a submenu, you
* should create a submenu for it with gtk_menu_tracker_new_item_for_submenu(),
* and apply the same menu tracking logic you would for a toplevel menu.
* Applications using submenus may want to lazily build their submenus in
* response to the user clicking on it, as building a submenu may be expensive.
*
docs: use proper apostrophe https://wiki.gnome.org/Design/OS/Typography
2014-02-07 18:01:26 +00:00
* Thus, the submenu has two special controls -- the submenu’s visibility
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
* should be controlled by the GtkMenuTrackerItem::submenu-shown property,
* and if a user clicks on the submenu, do not immediately show the menu,
* but call gtk_menu_tracker_item_request_submenu_shown() and wait for the
* GtkMenuTrackerItem::submenu-shown property to update. If the user navigates,
* the application may want to be notified so it can cancel the expensive
* operation that it was using to build the submenu. Thus,
* gtk_menu_tracker_item_request_submenu_shown() takes a boolean parameter.
* Use %TRUE when the user wants to open the submenu, and %FALSE when the
* user wants to close the submenu.
*/
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
typedef GObjectClass GtkMenuTrackerItemClass;
struct _GtkMenuTrackerItem
{
GObject parent_instance;
GtkActionObservable *observable;
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *action_namespace;
char *action_and_target;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GMenuItem *item;
GtkMenuTrackerItemRole role : 4;
guint is_separator : 1;
guint can_activate : 1;
guint sensitive : 1;
guint toggled : 1;
guint submenu_shown : 1;
guint submenu_requested : 1;
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
guint hidden_when : 2;
guint is_visible : 1;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
};
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
#define HIDDEN_NEVER 0
#define HIDDEN_WHEN_MISSING 1
#define HIDDEN_WHEN_DISABLED 2
GtkMenuTracker: add hidden-when='macos-menubar' Provide a mechanism for hiding the "Quit", "About" and "Preferences" menu items from the normal places in a traditional menubar layout (in the File and Edit menus) when the menu is being rendered in the Mac OS menubar. These items can already be found in the application menu. With this feature, applications can now define a single menu to use in all 'traditional' scenarios. Use this new attribute in Bloatpad. https://bugzilla.gnome.org/show_bug.cgi?id=741610
2014-12-16 17:14:23 +00:00
#define HIDDEN_WHEN_ALWAYS 3
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
enum {
PROP_0,
PROP_IS_SEPARATOR,
PROP_LABEL,
Add support for pango markup in menu items Before https://gitlab.gnome.org/GNOME/gtk/-/commit/c4a2234a28456fda5034bbaa155a1f8f76a6bebc menu models could use markup for items and the markup would be parsed, but this was not intended behavior. This commit adds official support for using markup for menu items via the `use-markup` property. Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/4306
2021-10-07 09:32:31 +00:00
PROP_USE_MARKUP,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
PROP_ICON,
GtkMenuTrackerItem: Add support for verb-icons When rendering iconic sections, we want to use icons for verbs, and we want to differentiate these in the menu model, to keep the icon attribute reserved for nouns. https://bugzilla.gnome.org/show_bug.cgi?id=727477
2014-04-26 18:15:01 +00:00
PROP_VERB_ICON,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
PROP_SENSITIVE,
PROP_ROLE,
PROP_TOGGLED,
PROP_ACCEL,
PROP_SUBMENU_SHOWN,
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
PROP_IS_VISIBLE,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
N_PROPS
};
static GParamSpec *gtk_menu_tracker_item_pspecs[N_PROPS];
static void gtk_menu_tracker_item_init_observer_iface (GtkActionObserverInterface *iface);
G_DEFINE_TYPE_WITH_CODE (GtkMenuTrackerItem, gtk_menu_tracker_item, G_TYPE_OBJECT,
G_IMPLEMENT_INTERFACE (GTK_TYPE_ACTION_OBSERVER, gtk_menu_tracker_item_init_observer_iface))
GType
gtk_menu_tracker_item_role_get_type (void)
{
static gsize gtk_menu_tracker_item_role_type;
if (g_once_init_enter (&gtk_menu_tracker_item_role_type))
{
static const GEnumValue values[] = {
{ GTK_MENU_TRACKER_ITEM_ROLE_NORMAL, "GTK_MENU_TRACKER_ITEM_ROLE_NORMAL", "normal" },
{ GTK_MENU_TRACKER_ITEM_ROLE_CHECK, "GTK_MENU_TRACKER_ITEM_ROLE_CHECK", "check" },
{ GTK_MENU_TRACKER_ITEM_ROLE_RADIO, "GTK_MENU_TRACKER_ITEM_ROLE_RADIO", "radio" },
{ 0, NULL, NULL }
};
GType type;
Some more interning This avoids more strdups at startup.
2017-11-18 13:18:11 +00:00
type = g_enum_register_static (I_("GtkMenuTrackerItemRole"), values);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_once_init_leave (&gtk_menu_tracker_item_role_type, type);
}
return gtk_menu_tracker_item_role_type;
}
static void
gtk_menu_tracker_item_get_property (GObject *object,
guint prop_id,
GValue *value,
GParamSpec *pspec)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (object);
switch (prop_id)
{
case PROP_IS_SEPARATOR:
g_value_set_boolean (value, gtk_menu_tracker_item_get_is_separator (self));
break;
case PROP_LABEL:
g_value_set_string (value, gtk_menu_tracker_item_get_label (self));
break;
Add support for pango markup in menu items Before https://gitlab.gnome.org/GNOME/gtk/-/commit/c4a2234a28456fda5034bbaa155a1f8f76a6bebc menu models could use markup for items and the markup would be parsed, but this was not intended behavior. This commit adds official support for using markup for menu items via the `use-markup` property. Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/4306
2021-10-07 09:32:31 +00:00
case PROP_USE_MARKUP:
g_value_set_boolean (value, gtk_menu_tracker_item_get_use_markup (self));
break;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
case PROP_ICON:
GtkMenuTrackerItem: Plug a memory leak gtk_menu_tracker_get_[verb_]icon both return a reference, so don't use g_value_set_object, which adds another one.
2014-06-29 02:39:43 +00:00
g_value_take_object (value, gtk_menu_tracker_item_get_icon (self));
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
break;
GtkMenuTrackerItem: Add support for verb-icons When rendering iconic sections, we want to use icons for verbs, and we want to differentiate these in the menu model, to keep the icon attribute reserved for nouns. https://bugzilla.gnome.org/show_bug.cgi?id=727477
2014-04-26 18:15:01 +00:00
case PROP_VERB_ICON:
GtkMenuTrackerItem: Plug a memory leak gtk_menu_tracker_get_[verb_]icon both return a reference, so don't use g_value_set_object, which adds another one.
2014-06-29 02:39:43 +00:00
g_value_take_object (value, gtk_menu_tracker_item_get_verb_icon (self));
GtkMenuTrackerItem: Add support for verb-icons When rendering iconic sections, we want to use icons for verbs, and we want to differentiate these in the menu model, to keep the icon attribute reserved for nouns. https://bugzilla.gnome.org/show_bug.cgi?id=727477
2014-04-26 18:15:01 +00:00
break;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
case PROP_SENSITIVE:
g_value_set_boolean (value, gtk_menu_tracker_item_get_sensitive (self));
break;
case PROP_ROLE:
g_value_set_enum (value, gtk_menu_tracker_item_get_role (self));
break;
case PROP_TOGGLED:
g_value_set_boolean (value, gtk_menu_tracker_item_get_toggled (self));
break;
case PROP_ACCEL:
g_value_set_string (value, gtk_menu_tracker_item_get_accel (self));
break;
case PROP_SUBMENU_SHOWN:
g_value_set_boolean (value, gtk_menu_tracker_item_get_submenu_shown (self));
break;
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
case PROP_IS_VISIBLE:
g_value_set_boolean (value, gtk_menu_tracker_item_get_is_visible (self));
break;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
static void
gtk_menu_tracker_item_finalize (GObject *object)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (object);
g_free (self->action_namespace);
GtkMenuTrackerItem: Plug a memory leak gtk_menu_tracker_get_[verb_]icon both return a reference, so don't use g_value_set_object, which adds another one.
2014-06-29 02:39:43 +00:00
g_free (self->action_and_target);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (self->observable)
g_object_unref (self->observable);
g_object_unref (self->item);
G_OBJECT_CLASS (gtk_menu_tracker_item_parent_class)->finalize (object);
}
static void
gtk_menu_tracker_item_init (GtkMenuTrackerItem * self)
{
}
static void
gtk_menu_tracker_item_class_init (GtkMenuTrackerItemClass *class)
{
class->get_property = gtk_menu_tracker_item_get_property;
class->finalize = gtk_menu_tracker_item_finalize;
gtk_menu_tracker_item_pspecs[PROP_IS_SEPARATOR] =
g_param_spec_boolean ("is-separator", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
gtk_menu_tracker_item_pspecs[PROP_LABEL] =
g_param_spec_string ("label", "", "", NULL, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
Add support for pango markup in menu items Before https://gitlab.gnome.org/GNOME/gtk/-/commit/c4a2234a28456fda5034bbaa155a1f8f76a6bebc menu models could use markup for items and the markup would be parsed, but this was not intended behavior. This commit adds official support for using markup for menu items via the `use-markup` property. Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/4306
2021-10-07 09:32:31 +00:00
gtk_menu_tracker_item_pspecs[PROP_USE_MARKUP] =
g_param_spec_boolean ("use-markup", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gtk_menu_tracker_item_pspecs[PROP_ICON] =
g_param_spec_object ("icon", "", "", G_TYPE_ICON, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
GtkMenuTrackerItem: Add support for verb-icons When rendering iconic sections, we want to use icons for verbs, and we want to differentiate these in the menu model, to keep the icon attribute reserved for nouns. https://bugzilla.gnome.org/show_bug.cgi?id=727477
2014-04-26 18:15:01 +00:00
gtk_menu_tracker_item_pspecs[PROP_VERB_ICON] =
g_param_spec_object ("verb-icon", "", "", G_TYPE_ICON, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gtk_menu_tracker_item_pspecs[PROP_SENSITIVE] =
g_param_spec_boolean ("sensitive", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
gtk_menu_tracker_item_pspecs[PROP_ROLE] =
g_param_spec_enum ("role", "", "",
GTK_TYPE_MENU_TRACKER_ITEM_ROLE, GTK_MENU_TRACKER_ITEM_ROLE_NORMAL,
G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
gtk_menu_tracker_item_pspecs[PROP_TOGGLED] =
g_param_spec_boolean ("toggled", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
gtk_menu_tracker_item_pspecs[PROP_ACCEL] =
g_param_spec_string ("accel", "", "", NULL, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
gtk_menu_tracker_item_pspecs[PROP_SUBMENU_SHOWN] =
g_param_spec_boolean ("submenu-shown", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
gtk_menu_tracker_item_pspecs[PROP_IS_VISIBLE] =
g_param_spec_boolean ("is-visible", "", "", FALSE, G_PARAM_STATIC_STRINGS | G_PARAM_READABLE);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_class_install_properties (class, N_PROPS, gtk_menu_tracker_item_pspecs);
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
}
/* This syncs up the visibility for the hidden-when='' case. We call it
* from the action observer functions on changes to the action group and
* on initialisation (via the action observer functions that are invoked
* at that time).
*/
static void
gtk_menu_tracker_item_update_visibility (GtkMenuTrackerItem *self)
{
gboolean visible;
switch (self->hidden_when)
{
case HIDDEN_NEVER:
visible = TRUE;
break;
case HIDDEN_WHEN_MISSING:
visible = self->can_activate;
break;
case HIDDEN_WHEN_DISABLED:
visible = self->sensitive;
break;
GtkMenuTracker: add hidden-when='macos-menubar' Provide a mechanism for hiding the "Quit", "About" and "Preferences" menu items from the normal places in a traditional menubar layout (in the File and Edit menus) when the menu is being rendered in the Mac OS menubar. These items can already be found in the application menu. With this feature, applications can now define a single menu to use in all 'traditional' scenarios. Use this new attribute in Bloatpad. https://bugzilla.gnome.org/show_bug.cgi?id=741610
2014-12-16 17:14:23 +00:00
case HIDDEN_WHEN_ALWAYS:
visible = FALSE;
break;
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
default:
g_assert_not_reached ();
}
if (visible != self->is_visible)
{
self->is_visible = visible;
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_IS_VISIBLE]);
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
gtk_menu_tracker_item_action_added (GtkActionObserver *observer,
GtkActionObservable *observable,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
const GVariantType *parameter_type,
gboolean enabled,
GVariant *state)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
GVariant *action_target;
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
gboolean old_sensitive;
gboolean old_toggled;
GtkMenuTrackerItemRole old_role;
guint n_changed;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s added", action_name));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
old_sensitive = self->sensitive;
old_toggled = self->toggled;
old_role = self->role;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
action_target = g_menu_item_get_attribute_value (self->item, G_MENU_ATTRIBUTE_TARGET, NULL);
self->can_activate = (action_target == NULL && parameter_type == NULL) ||
(action_target != NULL && parameter_type != NULL &&
g_variant_is_of_type (action_target, parameter_type));
if (!self->can_activate)
{
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s can't be activated due to parameter type mismatch "
"(parameter type %s, target type %s)",
action_name,
parameter_type ? g_variant_type_peek_string (parameter_type) : "NULL",
action_target ? g_variant_get_type_string (action_target) : "NULL"));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (action_target)
g_variant_unref (action_target);
return;
}
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s can be activated", action_name));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
self->sensitive = enabled;
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s is %s", action_name, enabled ? "enabled" : "disabled"));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (action_target != NULL && state != NULL)
{
self->toggled = g_variant_equal (state, action_target);
self->role = GTK_MENU_TRACKER_ITEM_ROLE_RADIO;
}
else if (state != NULL && g_variant_is_of_type (state, G_VARIANT_TYPE_BOOLEAN))
{
self->toggled = g_variant_get_boolean (state);
self->role = GTK_MENU_TRACKER_ITEM_ROLE_CHECK;
}
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
/* Avoid freeze/thaw_notify as they are quite expensive in runtime/memory
* unless we have more than one property to update. Additionally, only
* notify on properties that have changed to avoid extraneous signal
* emission. This code can get run a lot!
*/
n_changed = (old_role != self->role)
+ (old_toggled != self->toggled)
+ (old_sensitive != self->sensitive);
if (n_changed > 1)
g_object_freeze_notify (G_OBJECT (self));
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
if (self->sensitive != old_sensitive)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_SENSITIVE]);
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
if (self->toggled != old_toggled)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_TOGGLED]);
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
if (self->role != old_role)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_ROLE]);
menutracker: reduce allocations and signal emission When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot. That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times. Related #4422
2021-12-08 06:33:20 +00:00
if (n_changed > 1)
g_object_thaw_notify (G_OBJECT (self));
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (action_target)
g_variant_unref (action_target);
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
/* In case of hidden-when='', we want to Wait until after refreshing
* all of the properties to emit the signal that will cause the
* tracker to expose us (to prevent too much thrashing).
*/
gtk_menu_tracker_item_update_visibility (self);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
gtk_menu_tracker_item_action_enabled_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean enabled)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s: enabled changed to %d", action_name, enabled));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (!self->can_activate)
return;
if (self->sensitive == enabled)
return;
self->sensitive = enabled;
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_SENSITIVE]);
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
gtk_menu_tracker_item_update_visibility (self);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
gtk_menu_tracker_item_action_state_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GVariant *state)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
GVariant *action_target;
gboolean was_toggled;
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s: state changed", action_name));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (!self->can_activate)
return;
action_target = g_menu_item_get_attribute_value (self->item, G_MENU_ATTRIBUTE_TARGET, NULL);
was_toggled = self->toggled;
if (action_target)
{
self->toggled = g_variant_equal (state, action_target);
g_variant_unref (action_target);
}
else if (g_variant_is_of_type (state, G_VARIANT_TYPE_BOOLEAN))
self->toggled = g_variant_get_boolean (state);
else
self->toggled = FALSE;
if (self->toggled != was_toggled)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_TOGGLED]);
}
static void
gtk_menu_tracker_item_action_removed (GtkActionObserver *observer,
GtkActionObservable *observable,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
gboolean was_sensitive, was_toggled;
GtkMenuTrackerItemRole old_role;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s was removed", action_name));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (!self->can_activate)
return;
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
was_sensitive = self->sensitive;
was_toggled = self->toggled;
old_role = self->role;
GtkMenuTrackerItem: small logic tweak Strictly speaking, can_activate should always be set back to FALSE when the action disappears from the muxer (since we can't activate it anymore) but we forgot to do that. This 'bug' could never cause a problem because 'can_activate' is never directly queried for anything at all and the item would get marked insensitive anyway. As soon as the action was re-added, can_activate would be recalculated based on the new action before anything else could happen. All the same, this should be cleared here. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:04:53 +00:00
self->can_activate = FALSE;
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
self->sensitive = FALSE;
self->toggled = FALSE;
self->role = GTK_MENU_TRACKER_ITEM_ROLE_NORMAL;
GtkMenuTrackerItem: small logic tweak Strictly speaking, can_activate should always be set back to FALSE when the action disappears from the muxer (since we can't activate it anymore) but we forgot to do that. This 'bug' could never cause a problem because 'can_activate' is never directly queried for anything at all and the item would get marked insensitive anyway. As soon as the action was re-added, can_activate would be recalculated based on the new action before anything else could happen. All the same, this should be cleared here. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:04:53 +00:00
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
/* Backwards from adding: we want to remove ourselves from the menu
* -before- thrashing the properties.
*/
gtk_menu_tracker_item_update_visibility (self);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_freeze_notify (G_OBJECT (self));
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
if (was_sensitive)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_SENSITIVE]);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
if (was_toggled)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_TOGGLED]);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTracker: rework action removal a bit Refactor the code in the action observer remove function in order to make way for the (efficient) handling of hiding of the item in the case that hidden-when='' is given. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:11:24 +00:00
if (old_role != GTK_MENU_TRACKER_ITEM_ROLE_NORMAL)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_ROLE]);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_object_thaw_notify (G_OBJECT (self));
}
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
static void
gtk_menu_tracker_item_primary_accel_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name,
const char *action_and_target)
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
menutrackeritem: Be more careful with accel changes In some cases (such as when getting a new parent), the action muxer doesn't know exactly which detailed actions have changed accels, so we call primary_accel_changed with just an action name. Make the menu tracker item handle that case by matching either against the detailed name or the the action name.
2021-06-17 12:42:03 +00:00
const char *action;
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
menutrackeritem: Be more careful with accel changes In some cases (such as when getting a new parent), the action muxer doesn't know exactly which detailed actions have changed accels, so we call primary_accel_changed with just an action name. Make the menu tracker item handle that case by matching either against the detailed name or the the action name.
2021-06-17 12:42:03 +00:00
action = strrchr (self->action_and_target, '|') + 1;
if ((action_and_target && g_str_equal (action_and_target, self->action_and_target)) ||
(action_name && g_str_equal (action_name, action)))
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_ACCEL]);
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
static void
gtk_menu_tracker_item_init_observer_iface (GtkActionObserverInterface *iface)
{
iface->action_added = gtk_menu_tracker_item_action_added;
iface->action_enabled_changed = gtk_menu_tracker_item_action_enabled_changed;
iface->action_state_changed = gtk_menu_tracker_item_action_state_changed;
iface->action_removed = gtk_menu_tracker_item_action_removed;
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
iface->primary_accel_changed = gtk_menu_tracker_item_primary_accel_changed;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
GtkMenuTrackerItem *
_gtk_menu_tracker_item_new (GtkActionObservable *observable,
GMenuModel *model,
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int item_index,
GtkMenuTracker: add hidden-when='macos-menubar' Provide a mechanism for hiding the "Quit", "About" and "Preferences" menu items from the normal places in a traditional menubar layout (in the File and Edit menus) when the menu is being rendered in the Mac OS menubar. These items can already be found in the application menu. With this feature, applications can now define a single menu to use in all 'traditional' scenarios. Use this new attribute in Bloatpad. https://bugzilla.gnome.org/show_bug.cgi?id=741610
2014-12-16 17:14:23 +00:00
gboolean mac_os_mode,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_namespace,
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean is_separator)
{
GtkMenuTrackerItem *self;
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name;
const char *hidden_when;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_return_val_if_fail (GTK_IS_ACTION_OBSERVABLE (observable), NULL);
g_return_val_if_fail (G_IS_MENU_MODEL (model), NULL);
self = g_object_new (GTK_TYPE_MENU_TRACKER_ITEM, NULL);
self->item = g_menu_item_new_from_model (model, item_index);
self->action_namespace = g_strdup (action_namespace);
self->observable = g_object_ref (observable);
self->is_separator = is_separator;
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
if (!is_separator && g_menu_item_get_attribute (self->item, "hidden-when", "&s", &hidden_when))
{
if (g_str_equal (hidden_when, "action-disabled"))
self->hidden_when = HIDDEN_WHEN_DISABLED;
else if (g_str_equal (hidden_when, "action-missing"))
self->hidden_when = HIDDEN_WHEN_MISSING;
GtkMenuTracker: add hidden-when='macos-menubar' Provide a mechanism for hiding the "Quit", "About" and "Preferences" menu items from the normal places in a traditional menubar layout (in the File and Edit menus) when the menu is being rendered in the Mac OS menubar. These items can already be found in the application menu. With this feature, applications can now define a single menu to use in all 'traditional' scenarios. Use this new attribute in Bloatpad. https://bugzilla.gnome.org/show_bug.cgi?id=741610
2014-12-16 17:14:23 +00:00
else if (mac_os_mode && g_str_equal (hidden_when, "macos-menubar"))
self->hidden_when = HIDDEN_WHEN_ALWAYS;
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
/* Ignore other values -- this code may be running in context of a
* desktop shell or the like and should not spew criticals due to
* application bugs...
*
* Note: if we just set a hidden-when state, but don't get the
* action_name below then our visibility will be FALSE forever.
* That's to be expected since the action is missing...
*/
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (!is_separator && g_menu_item_get_attribute (self->item, "action", "&s", &action_name))
{
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
GtkActionMuxer *muxer = GTK_ACTION_MUXER (observable);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
const GVariantType *parameter_type;
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
GVariant *target;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean enabled;
GVariant *state;
gboolean found;
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
target = g_menu_item_get_attribute_value (self->item, "target", NULL);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
self->action_and_target = gtk_print_action_and_target (action_namespace, action_name, target);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
if (target)
g_variant_unref (target);
action_name = strrchr (self->action_and_target, '|') + 1;
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
GTK_NOTE(ACTIONS,
if (!strchr (action_name, '.'))
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
g_message ("menutracker: action name %s doesn't look like 'app.' or 'win.'; "
"it is unlikely to work", action_name));
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
state = NULL;
gtk_action_observable_register_observer (self->observable, action_name, GTK_ACTION_OBSERVER (self));
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
found = gtk_action_muxer_query_action (muxer, action_name, &enabled, &parameter_type, NULL, NULL, &state);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (found)
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
{
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s existed from the start", action_name));
menu tracker item: Improve logging Pass the action name along, so we can put it in log messages.
2019-06-16 01:38:12 +00:00
gtk_menu_tracker_item_action_added (GTK_ACTION_OBSERVER (self), observable, action_name, parameter_type, enabled, state);
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
else
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
{
Better debug messages for actions Unify the debug messages between actionhelper and menutracker, and add some more context to some of them.
2016-03-11 17:19:47 +00:00
GTK_NOTE(ACTIONS, g_message ("menutracker: action %s missing from the start", action_name));
GtkMenuTracker: one more visibility tweak On creation, we call action_removed() in case the action was missing from the start. Because we just created the action, 'can_activate' will always be FALSE here and this function will therefore always do nothing. We do want the visibility state to be updated though, for the case where the action is missing but the item should still be visible from the start. Update the visibility directly instead of trying to call action_removed(). https://bugzilla.gnome.org/show_bug.cgi?id=735122
2014-08-20 20:00:14 +00:00
gtk_menu_tracker_item_update_visibility (self);
GtkMenuTrackerItem: introduce action debugging Add some action debugging output for GtkMenuTrackerItem as well... https://bugzilla.gnome.org/show_bug.cgi?id=733965
2014-07-30 10:28:21 +00:00
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (state)
g_variant_unref (state);
}
else
GtkMenuTrackerItem: fix submenu visibility flag We were only properly setting the "is-visible" flag to TRUE for menu items with associated actions and not (for example) on submenus. This was fine because the code for building GtkMenus from models (correctly) assumed that submenus should always be visible and never checked the property. This is not true for the Mac OS code, which actually checked the property and found it to be false for submenus. Initialise the property to TRUE so that we get the correct value reported for items that don't have actions. https://bugzilla.gnome.org/show_bug.cgi?id=735122
2014-08-20 19:43:09 +00:00
{
gtk_menu_tracker_item_update_visibility (self);
self->sensitive = TRUE;
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
return self;
}
GtkActionObservable *
_gtk_menu_tracker_item_get_observable (GtkMenuTrackerItem *self)
{
return self->observable;
}
docs: mark gtkdoc blocks as private for internal only API
2014-01-22 02:47:34 +00:00
/*< private >
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
* gtk_menu_tracker_item_get_is_separator:
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* @self: A GtkMenuTrackerItem instance
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
*
docs: avoid ambiguous return tags
2014-01-21 00:15:34 +00:00
* Returns: whether the menu item is a separator. If so, only
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
* certain properties may need to be obeyed. See the documentation
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* for GtkMenuTrackerItem.
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
*/
gboolean
gtk_menu_tracker_item_get_is_separator (GtkMenuTrackerItem *self)
{
return self->is_separator;
}
docs: mark gtkdoc blocks as private for internal only API
2014-01-22 02:47:34 +00:00
/*< private >
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
* gtk_menu_tracker_item_get_has_submenu:
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* @self: A GtkMenuTrackerItem instance
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
*
docs: avoid ambiguous return tags
2014-01-21 00:15:34 +00:00
* Returns: whether the menu item has a submenu. If so, only
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
* certain properties may need to be obeyed. See the documentation
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* for GtkMenuTrackerItem.
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
*/
gboolean
GtkMenuTracker: don't specialise "submenu" link We have some API in GtkMenuTracker and GtkMenuTrackerItem that is specifically designed to deal with submenus. Generalise these APIs to take a 'link_name' parameter that we always give as G_MENU_SUBMENU for now. In the future, this will allow creating trackers for other types of links, such as sections.
2014-04-28 12:01:35 +00:00
gtk_menu_tracker_item_get_has_link (GtkMenuTrackerItem *self,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *link_name)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
GMenuModel *link;
GtkMenuTracker: don't specialise "submenu" link We have some API in GtkMenuTracker and GtkMenuTrackerItem that is specifically designed to deal with submenus. Generalise these APIs to take a 'link_name' parameter that we always give as G_MENU_SUBMENU for now. In the future, this will allow creating trackers for other types of links, such as sections.
2014-04-28 12:01:35 +00:00
link = g_menu_item_get_link (self->item, link_name);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (link)
{
g_object_unref (link);
return TRUE;
}
else
return FALSE;
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gtk_menu_tracker_item_get_label (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *label = NULL;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
g_menu_item_get_attribute (self->item, G_MENU_ATTRIBUTE_LABEL, "&s", &label);
return label;
}
Add support for pango markup in menu items Before https://gitlab.gnome.org/GNOME/gtk/-/commit/c4a2234a28456fda5034bbaa155a1f8f76a6bebc menu models could use markup for items and the markup would be parsed, but this was not intended behavior. This commit adds official support for using markup for menu items via the `use-markup` property. Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/4306
2021-10-07 09:32:31 +00:00
gboolean
gtk_menu_tracker_item_get_use_markup (GtkMenuTrackerItem *self)
{
return g_menu_item_get_attribute (self->item, "use-markup", "&s", NULL);
}
docs: mark gtkdoc blocks as private for internal only API
2014-01-22 02:47:34 +00:00
/*< private >
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
* gtk_menu_tracker_item_get_icon:
*
* Returns: (transfer full):
*/
GIcon *
gtk_menu_tracker_item_get_icon (GtkMenuTrackerItem *self)
{
GVariant *icon_data;
GIcon *icon;
icon_data = g_menu_item_get_attribute_value (self->item, "icon", NULL);
if (icon_data == NULL)
return NULL;
icon = g_icon_deserialize (icon_data);
g_variant_unref (icon_data);
return icon;
}
GtkMenuTrackerItem: Add support for verb-icons When rendering iconic sections, we want to use icons for verbs, and we want to differentiate these in the menu model, to keep the icon attribute reserved for nouns. https://bugzilla.gnome.org/show_bug.cgi?id=727477
2014-04-26 18:15:01 +00:00
/*< private >
* gtk_menu_tracker_item_get_verb_icon:
*
* Returns: (transfer full):
*/
GIcon *
gtk_menu_tracker_item_get_verb_icon (GtkMenuTrackerItem *self)
{
GVariant *icon_data;
GIcon *icon;
icon_data = g_menu_item_get_attribute_value (self->item, "verb-icon", NULL);
if (icon_data == NULL)
return NULL;
icon = g_icon_deserialize (icon_data);
g_variant_unref (icon_data);
return icon;
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean
gtk_menu_tracker_item_get_sensitive (GtkMenuTrackerItem *self)
{
return self->sensitive;
}
GtkMenuTrackerItemRole
gtk_menu_tracker_item_get_role (GtkMenuTrackerItem *self)
{
return self->role;
}
gboolean
gtk_menu_tracker_item_get_toggled (GtkMenuTrackerItem *self)
{
return self->toggled;
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gtk_menu_tracker_item_get_accel (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *accel;
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
if (!self->action_and_target)
return NULL;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
if (g_menu_item_get_attribute (self->item, "accel", "&s", &accel))
return accel;
if (!GTK_IS_ACTION_MUXER (self->observable))
return NULL;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem: add support for dynamic accels Add support for pulling the primary accel out of the GtkActionMuxer. With this change, it is no longer necessary to have the accel='' attribute hardcoded onto each menu item (and, in fact, it should be left off if you intend to have support for dynamic accelerator changing). Specifying accel='' is a good way to force an accelerator not to be displayed on a menu item.
2013-07-10 02:50:14 +00:00
return gtk_action_muxer_get_primary_accel (GTK_ACTION_MUXER (self->observable), self->action_and_target);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *
GtkMenuTracker: add 'special' items Allow the possibility for items to be marked with a special attribute and expose this via GtkTrackerMenuItem. For internal use only. We will use this to implement the special 'Hide', 'Hide Others' and 'Show All' items and the 'Services' submenu in the Mac OS application menu. https://bugzilla.gnome.org/show_bug.cgi?id=720552
2013-12-15 02:56:26 +00:00
gtk_menu_tracker_item_get_special (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *special = NULL;
GtkMenuTracker: add 'special' items Allow the possibility for items to be marked with a special attribute and expose this via GtkTrackerMenuItem. For internal use only. We will use this to implement the special 'Hide', 'Hide Others' and 'Show All' items and the 'Services' submenu in the Mac OS application menu. https://bugzilla.gnome.org/show_bug.cgi?id=720552
2013-12-15 02:56:26 +00:00
g_menu_item_get_attribute (self->item, "x-gtk-private-special", "&s", &special);
return special;
}
popovermenu: Allow custom items Add a way to add children at certain places in the generated menu for both GtkPopoverMenu and GtkPopoverMenuBar. New apis: gtk_popover_menu_add_child gtk_popover_menu_remove_child gtk_popover_menu_bar_add_child gtk_popover_menu_bar_remove_child Fixes: #3260
2020-10-20 18:26:45 +00:00
const char *
gtk_menu_tracker_item_get_custom (GtkMenuTrackerItem *self)
{
const char *custom = NULL;
g_menu_item_get_attribute (self->item, "custom", "&s", &custom);
return custom;
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *
GtkMenuTrackerItem: Add support for display-hint This commit adds a getter for the display-hint attribute.
2014-04-28 18:18:06 +00:00
gtk_menu_tracker_item_get_display_hint (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *display_hint = NULL;
GtkMenuTrackerItem: Add support for display-hint This commit adds a getter for the display-hint attribute.
2014-04-28 18:18:06 +00:00
g_menu_item_get_attribute (self->item, "display-hint", "&s", &display_hint);
return display_hint;
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *
menusectionbox: add support for "text-direction" attribute This allows the use of a "text-direction" hint set to one of "none", "rtl", or "ltr" to enforce the text direction of a "horizontal-buttons" display-hint. This is useful when a menu has buttons that map to physical space in the UI and therefore must match the application widgetry. https://bugzilla.gnome.org/show_bug.cgi?id=772775
2016-10-12 20:56:57 +00:00
gtk_menu_tracker_item_get_text_direction (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *text_direction = NULL;
menusectionbox: add support for "text-direction" attribute This allows the use of a "text-direction" hint set to one of "none", "rtl", or "ltr" to enforce the text direction of a "horizontal-buttons" display-hint. This is useful when a menu has buttons that map to physical space in the UI and therefore must match the application widgetry. https://bugzilla.gnome.org/show_bug.cgi?id=772775
2016-10-12 20:56:57 +00:00
g_menu_item_get_attribute (self->item, "text-direction", "&s", &text_direction);
return text_direction;
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GMenuModel *
GtkMenuTracker: don't specialise "submenu" link We have some API in GtkMenuTracker and GtkMenuTrackerItem that is specifically designed to deal with submenus. Generalise these APIs to take a 'link_name' parameter that we always give as G_MENU_SUBMENU for now. In the future, this will allow creating trackers for other types of links, such as sections.
2014-04-28 12:01:35 +00:00
_gtk_menu_tracker_item_get_link (GtkMenuTrackerItem *self,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *link_name)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
GtkMenuTracker: don't specialise "submenu" link We have some API in GtkMenuTracker and GtkMenuTrackerItem that is specifically designed to deal with submenus. Generalise these APIs to take a 'link_name' parameter that we always give as G_MENU_SUBMENU for now. In the future, this will allow creating trackers for other types of links, such as sections.
2014-04-28 12:01:35 +00:00
return g_menu_item_get_link (self->item, link_name);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *
GtkMenuTracker: don't specialise "submenu" link We have some API in GtkMenuTracker and GtkMenuTrackerItem that is specifically designed to deal with submenus. Generalise these APIs to take a 'link_name' parameter that we always give as G_MENU_SUBMENU for now. In the future, this will allow creating trackers for other types of links, such as sections.
2014-04-28 12:01:35 +00:00
_gtk_menu_tracker_item_get_link_namespace (GtkMenuTrackerItem *self)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *namespace;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (g_menu_item_get_attribute (self->item, "action-namespace", "&s", &namespace))
{
if (self->action_namespace)
return g_strjoin (".", self->action_namespace, namespace, NULL);
else
return g_strdup (namespace);
}
else
return g_strdup (self->action_namespace);
}
gboolean
gtk_menu_tracker_item_get_should_request_show (GtkMenuTrackerItem *self)
{
return g_menu_item_get_attribute (self->item, "submenu-action", "&s", NULL);
}
gboolean
gtk_menu_tracker_item_get_submenu_shown (GtkMenuTrackerItem *self)
{
return self->submenu_shown;
}
static void
gtk_menu_tracker_item_set_submenu_shown (GtkMenuTrackerItem *self,
gboolean submenu_shown)
{
if (submenu_shown == self->submenu_shown)
return;
self->submenu_shown = submenu_shown;
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_SUBMENU_SHOWN]);
}
void
gtk_menu_tracker_item_activated (GtkMenuTrackerItem *self)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *action_name;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GVariant *action_target;
g_return_if_fail (GTK_IS_MENU_TRACKER_ITEM (self));
if (!self->can_activate)
return;
GtkMenuTrackerItem: use "action and target" format Store "action and target" format inside each GtkMenuTrackerItem. This makes action invocation more efficient (no hash table lookups or allocations) and slightly simplifies handling of action namespace. More importantly, this will be used when we start to get accels from GtkActionMuxer.
2013-07-10 02:48:29 +00:00
action_name = strrchr (self->action_and_target, '|') + 1;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
action_target = g_menu_item_get_attribute_value (self->item, G_MENU_ATTRIBUTE_TARGET, NULL);
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
gtk_action_muxer_activate_action (GTK_ACTION_MUXER (self->observable), action_name, action_target);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (action_target)
g_variant_unref (action_target);
}
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
typedef struct {
GObject parent;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
GtkMenuTrackerItem *item;
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *submenu_action;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean first_time;
} GtkMenuTrackerOpener;
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
typedef struct {
GObjectClass parent_class;
} GtkMenuTrackerOpenerClass;
static void gtk_menu_tracker_opener_observer_iface_init (GtkActionObserverInterface *iface);
GType gtk_menu_tracker_opener_get_type (void) G_GNUC_CONST;
G_DEFINE_TYPE_WITH_CODE (GtkMenuTrackerOpener, gtk_menu_tracker_opener, G_TYPE_OBJECT,
G_IMPLEMENT_INTERFACE (GTK_TYPE_ACTION_OBSERVER, gtk_menu_tracker_opener_observer_iface_init))
static void
gtk_menu_tracker_opener_init (GtkMenuTrackerOpener *self)
{
}
static void
gtk_menu_tracker_opener_finalize (GObject *object)
{
GtkMenuTrackerOpener *opener = (GtkMenuTrackerOpener *)object;
gtk_action_observable_unregister_observer (opener->item->observable,
opener->submenu_action,
(GtkActionObserver *)opener);
if (GTK_IS_ACTION_MUXER (opener->item->observable))
gtk_action_muxer_change_action_state (GTK_ACTION_MUXER (opener->item->observable),
opener->submenu_action,
g_variant_new_boolean (FALSE));
gtk_menu_tracker_item_set_submenu_shown (opener->item, FALSE);
g_free (opener->submenu_action);
G_OBJECT_CLASS (gtk_menu_tracker_opener_parent_class)->finalize (object);
}
static void
gtk_menu_tracker_opener_class_init (GtkMenuTrackerOpenerClass *class)
{
G_OBJECT_CLASS (class)->finalize = gtk_menu_tracker_opener_finalize;
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
static void
gtk_menu_tracker_opener_update (GtkMenuTrackerOpener *opener)
{
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
GtkActionMuxer *muxer = GTK_ACTION_MUXER (opener->item->observable);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gboolean is_open = TRUE;
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
GVariant *state;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
/* We consider the menu as being "open" if the action does not exist
* or if there is another problem (no state, wrong state type, etc.).
* If the action exists, with the correct state then we consider it
* open if we have ever seen this state equal to TRUE.
*
* In the event that we see the state equal to FALSE, we force it back
* to TRUE. We do not signal that the menu was closed because this is
* likely to create UI thrashing.
*
* The only way the menu can have a true-to-false submenu-shown
* transition is if the user calls _request_submenu_shown (FALSE).
* That is handled in _free() below.
*/
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
if (gtk_action_muxer_query_action (muxer, opener->submenu_action, NULL, NULL, NULL, NULL, &state))
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
if (state)
{
if (g_variant_is_of_type (state, G_VARIANT_TYPE_BOOLEAN))
is_open = g_variant_get_boolean (state);
g_variant_unref (state);
}
}
/* If it is already open, signal that.
*
* If it is not open, ask it to open.
*/
if (is_open)
gtk_menu_tracker_item_set_submenu_shown (opener->item, TRUE);
if (!is_open || opener->first_time)
{
actionmuxer: Port internal users Port all internal users of the action muxer from the GActionGroup interface to the new action muxer apis.
2020-07-19 02:30:02 +00:00
gtk_action_muxer_change_action_state (muxer, opener->submenu_action, g_variant_new_boolean (TRUE));
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
opener->first_time = FALSE;
}
}
static void
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_added (GtkActionObserver *observer,
GtkActionObservable *observable,
const char *action_name,
const GVariantType *parameter_type,
gboolean enabled,
GVariant *state)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_update ((GtkMenuTrackerOpener *)observer);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_removed (GtkActionObserver *observer,
GtkActionObservable *observable,
const char *action_name)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_update ((GtkMenuTrackerOpener *)observer);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_enabled_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
const char *action_name,
gboolean enabled)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_update ((GtkMenuTrackerOpener *)observer);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static void
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_state_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
const char *action_name,
GVariant *state)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_menu_tracker_opener_update ((GtkMenuTrackerOpener *)observer);
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
static void
gtk_menu_tracker_opener_observer_iface_init (GtkActionObserverInterface *iface)
{
iface->action_added = gtk_menu_tracker_opener_added;
iface->action_removed = gtk_menu_tracker_opener_removed;
iface->action_enabled_changed = gtk_menu_tracker_opener_enabled_changed;
iface->action_state_changed = gtk_menu_tracker_opener_state_changed;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
static GtkMenuTrackerOpener *
gtk_menu_tracker_opener_new (GtkMenuTrackerItem *item,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *submenu_action)
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
{
GtkMenuTrackerOpener *opener;
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
opener = g_object_new (gtk_menu_tracker_opener_get_type (), NULL);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
opener->first_time = TRUE;
opener->item = item;
if (item->action_namespace)
opener->submenu_action = g_strjoin (".", item->action_namespace, submenu_action, NULL);
else
opener->submenu_action = g_strdup (submenu_action);
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
gtk_action_observable_register_observer (item->observable,
opener->submenu_action,
(GtkActionObserver *)opener);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
gtk_menu_tracker_opener_update (opener);
return opener;
}
void
gtk_menu_tracker_item_request_submenu_shown (GtkMenuTrackerItem *self,
gboolean shown)
{
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *submenu_action;
gtkmenutrackeritem: Simplify the submenu opening API Instead of making clients inspect the submenu action and decide what to do based upon that, always request the submenu open and let the tracker decide what to do.
2013-05-13 19:52:21 +00:00
gboolean has_submenu_action;
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
if (shown == self->submenu_requested)
return;
gtkmenutrackeritem: Simplify the submenu opening API Instead of making clients inspect the submenu action and decide what to do based upon that, always request the submenu open and let the tracker decide what to do.
2013-05-13 19:52:21 +00:00
has_submenu_action = g_menu_item_get_attribute (self->item, "submenu-action", "&s", &submenu_action);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
self->submenu_requested = shown;
gtkmenutrackeritem: Simplify the submenu opening API Instead of making clients inspect the submenu action and decide what to do based upon that, always request the submenu open and let the tracker decide what to do.
2013-05-13 19:52:21 +00:00
/* If we have a submenu action, start a submenu opener and wait
* for the reply from the client. Otherwise, simply open the
* submenu immediately.
*/
if (has_submenu_action)
{
if (shown)
g_object_set_data_full (G_OBJECT (self), "submenu-opener",
gtk_menu_tracker_opener_new (self, submenu_action),
menutrackeritem: Make submenu-actions work again This broke when GtkActionMuxer stopped being a GActionGroup.
2021-03-08 05:45:35 +00:00
g_object_unref);
gtkmenutrackeritem: Simplify the submenu opening API Instead of making clients inspect the submenu action and decide what to do based upon that, always request the submenu open and let the tracker decide what to do.
2013-05-13 19:52:21 +00:00
else
g_object_set_data (G_OBJECT (self), "submenu-opener", NULL);
}
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
else
gtkmenutrackeritem: Simplify the submenu opening API Instead of making clients inspect the submenu action and decide what to do based upon that, always request the submenu open and let the tracker decide what to do.
2013-05-13 19:52:21 +00:00
gtk_menu_tracker_item_set_submenu_shown (self, shown);
add GtkMenuTrackerItem Add a new class, GtkMenuTrackerItem that represents a menu item, to be used with GtkMenuTracker. GtkMenuTracker's insert callback now works in terms of this new type (instead of passing reference to the model and an index to the item). GtkMenuShell now handles all of the binding tasks internally, mostly through the use of property bindings. Having bindings for the label and visibility attributes, in partiular, will help with supporting upcoming extensions to GMenuModel. GtkModelMenu has been reduced to a helper class that has nothing to do with GMenuModel. It represents something closer to an "ideal" API for GtkMenuItem if we didn't have compatibility concerns (eg: not emitting "activate" when setting toggle state, no separate subclasses per menu item type, supporting icons, etc.) Improvements to GtkMenuItem could eventually shrink the size of this class or remove the need for it entirely. Some GtkActionHelper functionality has been duplicated in GtkMenuTracker, which is suboptimal. The duplication exists so that other codebases (such as Unity and gnome-shell) can reuse the GtkMenuTracker code, whereas GtkActionHelper is very much tied to GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs. supporting the full range of GMenuModel features for menu items turns out to be two overlapping but not entirely similar problems. Some of the duplication (such as roles) can be removed from GtkActionHelper once Gtk's internal Mac OS menubar support is ported to GtkMenuTracker. The intent to reuse the code outside of Gtk is also the reason for the unusual treatment of the enum type introduced in this comment. This adds no new "public" API to the Gtk library, other than types that we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
}
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
gtk: Documentation fixups Document missing symbols, and other cleanups.
2020-06-06 01:36:27 +00:00
/*
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
* gtk_menu_tracker_item_get_is_visible:
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* @self: A GtkMenuTrackerItem instance
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
*
* Don't use this unless you're tracking items for yourself -- normally
* the tracker will emit add/remove automatically when this changes.
*
* Returns: if the item should currently be shown
*/
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
gboolean
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
gtk_menu_tracker_item_get_is_visible (GtkMenuTrackerItem *self)
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
{
return self->is_visible;
}
gtk: Documentation fixups Document missing symbols, and other cleanups.
2020-06-06 01:36:27 +00:00
/*
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
* gtk_menu_tracker_item_may_disappear:
gtk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 13:17:04 +00:00
* @self: A GtkMenuTrackerItem instance
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
*
* Returns: if the item may disappear (ie: is-visible property may change)
*/
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
gboolean
GtkMenuTracker: make "is-visible" a property Make this a property just like all of the other things and make the APIs for accessing it non-private (but add a note that they are not intended to be used).
2014-04-28 08:12:51 +00:00
gtk_menu_tracker_item_may_disappear (GtkMenuTrackerItem *self)
GtkMenuTrackerItem: add an internal 'visible' flag Add an internal API for checking if a GtkMenuTrackerItem is visible, along with a signal for reporting changes in that flag. The item will become invisible in situations according to the new hidden-when='' attribute, which can be set to 'action-disabled' or 'action-missing'. This new flag doesn't actually do anything yet, and none of the consumers of GtkMenuTracker do anything with it (nor should they). A followup patch will address the issue. https://bugzilla.gnome.org/show_bug.cgi?id=688421
2014-01-04 07:25:43 +00:00
{
return self->hidden_when != HIDDEN_NEVER;
}
Reference in New Issue Copy Permalink