2007-07-06 14:36:59 +02:00
|
|
|
# Copyright (C) 2007, Eduardo Silva <edsiper@gmail.com>
|
2008-04-01 11:52:11 +02:00
|
|
|
# Copyright (C) 2008, One Laptop Per Child
|
2009-08-01 16:15:01 +02:00
|
|
|
# Copyright (C) 2009, Tomeu Vizoso
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
# Copyright (C) 2011, Benjamin Berg <benjamin@sipsolutions.net>
|
|
|
|
# Copyright (C) 2011, Marco Pesenti Gritti <marco@marcopg.org>
|
2007-05-24 19:37:48 +02:00
|
|
|
#
|
2007-06-14 22:04:25 +02: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 License, or (at your option) any later version.
|
2007-05-24 19:37:48 +02:00
|
|
|
#
|
2007-06-14 22:04:25 +02:00
|
|
|
# This library is distributed in the hope that it will be useful,
|
2007-05-24 19:37:48 +02:00
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
2007-06-14 22:04:25 +02:00
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
# Lesser General Public License for more details.
|
2007-05-24 19:37:48 +02:00
|
|
|
#
|
2007-06-14 22:04:25 +02:00
|
|
|
# You should have received a copy of the GNU Lesser General Public
|
|
|
|
# License along with this library; if not, write to the
|
|
|
|
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
|
|
|
|
# Boston, MA 02111-1307, USA.
|
2007-05-24 19:37:48 +02:00
|
|
|
|
2008-10-28 14:19:01 +01:00
|
|
|
"""
|
|
|
|
STABLE.
|
|
|
|
"""
|
2014-04-02 16:02:34 +02:00
|
|
|
import textwrap
|
|
|
|
|
2014-12-12 21:37:22 +01:00
|
|
|
from gi.repository import GLib
|
2011-11-15 19:29:07 +01:00
|
|
|
from gi.repository import Gtk
|
2013-11-29 13:09:53 +01:00
|
|
|
from gi.repository import Gdk
|
2011-11-15 19:29:07 +01:00
|
|
|
from gi.repository import GObject
|
2015-06-23 13:32:09 +02:00
|
|
|
from gi.repository import Pango
|
2007-05-24 19:37:48 +02:00
|
|
|
|
2011-10-29 10:44:18 +02:00
|
|
|
from sugar3.graphics import animator
|
|
|
|
from sugar3.graphics import style
|
|
|
|
from sugar3.graphics.icon import Icon
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
from sugar3.graphics.palettewindow import PaletteWindow, \
|
|
|
|
_PaletteWindowWidget, _PaletteMenuWidget
|
2012-12-10 15:47:52 +01:00
|
|
|
from sugar3.graphics.palettemenu import PaletteMenuItem
|
2007-06-25 14:31:43 +02:00
|
|
|
|
2011-10-29 10:44:18 +02:00
|
|
|
from sugar3.graphics.palettewindow import MouseSpeedDetector, Invoker, \
|
2014-11-28 12:45:22 +01:00
|
|
|
WidgetInvoker, CursorInvoker, ToolInvoker, TreeViewInvoker
|
|
|
|
|
2013-05-05 01:27:31 +02:00
|
|
|
assert MouseSpeedDetector
|
|
|
|
assert Invoker
|
|
|
|
assert WidgetInvoker
|
|
|
|
assert CursorInvoker
|
|
|
|
assert ToolInvoker
|
2014-11-28 12:45:22 +01:00
|
|
|
assert TreeViewInvoker
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2013-05-18 04:27:04 +02:00
|
|
|
|
2012-09-13 05:39:55 +02:00
|
|
|
class _HeaderItem(Gtk.MenuItem):
|
|
|
|
"""A MenuItem with a custom child widget that gets all the
|
|
|
|
available space.
|
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
"""
|
2012-09-13 05:39:55 +02:00
|
|
|
|
|
|
|
__gtype_name__ = 'SugarPaletteHeader'
|
|
|
|
|
|
|
|
def __init__(self, widget):
|
|
|
|
Gtk.MenuItem.__init__(self)
|
|
|
|
if self.get_child() is not None:
|
|
|
|
self.remove(self.get_child())
|
|
|
|
self.add(widget)
|
|
|
|
# FIXME we have to mark it as insensitive again to make it an
|
|
|
|
# informational element, when we realize how to get the icon
|
|
|
|
# displayed correctly - SL #3836
|
|
|
|
# self.set_sensitive(False)
|
|
|
|
|
|
|
|
def do_size_allocate(self, allocation):
|
|
|
|
self.set_allocation(allocation)
|
|
|
|
self.get_child().size_allocate(allocation)
|
|
|
|
|
2015-06-30 19:24:52 +02:00
|
|
|
def do_draw(self, cr):
|
|
|
|
# force state normal, we don't want change color when hover
|
|
|
|
self.set_state(Gtk.StateType.NORMAL)
|
|
|
|
|
|
|
|
# draw separator
|
|
|
|
allocation = self.get_allocation()
|
|
|
|
cr.save()
|
|
|
|
line_width = 2
|
|
|
|
cr.set_line_width(line_width)
|
|
|
|
cr.set_source_rgb(.5, .5, .5) # button_grey #808080;
|
|
|
|
cr.move_to(0, allocation.height - line_width)
|
|
|
|
cr.line_to(allocation.width, allocation.height - line_width)
|
|
|
|
cr.stroke()
|
|
|
|
cr.restore()
|
|
|
|
|
|
|
|
# draw content
|
|
|
|
Gtk.MenuItem.do_draw(self, cr)
|
|
|
|
return False
|
2012-09-13 05:39:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
class Palette(PaletteWindow):
|
|
|
|
"""Floating palette implementation.
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
|
|
|
|
This class dynamically switches between one of two encapsulated child
|
|
|
|
widget types: a _PaletteWindowWidget or a _PaletteMenuWidget.
|
|
|
|
|
|
|
|
The window widget, created by default, acts as the container for any
|
|
|
|
type of widget the user may wish to add. It can optionally display primary
|
|
|
|
text, secondary text, and an icon at the top of the palette.
|
|
|
|
|
|
|
|
If the user attempts to access the 'menu' property, the window widget is
|
|
|
|
destroyed and the palette is dynamically switched to use a menu widget.
|
|
|
|
This is a GtkMenu that retains the same look and feel as a normal palette,
|
|
|
|
allowing submenus and so on. If primary text, secondary text and/or icons
|
|
|
|
were provided, an initial menu entry is created containing widgets to
|
|
|
|
display such information.
|
|
|
|
"""
|
|
|
|
|
|
|
|
__gsignals__ = {
|
|
|
|
'activate': (GObject.SignalFlags.RUN_FIRST, None, ([])),
|
|
|
|
}
|
|
|
|
|
2009-08-01 13:23:06 +02:00
|
|
|
__gtype_name__ = 'SugarPalette'
|
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
def __init__(self, label=None, accel_path=None,
|
2014-01-08 14:35:16 +01:00
|
|
|
text_maxlen=style.MENU_WIDTH_CHARS, **kwargs):
|
2009-08-25 21:12:40 +02:00
|
|
|
# DEPRECATED: label is passed with the primary-text property,
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
# accel_path is set via the invoker property
|
2007-05-24 19:37:48 +02:00
|
|
|
|
2008-04-01 03:27:46 +02:00
|
|
|
self._primary_text = None
|
|
|
|
self._secondary_text = None
|
|
|
|
self._icon = None
|
|
|
|
self._icon_visible = True
|
2009-08-01 16:15:01 +02:00
|
|
|
self._palette_state = self.PRIMARY
|
2007-06-01 06:08:24 +02:00
|
|
|
|
2013-11-29 13:09:53 +01:00
|
|
|
self._primary_event_box = Gtk.EventBox()
|
|
|
|
self._primary_event_box.show()
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._primary_box = Gtk.HBox()
|
2013-11-29 13:09:53 +01:00
|
|
|
self._primary_event_box.add(self._primary_box)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._primary_box.show()
|
2007-07-02 12:05:42 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self._icon_box = Gtk.HBox()
|
2009-03-13 15:44:57 +01:00
|
|
|
self._icon_box.set_size_request(style.GRID_CELL_SIZE, -1)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._primary_box.pack_start(self._icon_box, False, True, 0)
|
2007-06-25 14:31:43 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
labels_box = Gtk.VBox()
|
2011-10-30 14:54:53 +01:00
|
|
|
self._label_alignment = Gtk.Alignment(xalign=0, yalign=0.5, xscale=1,
|
|
|
|
yscale=0.33)
|
2014-04-02 16:02:34 +02:00
|
|
|
self._label_alignment.set_padding(
|
|
|
|
style.DEFAULT_SPACING, style.DEFAULT_SPACING,
|
|
|
|
style.DEFAULT_SPACING, style.DEFAULT_SPACING)
|
2008-04-01 03:27:46 +02:00
|
|
|
self._label_alignment.add(labels_box)
|
|
|
|
self._label_alignment.show()
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._primary_box.pack_start(self._label_alignment, True, True, 0)
|
2008-04-01 03:27:46 +02:00
|
|
|
labels_box.show()
|
2007-08-08 03:07:00 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self._label = Gtk.AccelLabel(label='')
|
2007-09-22 00:21:45 +02:00
|
|
|
self._label.set_alignment(0, 0.5)
|
2008-01-10 19:21:29 +01:00
|
|
|
|
|
|
|
if text_maxlen > 0:
|
|
|
|
self._label.set_max_width_chars(text_maxlen)
|
2014-12-17 00:39:50 +01:00
|
|
|
self._label.set_ellipsize(style.ELLIPSIZE_MODE_DEFAULT)
|
2011-11-15 19:29:07 +01:00
|
|
|
labels_box.pack_start(self._label, True, True, 0)
|
2013-11-29 13:09:53 +01:00
|
|
|
self._primary_event_box.connect('button-release-event',
|
|
|
|
self.__button_release_event_cb)
|
|
|
|
self._primary_event_box.set_events(Gdk.EventMask.BUTTON_RELEASE_MASK)
|
2008-01-10 19:21:29 +01:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self._secondary_label = Gtk.Label()
|
2008-04-01 03:27:46 +02:00
|
|
|
self._secondary_label.set_alignment(0, 0.5)
|
2011-11-15 19:29:07 +01:00
|
|
|
labels_box.pack_start(self._secondary_label, True, True, 0)
|
2007-08-08 03:07:00 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self._secondary_box = Gtk.VBox()
|
2007-08-08 12:56:19 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self._separator = Gtk.HSeparator()
|
|
|
|
self._secondary_box.pack_start(self._separator, True, True, 0)
|
2007-08-08 03:07:00 +02:00
|
|
|
|
2008-05-24 19:34:03 +02:00
|
|
|
self._secondary_anim = animator.Animator(2.0, 10)
|
2008-04-01 03:27:46 +02:00
|
|
|
self._secondary_anim.add(_SecondaryAnimation(self))
|
|
|
|
|
|
|
|
# we init after initializing all of our containers
|
2009-08-01 13:23:06 +02:00
|
|
|
PaletteWindow.__init__(self, **kwargs)
|
2008-12-05 11:51:40 +01:00
|
|
|
|
2009-08-01 13:23:06 +02:00
|
|
|
self._full_request = [0, 0]
|
2008-04-19 10:45:52 +02:00
|
|
|
self._content = None
|
2008-04-01 03:27:46 +02:00
|
|
|
|
|
|
|
# we set these for backward compatibility
|
|
|
|
if label is not None:
|
|
|
|
self.props.primary_text = label
|
|
|
|
|
|
|
|
self._add_content()
|
2007-06-02 06:33:41 +02:00
|
|
|
|
2007-08-08 13:03:09 +02:00
|
|
|
self.action_bar = PaletteActionBar()
|
2011-11-15 19:29:07 +01:00
|
|
|
self._secondary_box.pack_start(self.action_bar, True, True, 0)
|
2007-08-08 13:03:09 +02:00
|
|
|
self.action_bar.show()
|
2007-06-06 06:51:01 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self.connect('notify::invoker', self.__notify_invoker_cb)
|
|
|
|
self.connect('popdown', self.__popdown_cb)
|
2007-06-25 11:39:51 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
# Default to a normal window palette
|
|
|
|
self._content_widget = None
|
|
|
|
self.set_content(None)
|
2007-08-08 11:53:41 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
def _setup_widget(self):
|
|
|
|
PaletteWindow._setup_widget(self)
|
|
|
|
self._widget.connect('destroy', self.__destroy_cb)
|
2015-01-14 05:37:16 +01:00
|
|
|
self._widget.connect('map', self.__map_cb)
|
|
|
|
|
|
|
|
def __map_cb(self, *args):
|
|
|
|
# Fixes #4463
|
2015-05-15 23:34:17 +02:00
|
|
|
if hasattr(self._widget, 'present'):
|
|
|
|
self._widget.present()
|
2007-06-06 04:43:42 +02:00
|
|
|
|
2008-09-10 12:31:10 +02:00
|
|
|
def __destroy_cb(self, palette):
|
2009-09-03 17:35:54 +02:00
|
|
|
self._secondary_anim.stop()
|
|
|
|
self.popdown(immediate=True)
|
2008-09-13 13:23:49 +02:00
|
|
|
# Break the reference cycle. It looks like the gc is not able to free
|
2011-11-15 19:29:07 +01:00
|
|
|
# it, possibly because Gtk.Menu memory handling is very special.
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._widget = None
|
2009-08-01 13:23:06 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
def __popdown_cb(self, widget):
|
2009-08-01 16:15:01 +02:00
|
|
|
self._secondary_anim.stop()
|
2009-08-01 13:23:06 +02:00
|
|
|
|
|
|
|
def __notify_invoker_cb(self, palette, pspec):
|
|
|
|
invoker = self.props.invoker
|
|
|
|
if invoker is not None and hasattr(invoker.props, 'widget'):
|
|
|
|
self._update_accel_widget()
|
|
|
|
self._invoker.connect('notify::widget',
|
|
|
|
self.__invoker_widget_changed_cb)
|
|
|
|
|
|
|
|
def __invoker_widget_changed_cb(self, invoker, spec):
|
|
|
|
self._update_accel_widget()
|
|
|
|
|
|
|
|
def get_full_size_request(self):
|
|
|
|
return self._full_request
|
|
|
|
|
|
|
|
def popup(self, immediate=False, state=None):
|
|
|
|
if self._invoker is not None:
|
|
|
|
self._update_full_request()
|
2009-08-25 19:55:48 +02:00
|
|
|
|
2009-08-01 13:23:06 +02:00
|
|
|
if state is None:
|
|
|
|
state = self.PRIMARY
|
2009-08-01 00:04:28 +02:00
|
|
|
self.set_palette_state(state)
|
2009-08-01 13:23:06 +02:00
|
|
|
|
2009-09-09 14:41:37 +02:00
|
|
|
if state == self.PRIMARY:
|
|
|
|
self._secondary_anim.start()
|
|
|
|
else:
|
|
|
|
self._secondary_anim.stop()
|
|
|
|
|
2014-06-24 19:16:09 +02:00
|
|
|
PaletteWindow.popup(self, immediate)
|
|
|
|
|
2009-09-09 14:41:37 +02:00
|
|
|
def popdown(self, immediate=False):
|
|
|
|
if immediate:
|
2009-09-09 22:05:31 +02:00
|
|
|
self._secondary_anim.stop()
|
2009-09-09 14:41:37 +02:00
|
|
|
# to suppress glitches while later re-opening
|
|
|
|
self.set_palette_state(self.PRIMARY)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
if self._widget:
|
|
|
|
self._widget.size_request()
|
2009-09-09 14:41:37 +02:00
|
|
|
PaletteWindow.popdown(self, immediate)
|
2009-09-04 12:05:16 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
def on_enter(self):
|
|
|
|
PaletteWindow.on_enter(self)
|
2009-08-01 16:15:01 +02:00
|
|
|
self._secondary_anim.start()
|
2009-08-25 19:55:48 +02:00
|
|
|
|
2007-09-09 04:48:21 +02:00
|
|
|
def _add_content(self):
|
2007-09-22 00:43:14 +02:00
|
|
|
# The content is not shown until a widget is added
|
2011-11-15 19:29:07 +01:00
|
|
|
self._content = Gtk.VBox()
|
Set correct padding and size for the palette, window implementation - SL #4144
A new API is provided: PaletteMenuBox is a container to be used in
Palette.set_content(). This is to hide the implementation details and
set the corresponding paddings and sizes.
Usage:
box = PaletteMenuBox()
palette.set_content(box)
Then we can append items to it, like:
item = PaletteMenuItem(text_label, icon, xo_color=xo_color)
box.append_child(item)
separator = PaletteMenuItemSeparator()
box.append_child(item)
We can also append any widget, and the box will handle the paddings:
box.append_child(widget)
style.DEFAULT_PADDING for horizontal and vertical padding is the
default. But can be overriden:
box.append_child(widget, horizontal_padding=0, vertical_padding=0)
Details:
- move palettemenuitem.py to palettemenu.py
- Width of palette: make it a minimun size of 3 Sugar grid cells.
- Padding of content, secondary box: we need top and bottom padding,
which can be set when packing the items container inside the
secondary box.
- Padding of menu items: needs to be just for left and right, so move
the padding to a new horizontal box.
- Padding of separators: unlike GtkSeparatorMenuItem, GtkSeparator
doesn't support padding. But we can wrap it in a GtkEventBox and
force the height of the widget there.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
2012-11-01 21:45:37 +01:00
|
|
|
self._secondary_box.pack_start(self._content, True, True,
|
|
|
|
style.DEFAULT_SPACING)
|
2007-09-09 04:48:21 +02:00
|
|
|
|
2008-08-14 15:12:57 +02:00
|
|
|
def _update_accel_widget(self):
|
|
|
|
assert self.props.invoker is not None
|
|
|
|
self._label.props.accel_widget = self.props.invoker.props.widget
|
2008-04-01 03:27:46 +02:00
|
|
|
|
|
|
|
def set_primary_text(self, label, accel_path=None):
|
|
|
|
self._primary_text = label
|
2007-08-16 17:32:29 +02:00
|
|
|
if label is not None:
|
2014-12-12 21:37:22 +01:00
|
|
|
label = GLib.markup_escape_text(label)
|
2008-04-01 11:52:11 +02:00
|
|
|
self._label.set_markup('<b>%s</b>' % label)
|
2007-08-16 17:32:29 +02:00
|
|
|
self._label.show()
|
2007-07-01 11:05:14 +02:00
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def get_primary_text(self):
|
|
|
|
return self._primary_text
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
primary_text = GObject.property(type=str,
|
2009-01-12 15:38:08 +01:00
|
|
|
getter=get_primary_text,
|
|
|
|
setter=set_primary_text)
|
|
|
|
|
2013-11-29 13:09:53 +01:00
|
|
|
def __button_release_event_cb(self, widget, event):
|
|
|
|
if self.props.invoker is not None:
|
|
|
|
self.props.invoker.primary_text_clicked()
|
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def set_secondary_text(self, label):
|
2008-04-01 03:27:46 +02:00
|
|
|
if label is None:
|
|
|
|
self._secondary_label.hide()
|
|
|
|
else:
|
2014-04-02 16:02:34 +02:00
|
|
|
NO_OF_LINES = 3
|
|
|
|
ELLIPSIS_LENGTH = 6
|
|
|
|
|
|
|
|
label = label.replace('\n', ' ')
|
Show palettes at the screen bottom with the right size - Fixes #4673
On Gtk 3.10, Gtk.Menu at the bottom of the screen are resized
to avoid fall out of the screen, then report a wrong height.
We need calculate the size of the children and move the Menu up.
This problem is visible on the Clipboard icon palettes,
and in journal objects palettes at the bottom of the screen.
This patch also rename a variable 'rect' to 'req', because is
a Requisition (width, height) and not a Rectangle (x, y, width, height).
Finally, to avoid a error with the secondary text on the palette,
when copy text from the terminal, reove the '¬r' character.
Signed-off-by: Gonzalo Odiard <godiard@sugarlabs.org>
2014-05-28 15:00:05 +02:00
|
|
|
label = label.replace('\r', ' ')
|
2014-04-02 16:02:34 +02:00
|
|
|
|
|
|
|
if hasattr(self._secondary_label, 'set_lines'):
|
|
|
|
self._secondary_label.set_max_width_chars(
|
|
|
|
style.MENU_WIDTH_CHARS)
|
|
|
|
self._secondary_label.set_line_wrap(True)
|
2015-05-15 23:40:09 +02:00
|
|
|
self._secondary_label.set_ellipsize(
|
|
|
|
style.ELLIPSIZE_MODE_DEFAULT)
|
2015-06-23 13:32:09 +02:00
|
|
|
self._secondary_label.set_line_wrap_mode(
|
|
|
|
Pango.WrapMode.WORD_CHAR)
|
2014-05-28 20:51:05 +02:00
|
|
|
self._secondary_label.set_lines(NO_OF_LINES)
|
|
|
|
self._secondary_label.set_justify(Gtk.Justification.FILL)
|
2014-04-02 16:02:34 +02:00
|
|
|
else:
|
|
|
|
# FIXME: fallback for Gtk < 3.10
|
|
|
|
body_width = NO_OF_LINES * style.MENU_WIDTH_CHARS
|
|
|
|
body_width -= ELLIPSIS_LENGTH
|
|
|
|
if len(label) > body_width:
|
2014-12-04 22:19:05 +01:00
|
|
|
label = ' '.join(label[:body_width].split()[:-1]) + '...'
|
2014-04-02 16:02:34 +02:00
|
|
|
label = textwrap.fill(label, width=style.MENU_WIDTH_CHARS)
|
|
|
|
|
|
|
|
self._secondary_text = label
|
2008-04-01 03:27:46 +02:00
|
|
|
self._secondary_label.set_text(label)
|
|
|
|
self._secondary_label.show()
|
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def get_secondary_text(self):
|
|
|
|
return self._secondary_text
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
secondary_text = GObject.property(type=str, getter=get_secondary_text,
|
2013-05-18 04:27:04 +02:00
|
|
|
setter=set_secondary_text)
|
2009-01-12 15:38:08 +01:00
|
|
|
|
2008-04-01 03:27:46 +02:00
|
|
|
def _show_icon(self):
|
2014-05-28 20:51:05 +02:00
|
|
|
self._label_alignment.set_padding(
|
|
|
|
style.DEFAULT_SPACING, style.DEFAULT_SPACING,
|
|
|
|
0, style.DEFAULT_SPACING)
|
2008-04-01 03:27:46 +02:00
|
|
|
self._icon_box.show()
|
|
|
|
|
|
|
|
def _hide_icon(self):
|
|
|
|
self._icon_box.hide()
|
2014-05-28 20:51:05 +02:00
|
|
|
self._label_alignment.set_padding(
|
|
|
|
style.DEFAULT_SPACING, style.DEFAULT_SPACING,
|
|
|
|
style.DEFAULT_SPACING, style.DEFAULT_SPACING)
|
2008-04-01 03:27:46 +02:00
|
|
|
|
2009-02-10 18:57:02 +01:00
|
|
|
def set_icon(self, icon):
|
2008-04-01 03:27:46 +02:00
|
|
|
if icon is None:
|
|
|
|
self._icon = None
|
|
|
|
self._hide_icon()
|
|
|
|
else:
|
|
|
|
if self._icon:
|
2009-02-10 18:57:02 +01:00
|
|
|
self._icon_box.remove(self._icon_box.get_children()[0])
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
event_box = Gtk.EventBox()
|
2009-02-10 18:57:02 +01:00
|
|
|
event_box.connect('button-release-event',
|
|
|
|
self.__icon_button_release_event_cb)
|
2011-11-15 19:29:07 +01:00
|
|
|
self._icon_box.pack_start(event_box, True, True, 0)
|
2009-02-10 18:57:02 +01:00
|
|
|
event_box.show()
|
2008-04-01 03:27:46 +02:00
|
|
|
|
|
|
|
self._icon = icon
|
2015-06-29 17:12:58 +02:00
|
|
|
self._icon.props.pixel_size = style.STANDARD_ICON_SIZE
|
2009-02-10 18:57:02 +01:00
|
|
|
event_box.add(self._icon)
|
2008-04-01 03:27:46 +02:00
|
|
|
self._icon.show()
|
|
|
|
self._show_icon()
|
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def get_icon(self):
|
|
|
|
return self._icon
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
icon = GObject.property(type=object, getter=get_icon, setter=set_icon)
|
2009-01-12 15:38:08 +01:00
|
|
|
|
2009-02-10 18:57:02 +01:00
|
|
|
def __icon_button_release_event_cb(self, icon, event):
|
|
|
|
self.emit('activate')
|
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def set_icon_visible(self, visible):
|
2008-04-01 03:27:46 +02:00
|
|
|
self._icon_visible = visible
|
|
|
|
|
|
|
|
if visible and self._icon is not None:
|
|
|
|
self._show_icon()
|
|
|
|
else:
|
|
|
|
self._hide_icon()
|
|
|
|
|
2009-01-12 15:38:08 +01:00
|
|
|
def get_icon_visible(self):
|
|
|
|
return self._icon_visilbe
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
icon_visible = GObject.property(type=bool,
|
2009-01-12 15:38:08 +01:00
|
|
|
default=True,
|
|
|
|
getter=get_icon_visible,
|
|
|
|
setter=set_icon_visible)
|
|
|
|
|
2007-08-08 12:56:19 +02:00
|
|
|
def set_content(self, widget):
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
assert self._widget is None \
|
2013-05-18 04:27:04 +02:00
|
|
|
or isinstance(self._widget, _PaletteWindowWidget)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
|
|
|
|
if self._widget is None:
|
2012-04-18 22:29:15 +02:00
|
|
|
self._widget = _PaletteWindowWidget(self)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._setup_widget()
|
|
|
|
|
|
|
|
self._palette_box = Gtk.VBox()
|
2013-11-29 13:09:53 +01:00
|
|
|
self._palette_box.pack_start(self._primary_event_box, False, True,
|
|
|
|
0)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._palette_box.pack_start(self._secondary_box, True, True, 0)
|
|
|
|
|
|
|
|
self._widget.add(self._palette_box)
|
|
|
|
self._palette_box.show()
|
|
|
|
height = style.GRID_CELL_SIZE - 2 * self._widget.get_border_width()
|
2013-11-29 13:09:53 +01:00
|
|
|
self._primary_event_box.set_size_request(-1, height)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
if self._content.get_children():
|
2007-09-30 00:20:27 +02:00
|
|
|
self._content.remove(self._content.get_children()[0])
|
2007-06-26 18:19:26 +02:00
|
|
|
|
2007-08-08 12:56:19 +02:00
|
|
|
if widget is not None:
|
2012-12-10 15:47:52 +01:00
|
|
|
widget.connect('button-release-event',
|
|
|
|
self.__widget_button_release_cb)
|
2007-08-08 12:56:19 +02:00
|
|
|
self._content.add(widget)
|
2007-09-22 00:43:14 +02:00
|
|
|
self._content.show()
|
|
|
|
else:
|
|
|
|
self._content.hide()
|
2007-06-26 18:19:26 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._content_widget = widget
|
|
|
|
|
2007-08-08 11:53:41 +02:00
|
|
|
self._update_accept_focus()
|
2007-09-22 00:43:14 +02:00
|
|
|
self._update_separators()
|
2007-05-24 19:37:48 +02:00
|
|
|
|
2012-12-10 15:47:52 +01:00
|
|
|
def __widget_button_release_cb(self, widget, event):
|
|
|
|
event_widget = Gtk.get_event_widget(event)
|
|
|
|
if isinstance(event_widget, PaletteMenuItem):
|
|
|
|
self.popdown(immediate=True)
|
|
|
|
return False
|
|
|
|
|
2012-04-18 22:29:15 +02:00
|
|
|
def get_label_width(self):
|
2011-11-15 19:29:07 +01:00
|
|
|
# Gtk.AccelLabel request doesn't include the accelerator.
|
2012-04-18 22:29:15 +02:00
|
|
|
label_width = self._label_alignment.get_preferred_width()[1] + \
|
2013-05-18 04:27:04 +02:00
|
|
|
self._label.get_accel_width()
|
2012-04-18 22:29:15 +02:00
|
|
|
return label_width
|
2007-09-22 00:13:33 +02:00
|
|
|
|
2007-09-22 00:43:14 +02:00
|
|
|
def _update_separators(self):
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
visible = self._content.get_children()
|
2007-08-08 12:56:19 +02:00
|
|
|
self._separator.props.visible = visible
|
|
|
|
|
2007-08-08 11:53:41 +02:00
|
|
|
def _update_accept_focus(self):
|
|
|
|
accept_focus = len(self._content.get_children())
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._widget.set_accept_focus(accept_focus)
|
2007-08-08 03:07:00 +02:00
|
|
|
|
2007-07-24 16:15:13 +02:00
|
|
|
def _update_full_request(self):
|
2009-08-01 00:04:28 +02:00
|
|
|
if self._palette_state == self.PRIMARY:
|
2008-09-07 21:51:10 +02:00
|
|
|
self._secondary_box.show()
|
2007-07-24 16:15:13 +02:00
|
|
|
|
2014-11-28 12:45:22 +01:00
|
|
|
if self._widget is not None:
|
|
|
|
self._full_request = self._widget.size_request()
|
2007-07-24 16:15:13 +02:00
|
|
|
|
2009-08-01 00:04:28 +02:00
|
|
|
if self._palette_state == self.PRIMARY:
|
2008-09-07 21:51:10 +02:00
|
|
|
self._secondary_box.hide()
|
2007-07-24 16:15:13 +02:00
|
|
|
|
2009-08-01 00:04:28 +02:00
|
|
|
def _set_palette_state(self, state):
|
|
|
|
if self._palette_state == state:
|
2007-07-24 15:53:35 +02:00
|
|
|
return
|
|
|
|
|
2007-08-24 14:21:07 +02:00
|
|
|
if state == self.PRIMARY:
|
2007-08-08 12:56:19 +02:00
|
|
|
self._secondary_box.hide()
|
2007-08-24 14:21:07 +02:00
|
|
|
elif state == self.SECONDARY:
|
2007-08-08 12:56:19 +02:00
|
|
|
self._secondary_box.show()
|
2009-08-01 13:23:06 +02:00
|
|
|
self.update_position()
|
2007-07-24 15:53:35 +02:00
|
|
|
|
2009-08-01 00:04:28 +02:00
|
|
|
self._palette_state = state
|
2007-07-24 15:53:35 +02:00
|
|
|
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
def get_menu(self):
|
|
|
|
assert self._content_widget is None
|
|
|
|
|
|
|
|
if self._widget is None \
|
|
|
|
or not isinstance(self._widget, _PaletteMenuWidget):
|
|
|
|
if self._widget is not None:
|
2013-11-29 13:09:53 +01:00
|
|
|
self._palette_box.remove(self._primary_event_box)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._palette_box.remove(self._secondary_box)
|
|
|
|
self._teardown_widget()
|
|
|
|
self._widget.destroy()
|
|
|
|
|
|
|
|
self._widget = _PaletteMenuWidget()
|
|
|
|
|
2013-11-29 13:09:53 +01:00
|
|
|
self._label_menuitem = _HeaderItem(self._primary_event_box)
|
Reimplement Palettes for GTK3
Moving from GTK2 to GTK3 has presented various challenges regarding
palettes.
In GTK2, we were able to access some internal API of the GtkMenu class
and use it to embed a GtkMenu in a regular window. As of GTK3, that API
has become private and we can no longer access it.
We still want to use GtkMenu for the advanced functionality it provides
(multiple-level menus, keyboard navigation, etc), but we are now limited
to popping it up with its own (internal) window, rather than being able
to pack it into one of our own.
Our palettes can historically be used either as a menu, or as a general
area where widgets can be added, or both. The new restrictions upon
GtkMenu force some changes here, but we work hard to stick to the old
API as far as possible.
A Palette instance now acts as a controller of either a "window widget"
(where any type of widget can be displayed as usual) or a "menu widget"
which just pops up a GtkMenu. A Palette defaults to the window mode, but
dynamically switches to menu mode if/when the user attempts to access
the menu element.
As a result of this, palettes can now pack either a user-defined collection
of widgets, or a menu, but types can no longer be mixed. This should
only affect a handful of palettes which will need to pick a single
approach and convert to it.
Some further challenges are presented by the fact that GtkMenu performs a
grab on the whole screen, meaning that all input events are delivered to
the GtkMenu widget. Through some careful event filtering and examination
of the mouse cursor position we are still able to determine when the mouse
has entered or left the invoker or menu areas.
This work is authored by Benjamin Berg, Marco Pesenti Gritti, Simon
Schampijer and Daniel Drake.
2011-12-15 02:53:48 +01:00
|
|
|
self._label_menuitem.show()
|
|
|
|
self._widget.append(self._label_menuitem)
|
|
|
|
|
|
|
|
self._setup_widget()
|
|
|
|
|
|
|
|
return self._widget
|
|
|
|
|
|
|
|
menu = GObject.property(type=object, getter=get_menu)
|
|
|
|
|
2014-06-24 16:18:57 +02:00
|
|
|
def _invoker_right_click_cb(self, invoker):
|
|
|
|
self.popup(immediate=True, state=self.SECONDARY)
|
|
|
|
|
|
|
|
def _invoker_toggle_state_cb(self, invoker):
|
|
|
|
if self.is_up() and self._palette_state == self.SECONDARY:
|
|
|
|
self.popdown(immediate=True)
|
|
|
|
else:
|
|
|
|
self.popup(immediate=True, state=self.SECONDARY)
|
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
class PaletteActionBar(Gtk.HButtonBox):
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2008-04-19 10:45:52 +02:00
|
|
|
def add_action(self, label, icon_name=None):
|
2011-11-15 19:29:07 +01:00
|
|
|
button = Gtk.Button(label)
|
2007-08-08 13:03:09 +02:00
|
|
|
|
|
|
|
if icon_name:
|
|
|
|
icon = Icon(icon_name)
|
|
|
|
button.set_image(icon)
|
|
|
|
icon.show()
|
|
|
|
|
2011-11-15 19:29:07 +01:00
|
|
|
self.pack_start(button, True, True, 0)
|
2007-08-08 13:03:09 +02:00
|
|
|
button.show()
|
|
|
|
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2007-07-02 12:05:42 +02:00
|
|
|
class _SecondaryAnimation(animator.Animation):
|
2009-08-25 21:12:40 +02:00
|
|
|
|
2007-07-02 12:05:42 +02:00
|
|
|
def __init__(self, palette):
|
|
|
|
animator.Animation.__init__(self, 0.0, 1.0)
|
|
|
|
self._palette = palette
|
|
|
|
|
|
|
|
def next_frame(self, current):
|
|
|
|
if current == 1.0:
|
2009-08-01 00:04:28 +02:00
|
|
|
self._palette.set_palette_state(Palette.SECONDARY)
|