AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
75b76af221
gtk2/gtk/gtkmenutracker.h

56 lines
3.3 KiB
C
Raw Normal View History

Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +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/>.
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +00:00
*
* Author: Ryan Lortie <desrt@desrt.ca>
*/
#ifndef __GTK_MENU_TRACKER_H__
#define __GTK_MENU_TRACKER_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
#include "gtkmenutrackeritem.h"
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +00:00
typedef struct _GtkMenuTracker GtkMenuTracker;
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 void (* GtkMenuTrackerInsertFunc) (GtkMenuTrackerItem *item,
gint position,
gpointer user_data);
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +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
typedef void (* GtkMenuTrackerRemoveFunc) (gint position,
gpointer user_data);
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +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
GtkMenuTracker * gtk_menu_tracker_new (GtkActionObservable *observer,
GMenuModel *model,
gboolean with_separators,
GtkMenuTracker: add 'merge_sections' flag Add the possibility of a GtkMenuTracker that performs no section merging. Instead, it will report an item in the form of a separator for subsections. It is then possible to get a separate tracker for the subsection contents by using gtk_menu_tracker_new_for_item_link().
2014-04-28 12:20:08 +00:00
gboolean merge_sections,
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,
GtkMenuTrackerInsertFunc insert_func,
GtkMenuTrackerRemoveFunc remove_func,
gpointer user_data);
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +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
GtkMenuTracker * gtk_menu_tracker_new_for_item_link (GtkMenuTrackerItem *item,
const gchar *link_name,
GtkMenuTracker: add 'merge_sections' flag Add the possibility of a GtkMenuTracker that performs no section merging. Instead, it will report an item in the form of a separator for subsections. It is then possible to get a separate tracker for the subsection contents by using gtk_menu_tracker_new_for_item_link().
2014-04-28 12:20:08 +00:00
gboolean merge_sections,
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
GtkMenuTrackerInsertFunc insert_func,
GtkMenuTrackerRemoveFunc remove_func,
gpointer user_data);
void gtk_menu_tracker_free (GtkMenuTracker *tracker);
Introduce GtkMenuTracker GtkMenuTracker folds a nested structure of sections in a GMenuModel into a single linear menu, which it expresses to its user by means of 'insert item at position' and 'remove item at position' callbacks. The logic for where to insert separators and how to handle action namespaces is contained within the tracker, removing the need to have this logic duplicated in the 3 or 4 places that consume GMenuModel. In comparison with the previous code, the tracker no longer completely destroys and rebuilds menus every time a single change occurs. As a result, the new gtkmenu testcase now runs in approximately 3 seconds instead of ~60 before. https://bugzilla.gnome.org/show_bug.cgi?id=696468
2013-03-22 21:24:46 +00:00
#endif /* __GTK_MENU_TRACKER_H__ */
Reference in New Issue Copy Permalink