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

982 lines
31 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"
#include "gtkmenutrackeritem.h"
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
#include "gtkactionmuxer.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"
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 "gtkactionmuxer.h"
#include <string.h>
docs: mark gtkdoc blocks as private for internal only API
2014-01-22 02:47:34 +00:00
/*< private >
Add some usage docs for the new private copy/paste APIs
2013-05-13 19:11:41 +00:00
* SECTION:gtkmenutrackeritem
* @Title: GtkMenuTrackerItem
* @Short_description: Small helper for model menu items
*
* A #GtkMenuTrackerItem is a small helper class used by #GtkMenuTracker to
* 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
* with g_object_bind_property() and #GBinding, and this is how this is
* implemented in GTK+; the appearance side is implemented in #GtkModelMenuItem.
*
* When an item is clicked, simply call gtk_menu_tracker_item_activated() in
* response. The #GtkMenuTrackerItem will take care of everything related to
* 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;
gchar *action_namespace;
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
gchar *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,
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;
type = g_enum_register_static ("GtkMenuTrackerItemRole", values);
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;
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);
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;
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
g_object_notify (G_OBJECT (self), "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,
const gchar *action_name,
const GVariantType *parameter_type,
gboolean enabled,
GVariant *state)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
GVariant *action_target;
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, g_message("menutracker: %s added", 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
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)
{
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, g_message("menutracker: %s found, but disabled due to parameter type mismatch", 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
if (action_target)
g_variant_unref (action_target);
return;
}
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, g_message ("menutracker: %s can be activated", 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
self->sensitive = 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
if (!enabled)
GTK_NOTE(ACTIONS, g_message("menutracker: %s found, but disabled due to disabled action", action_name));
else
GTK_NOTE(ACTIONS, g_message("menutracker: %s found and enabled", 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
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;
}
g_object_freeze_notify (G_OBJECT (self));
if (self->sensitive)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_SENSITIVE]);
if (self->toggled)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_TOGGLED]);
if (self->role != GTK_MENU_TRACKER_ITEM_ROLE_NORMAL)
g_object_notify_by_pspec (G_OBJECT (self), gtk_menu_tracker_item_pspecs[PROP_ROLE]);
g_object_thaw_notify (G_OBJECT (self));
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,
const gchar *action_name,
gboolean enabled)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
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, g_message ("menutracker: %s enabled changed: %d", action_name, 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
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,
const gchar *action_name,
GVariant *state)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
GVariant *action_target;
gboolean was_toggled;
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, g_message ("menutracker: %s state changed", 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
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,
const gchar *action_name)
{
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
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, g_message ("menutracker: %s was removed", 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
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,
const gchar *action_name,
const gchar *action_and_target)
{
GtkMenuTrackerItem *self = GTK_MENU_TRACKER_ITEM (observer);
if (g_str_equal (action_and_target, self->action_and_target))
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,
gint 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,
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 gchar *action_namespace,
gboolean is_separator)
{
GtkMenuTrackerItem *self;
const gchar *action_name;
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
const gchar *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))
{
GActionGroup *group = G_ACTION_GROUP (observable);
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, '.'))
g_message ("menutracker: action name %s doesn't look like 'app.' or 'win.' "
"which means that it will probably not work properly.", action_name));
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));
found = g_action_group_query_action (group, 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
{
GTK_NOTE(ACTIONS, g_message ("menutracker: %s existed from the start", action_name));
gtk_menu_tracker_item_action_added (GTK_ACTION_OBSERVER (self), observable, NULL, parameter_type, enabled, 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
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
{
GTK_NOTE(ACTIONS, g_message ("menutracker: %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:
* @self: A #GtkMenuTrackerItem instance
*
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
* for #GtkMenuTrackerItem.
*/
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:
* @self: A #GtkMenuTrackerItem instance
*
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
* for #GtkMenuTrackerItem.
*/
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,
const gchar *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;
}
const gchar *
gtk_menu_tracker_item_get_label (GtkMenuTrackerItem *self)
{
const gchar *label = NULL;
g_menu_item_get_attribute (self->item, G_MENU_ATTRIBUTE_LABEL, "&s", &label);
return label;
}
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;
}
const gchar *
gtk_menu_tracker_item_get_accel (GtkMenuTrackerItem *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
const gchar *accel;
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
}
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
const gchar *
gtk_menu_tracker_item_get_special (GtkMenuTrackerItem *self)
{
const gchar *special = NULL;
g_menu_item_get_attribute (self->item, "x-gtk-private-special", "&s", &special);
return special;
}
GtkMenuTrackerItem: Add support for display-hint This commit adds a getter for the display-hint attribute.
2014-04-28 18:18:06 +00:00
const gchar *
gtk_menu_tracker_item_get_display_hint (GtkMenuTrackerItem *self)
{
const gchar *display_hint = NULL;
g_menu_item_get_attribute (self->item, "display-hint", "&s", &display_hint);
return display_hint;
}
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,
const gchar *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
}
gchar *
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
{
const gchar *namespace;
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)
{
const gchar *action_name;
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);
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
g_action_group_activate_action (G_ACTION_GROUP (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);
}
typedef struct
{
GtkMenuTrackerItem *item;
gchar *submenu_action;
gboolean first_time;
} GtkMenuTrackerOpener;
static void
gtk_menu_tracker_opener_update (GtkMenuTrackerOpener *opener)
{
GActionGroup *group = G_ACTION_GROUP (opener->item->observable);
gboolean is_open = TRUE;
/* 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.
*/
if (g_action_group_has_action (group, opener->submenu_action))
{
GVariant *state = g_action_group_get_action_state (group, opener->submenu_action);
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)
{
g_action_group_change_action_state (group, opener->submenu_action, g_variant_new_boolean (TRUE));
opener->first_time = FALSE;
}
}
static void
gtk_menu_tracker_opener_added (GActionGroup *group,
const gchar *action_name,
gpointer user_data)
{
GtkMenuTrackerOpener *opener = user_data;
if (g_str_equal (action_name, opener->submenu_action))
gtk_menu_tracker_opener_update (opener);
}
static void
gtk_menu_tracker_opener_removed (GActionGroup *action_group,
const gchar *action_name,
gpointer user_data)
{
GtkMenuTrackerOpener *opener = user_data;
if (g_str_equal (action_name, opener->submenu_action))
gtk_menu_tracker_opener_update (opener);
}
static void
gtk_menu_tracker_opener_changed (GActionGroup *action_group,
const gchar *action_name,
GVariant *new_state,
gpointer user_data)
{
GtkMenuTrackerOpener *opener = user_data;
if (g_str_equal (action_name, opener->submenu_action))
gtk_menu_tracker_opener_update (opener);
}
static void
gtk_menu_tracker_opener_free (gpointer data)
{
GtkMenuTrackerOpener *opener = data;
g_signal_handlers_disconnect_by_func (opener->item->observable, gtk_menu_tracker_opener_added, opener);
g_signal_handlers_disconnect_by_func (opener->item->observable, gtk_menu_tracker_opener_removed, opener);
g_signal_handlers_disconnect_by_func (opener->item->observable, gtk_menu_tracker_opener_changed, opener);
g_action_group_change_action_state (G_ACTION_GROUP (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_slice_free (GtkMenuTrackerOpener, opener);
}
static GtkMenuTrackerOpener *
gtk_menu_tracker_opener_new (GtkMenuTrackerItem *item,
const gchar *submenu_action)
{
GtkMenuTrackerOpener *opener;
opener = g_slice_new (GtkMenuTrackerOpener);
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);
g_signal_connect (item->observable, "action-added", G_CALLBACK (gtk_menu_tracker_opener_added), opener);
g_signal_connect (item->observable, "action-removed", G_CALLBACK (gtk_menu_tracker_opener_removed), opener);
g_signal_connect (item->observable, "action-state-changed", G_CALLBACK (gtk_menu_tracker_opener_changed), opener);
gtk_menu_tracker_opener_update (opener);
return opener;
}
void
gtk_menu_tracker_item_request_submenu_shown (GtkMenuTrackerItem *self,
gboolean shown)
{
const gchar *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),
gtk_menu_tracker_opener_free);
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
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:
* @self: A #GtkMenuTrackerItem instance
*
* 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;
}
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:
* @self: A #GtkMenuTrackerItem instance
*
* 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