2011-12-02 01:39:11 +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
|
|
|
* Copyright © 2011, 2013 Canonical Limited
|
2011-12-02 01:39:11 +00:00
|
|
|
*
|
|
|
|
* 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
|
2012-02-27 13:01:10 +00:00
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
2011-12-02 01:39:11 +00:00
|
|
|
*
|
|
|
|
* Author: Ryan Lortie <desrt@desrt.ca>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include "gtkmodelmenuitem.h"
|
|
|
|
|
2012-09-10 18:36:23 +00:00
|
|
|
#include "gtkaccellabel.h"
|
2013-04-22 19:53:39 +00:00
|
|
|
#include "gtkimage.h"
|
|
|
|
#include "gtkbox.h"
|
2011-12-03 23:45:32 +00:00
|
|
|
|
2011-12-02 01:39:11 +00:00
|
|
|
struct _GtkModelMenuItem
|
|
|
|
{
|
|
|
|
GtkCheckMenuItem parent_instance;
|
add GtkMenuTrackerItem
Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.
GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).
GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings. Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.
GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel. It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.
Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal. The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems. Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.
This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.
2013-05-08 12:20:23 +00:00
|
|
|
GtkMenuTrackerItemRole role;
|
2011-12-02 03:33:30 +00:00
|
|
|
gboolean has_indicator;
|
2011-12-02 01:39:11 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
typedef GtkCheckMenuItemClass GtkModelMenuItemClass;
|
|
|
|
|
2012-08-18 03:13:42 +00:00
|
|
|
G_DEFINE_TYPE (GtkModelMenuItem, gtk_model_menu_item, GTK_TYPE_CHECK_MENU_ITEM)
|
2011-12-02 01:39:11 +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_ACTION_ROLE,
|
|
|
|
PROP_ICON,
|
|
|
|
PROP_TEXT,
|
|
|
|
PROP_TOGGLED,
|
|
|
|
PROP_ACCEL
|
|
|
|
};
|
2011-12-02 01:39:11 +00:00
|
|
|
|
2011-12-02 03:33:30 +00:00
|
|
|
static void
|
|
|
|
gtk_model_menu_item_toggle_size_request (GtkMenuItem *menu_item,
|
|
|
|
gint *requisition)
|
|
|
|
{
|
|
|
|
GtkModelMenuItem *item = GTK_MODEL_MENU_ITEM (menu_item);
|
|
|
|
|
|
|
|
if (item->has_indicator)
|
|
|
|
GTK_MENU_ITEM_CLASS (gtk_model_menu_item_parent_class)
|
|
|
|
->toggle_size_request (menu_item, requisition);
|
|
|
|
|
|
|
|
else
|
|
|
|
*requisition = 0;
|
|
|
|
}
|
|
|
|
|
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_model_menu_item_activate (GtkMenuItem *item)
|
|
|
|
{
|
|
|
|
/* block the automatic toggle behaviour -- just do nothing */
|
|
|
|
}
|
|
|
|
|
2011-12-02 03:33:30 +00:00
|
|
|
static void
|
|
|
|
gtk_model_menu_item_draw_indicator (GtkCheckMenuItem *check_item,
|
|
|
|
cairo_t *cr)
|
|
|
|
{
|
|
|
|
GtkModelMenuItem *item = GTK_MODEL_MENU_ITEM (check_item);
|
|
|
|
|
|
|
|
if (item->has_indicator)
|
|
|
|
GTK_CHECK_MENU_ITEM_CLASS (gtk_model_menu_item_parent_class)
|
|
|
|
->draw_indicator (check_item, cr);
|
|
|
|
}
|
|
|
|
|
2012-06-20 14:56:56 +00:00
|
|
|
static void
|
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_model_menu_item_set_has_indicator (GtkModelMenuItem *item,
|
|
|
|
gboolean has_indicator)
|
2012-06-20 14:56:56 +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 (has_indicator == item->has_indicator)
|
|
|
|
return;
|
2012-06-20 14:56:56 +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
|
|
|
item->has_indicator = has_indicator;
|
2012-08-24 18:11:37 +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
|
|
|
gtk_widget_queue_resize (GTK_WIDGET (item));
|
2012-08-24 18:11:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
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_model_menu_item_set_action_role (GtkModelMenuItem *item,
|
|
|
|
GtkMenuTrackerItemRole role)
|
2012-08-24 18:11:37 +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
|
|
|
AtkObject *accessible;
|
|
|
|
AtkRole a11y_role;
|
2012-08-24 18:11:37 +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 (role == item->role)
|
|
|
|
return;
|
2013-04-22 19:53:39 +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
|
|
|
gtk_check_menu_item_set_draw_as_radio (GTK_CHECK_MENU_ITEM (item), role == GTK_MENU_TRACKER_ITEM_ROLE_RADIO);
|
|
|
|
gtk_model_menu_item_set_has_indicator (item, role != GTK_MENU_TRACKER_ITEM_ROLE_NORMAL);
|
2013-04-22 19:53:39 +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
|
|
|
accessible = gtk_widget_get_accessible (GTK_WIDGET (item));
|
|
|
|
switch (role)
|
2013-04-22 19:53:39 +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
|
|
|
case GTK_MENU_TRACKER_ITEM_ROLE_NORMAL:
|
|
|
|
a11y_role = ATK_ROLE_MENU_ITEM;
|
|
|
|
break;
|
2013-04-22 19:53:39 +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
|
|
|
case GTK_MENU_TRACKER_ITEM_ROLE_CHECK:
|
|
|
|
a11y_role = ATK_ROLE_CHECK_MENU_ITEM;
|
|
|
|
break;
|
2013-04-22 19:53:39 +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
|
|
|
case GTK_MENU_TRACKER_ITEM_ROLE_RADIO:
|
|
|
|
a11y_role = ATK_ROLE_RADIO_MENU_ITEM;
|
|
|
|
break;
|
2013-04-22 19:53:39 +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
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
}
|
2013-04-22 19:53:39 +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
|
|
|
atk_object_set_role (accessible, a11y_role);
|
|
|
|
}
|
2013-04-22 19:53:39 +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_model_menu_item_set_icon (GtkModelMenuItem *item,
|
|
|
|
GIcon *icon)
|
|
|
|
{
|
|
|
|
GtkWidget *child;
|
2013-04-22 19:53:39 +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
|
|
|
g_return_if_fail (GTK_IS_MODEL_MENU_ITEM (item));
|
|
|
|
g_return_if_fail (icon == NULL || G_IS_ICON (icon));
|
2013-04-22 19:53:39 +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
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
2013-04-22 19:53:39 +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
|
|
|
/* There are only three possibilities here:
|
|
|
|
*
|
|
|
|
* - no child
|
|
|
|
* - accel label child
|
|
|
|
* - already a box
|
|
|
|
*
|
|
|
|
* Handle the no-child case by having GtkMenuItem create the accel
|
|
|
|
* label, then we will only have two possible cases.
|
|
|
|
*/
|
|
|
|
if (child == NULL)
|
|
|
|
{
|
|
|
|
gtk_menu_item_get_label (GTK_MENU_ITEM (item));
|
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
|
|
|
g_assert (GTK_IS_LABEL (child));
|
2013-04-22 19:53:39 +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 it is a box, make sure there are no images inside of it already.
|
|
|
|
*/
|
|
|
|
if (GTK_IS_BOX (child))
|
2013-04-22 19:53:39 +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
|
|
|
GList *children;
|
|
|
|
|
|
|
|
children = gtk_container_get_children (GTK_CONTAINER (child));
|
|
|
|
while (children)
|
|
|
|
{
|
|
|
|
if (GTK_IS_IMAGE (children->data))
|
|
|
|
gtk_widget_destroy (children->data);
|
2013-04-22 19:53:39 +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
|
|
|
children = g_list_delete_link (children, children);
|
|
|
|
}
|
|
|
|
}
|
2011-12-02 01:39:11 +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 it is not a box, put it into a box, at the end */
|
|
|
|
if (!GTK_IS_BOX (child))
|
2011-12-03 23:45:32 +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
|
|
|
GtkWidget *box;
|
2012-06-20 14:56:56 +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
|
|
|
box = gtk_box_new (GTK_ORIENTATION_HORIZONTAL, 0);
|
2012-06-20 14:56:56 +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
|
|
|
/* Reparent the child without destroying it */
|
|
|
|
g_object_ref (child);
|
|
|
|
gtk_container_remove (GTK_CONTAINER (item), child);
|
|
|
|
gtk_box_pack_end (GTK_BOX (box), child, TRUE, TRUE, 0);
|
|
|
|
g_object_unref (child);
|
2012-06-20 14:56:56 +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
|
|
|
gtk_container_add (GTK_CONTAINER (item), box);
|
|
|
|
gtk_widget_show (box);
|
2012-06-20 14:56:56 +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
|
|
|
/* Now we have a box */
|
|
|
|
child = box;
|
2011-12-03 23:45:32 +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
|
|
|
g_assert (GTK_IS_BOX (child));
|
|
|
|
|
|
|
|
/* child is now a box containing a label and no image. Add the icon,
|
|
|
|
* if appropriate.
|
|
|
|
*/
|
|
|
|
if (icon != NULL)
|
2011-12-02 01:39:11 +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
|
|
|
GtkWidget *image;
|
2011-12-02 01:39:11 +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
|
|
|
image = gtk_image_new_from_gicon (icon, GTK_ICON_SIZE_MENU);
|
|
|
|
gtk_box_pack_start (GTK_BOX (child), image, FALSE, FALSE, 0);
|
|
|
|
gtk_widget_show (image);
|
|
|
|
}
|
|
|
|
}
|
2012-09-10 18:36:23 +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_model_menu_item_set_text (GtkModelMenuItem *item,
|
|
|
|
const gchar *text)
|
|
|
|
{
|
|
|
|
GtkWidget *child;
|
|
|
|
GList *children;
|
2012-09-10 18:36:23 +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
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
|
|
|
if (child == NULL)
|
|
|
|
{
|
|
|
|
gtk_menu_item_get_label (GTK_MENU_ITEM (item));
|
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
|
|
|
g_assert (GTK_IS_LABEL (child));
|
|
|
|
}
|
2012-09-10 18:36:23 +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 (GTK_IS_LABEL (child))
|
|
|
|
{
|
|
|
|
gtk_label_set_text_with_mnemonic (GTK_LABEL (child), text);
|
|
|
|
return;
|
|
|
|
}
|
2011-12-02 01:39:11 +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 (!GTK_IS_CONTAINER (child))
|
|
|
|
return;
|
2011-12-02 01:39:11 +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
|
|
|
children = gtk_container_get_children (GTK_CONTAINER (child));
|
2012-08-24 18:11:37 +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
|
|
|
while (children)
|
|
|
|
{
|
|
|
|
if (GTK_IS_LABEL (children->data))
|
|
|
|
gtk_label_set_label (GTK_LABEL (children->data), text);
|
2012-08-24 18:11:37 +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
|
|
|
children = g_list_delete_link (children, children);
|
|
|
|
}
|
|
|
|
}
|
2012-08-24 18:11:37 +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_model_menu_item_set_accel (GtkModelMenuItem *item,
|
|
|
|
const gchar *accel)
|
|
|
|
{
|
|
|
|
GtkWidget *child;
|
|
|
|
GList *children;
|
|
|
|
GdkModifierType modifiers;
|
|
|
|
guint key;
|
2012-08-24 18:11:37 +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 (accel)
|
|
|
|
{
|
|
|
|
gtk_accelerator_parse (accel, &key, &modifiers);
|
|
|
|
if (!key)
|
|
|
|
modifiers = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
key = 0;
|
|
|
|
modifiers = 0;
|
|
|
|
}
|
2012-08-24 18:11:37 +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
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
|
|
|
if (child == NULL)
|
|
|
|
{
|
|
|
|
gtk_menu_item_get_label (GTK_MENU_ITEM (item));
|
|
|
|
child = gtk_bin_get_child (GTK_BIN (item));
|
|
|
|
g_assert (GTK_IS_LABEL (child));
|
2011-12-02 01:39:11 +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 (GTK_IS_LABEL (child))
|
|
|
|
{
|
|
|
|
gtk_accel_label_set_accel (GTK_ACCEL_LABEL (child), key, modifiers);
|
|
|
|
return;
|
|
|
|
}
|
2011-12-02 01:39:11 +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 (!GTK_IS_CONTAINER (child))
|
2012-08-18 03:13:42 +00:00
|
|
|
return;
|
|
|
|
|
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
|
|
|
children = gtk_container_get_children (GTK_CONTAINER (child));
|
2012-08-18 03:13:42 +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
|
|
|
while (children)
|
|
|
|
{
|
|
|
|
if (GTK_IS_ACCEL_LABEL (children->data))
|
|
|
|
gtk_accel_label_set_accel (children->data, key, modifiers);
|
|
|
|
|
|
|
|
children = g_list_delete_link (children, children);
|
|
|
|
}
|
2011-12-02 01:39:11 +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
|
|
|
void
|
2012-08-18 03:13:42 +00:00
|
|
|
gtk_model_menu_item_set_property (GObject *object, guint prop_id,
|
|
|
|
const GValue *value, GParamSpec *pspec)
|
2011-12-02 01:39:11 +00:00
|
|
|
{
|
2012-08-18 03:13:42 +00:00
|
|
|
GtkModelMenuItem *item = GTK_MODEL_MENU_ITEM (object);
|
|
|
|
|
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
|
|
|
switch (prop_id)
|
|
|
|
{
|
|
|
|
case PROP_ACTION_ROLE:
|
|
|
|
gtk_model_menu_item_set_action_role (item, g_value_get_enum (value));
|
|
|
|
break;
|
2012-08-18 03:13:42 +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
|
|
|
case PROP_ICON:
|
|
|
|
gtk_model_menu_item_set_icon (item, g_value_get_object (value));
|
|
|
|
break;
|
2012-08-18 03:13:42 +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
|
|
|
case PROP_TEXT:
|
|
|
|
gtk_model_menu_item_set_text (item, g_value_get_string (value));
|
2012-08-18 03:13:42 +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_TOGGLED:
|
|
|
|
_gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (item), g_value_get_boolean (value));
|
2012-08-18 03:13:42 +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_ACCEL:
|
|
|
|
gtk_model_menu_item_set_accel (item, g_value_get_string (value));
|
2012-08-18 03:13:42 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
g_assert_not_reached ();
|
|
|
|
}
|
2011-12-02 01:39:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2012-08-18 03:13:42 +00:00
|
|
|
gtk_model_menu_item_init (GtkModelMenuItem *item)
|
2011-12-02 01:39:11 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gtk_model_menu_item_class_init (GtkModelMenuItemClass *class)
|
|
|
|
{
|
2011-12-02 03:33:30 +00:00
|
|
|
GtkCheckMenuItemClass *check_class = GTK_CHECK_MENU_ITEM_CLASS (class);
|
2011-12-02 01:39:11 +00:00
|
|
|
GtkMenuItemClass *item_class = GTK_MENU_ITEM_CLASS (class);
|
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (class);
|
|
|
|
|
2011-12-02 03:33:30 +00:00
|
|
|
check_class->draw_indicator = gtk_model_menu_item_draw_indicator;
|
|
|
|
|
|
|
|
item_class->toggle_size_request = gtk_model_menu_item_toggle_size_request;
|
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
|
|
|
item_class->activate = gtk_model_menu_item_activate;
|
2011-12-02 01:39:11 +00:00
|
|
|
|
2012-08-18 03:13:42 +00:00
|
|
|
object_class->set_property = gtk_model_menu_item_set_property;
|
|
|
|
|
|
|
|
g_object_class_install_property (object_class, PROP_ACTION_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_param_spec_enum ("action-role", "action role", "action role",
|
|
|
|
GTK_TYPE_MENU_TRACKER_ITEM_ROLE,
|
|
|
|
GTK_MENU_TRACKER_ITEM_ROLE_NORMAL,
|
|
|
|
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
|
|
|
|
g_object_class_install_property (object_class, PROP_ICON,
|
|
|
|
g_param_spec_object ("icon", "icon", "icon", G_TYPE_ICON,
|
|
|
|
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
|
|
|
|
g_object_class_install_property (object_class, PROP_TEXT,
|
|
|
|
g_param_spec_string ("text", "text", "text", NULL,
|
|
|
|
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
|
|
|
|
g_object_class_install_property (object_class, PROP_TOGGLED,
|
|
|
|
g_param_spec_boolean ("toggled", "toggled", "toggled", FALSE,
|
|
|
|
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
|
|
|
|
g_object_class_install_property (object_class, PROP_ACCEL,
|
|
|
|
g_param_spec_string ("accel", "accel", "accel", NULL,
|
|
|
|
G_PARAM_WRITABLE | G_PARAM_STATIC_STRINGS));
|
2011-12-02 01:39:11 +00:00
|
|
|
}
|
|
|
|
|
2013-03-22 21:24:46 +00:00
|
|
|
GtkWidget *
|
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_model_menu_item_new (void)
|
2011-12-02 01:39:11 +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
|
|
|
return g_object_new (GTK_TYPE_MODEL_MENU_ITEM, NULL);
|
2011-12-02 01:39:11 +00:00
|
|
|
}
|