sugar-toolkit-gtk3/src/sugar3/graphics/toolbarbox.py

337 lines
10 KiB
Python
Raw Normal View History

2009-07-29 14:42:43 +02:00
# Copyright (C) 2009, Aleksey Lim
#
# 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.
#
# 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
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
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
import math
from gi.repository import Gtk
from gi.repository import GObject
from sugar3.graphics import style
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, ToolInvoker, \
_PaletteWindowWidget
from sugar3.graphics.toolbutton import ToolButton
from sugar3.graphics import palettegroup
2009-08-25 21:12:40 +02:00
class ToolbarButton(ToolButton):
2009-08-25 21:12:40 +02:00
2009-08-01 13:23:06 +02:00
def __init__(self, page=None, **kwargs):
2009-07-12 03:42:23 +02:00
ToolButton.__init__(self, **kwargs)
2009-08-24 15:09:02 +02:00
self.page_widget = None
2009-08-01 13:23:06 +02:00
self.set_page(page)
self.connect('clicked',
2013-05-18 04:27:04 +02:00
lambda widget: self.set_expanded(not self.is_expanded()))
self.connect_after('draw', self.__drawing_cb)
self.connect('hierarchy-changed', self.__hierarchy_changed_cb)
def __hierarchy_changed_cb(self, tool_button, previous_toplevel):
parent = self.get_parent()
if hasattr(parent, 'owner'):
if self.page_widget and previous_toplevel is None:
self._unparent()
parent.owner.pack_start(self.page_widget, True, True, 0)
self.set_expanded(False)
2009-07-31 05:49:05 +02:00
def get_toolbar_box(self):
parent = self.get_parent()
if not hasattr(parent, 'owner'):
2009-07-12 03:42:23 +02:00
return None
return parent.owner
2009-07-12 03:42:23 +02:00
2009-07-31 05:49:05 +02:00
toolbar_box = property(get_toolbar_box)
2009-07-12 03:42:23 +02:00
def get_page(self):
2009-07-31 09:10:17 +02:00
if self.page_widget is None:
return None
2009-09-18 15:18:46 +02:00
return _get_embedded_page(self.page_widget)
2009-07-12 03:42:23 +02:00
def set_page(self, page):
2009-08-01 13:23:06 +02:00
if page is None:
self.page_widget = None
return
self.page_widget, alignment_ = _embed_page(_Box(self), page)
self.page_widget.set_size_request(-1, style.GRID_CELL_SIZE)
2009-07-12 03:42:23 +02:00
page.show()
2009-08-01 13:23:06 +02:00
if self.props.palette is None:
self.props.palette = _ToolbarPalette(invoker=ToolInvoker(self))
self._move_page_to_palette()
2009-07-12 03:42:23 +02:00
page = GObject.property(type=object, getter=get_page, setter=set_page)
2009-09-18 15:18:46 +02:00
def is_in_palette(self):
2009-09-18 14:24:48 +02:00
return self.page is not None and \
2013-05-18 04:27:04 +02:00
self.page_widget.get_parent() == self.props.palette._widget
2009-08-01 13:23:06 +02:00
2009-07-31 09:10:17 +02:00
def is_expanded(self):
2009-09-18 14:24:48 +02:00
return self.page is not None and \
2013-05-18 04:27:04 +02:00
not self.is_in_palette()
2009-07-12 03:42:23 +02:00
2009-07-31 09:10:17 +02:00
def popdown(self):
if self.props.palette is not None:
self.props.palette.popdown(immediate=True)
2009-07-12 03:42:23 +02:00
2009-07-31 09:10:17 +02:00
def set_expanded(self, expanded):
self.popdown()
palettegroup.popdown_all()
2009-07-31 09:10:17 +02:00
2009-09-18 14:24:48 +02:00
if self.page is None or self.is_expanded() == expanded:
2009-07-31 09:10:17 +02:00
return
2009-07-12 03:42:23 +02:00
2009-07-31 09:10:17 +02:00
if not expanded:
2009-08-01 13:23:06 +02:00
self._move_page_to_palette()
2009-07-31 09:10:17 +02:00
return
2009-07-12 03:42:23 +02:00
2009-09-18 13:25:32 +02:00
box = self.toolbar_box
2009-07-31 09:10:17 +02:00
if box.expanded_button is not None:
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
box.expanded_button.queue_draw()
2009-07-31 09:10:17 +02:00
box.expanded_button.set_expanded(False)
2009-09-18 13:25:32 +02:00
box.expanded_button = self
2009-07-12 03:42:23 +02:00
2009-09-18 14:24:48 +02:00
self._unparent()
self.modify_bg(Gtk.StateType.NORMAL, box.background)
2009-07-31 09:10:17 +02:00
_setup_page(self.page_widget, box.background, box.props.padding)
box.pack_start(self.page_widget, True, True, 0)
2009-09-18 14:24:48 +02:00
def _move_page_to_palette(self):
2009-09-18 15:18:46 +02:00
if self.is_in_palette():
2009-09-18 14:24:48 +02:00
return
self._unparent()
if isinstance(self.props.palette, _ToolbarPalette):
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.props.palette._widget.add(self.page_widget)
2009-09-18 14:24:48 +02:00
def _unparent(self):
page_parent = self.page_widget.get_parent()
if page_parent is None:
2009-09-18 14:24:48 +02:00
return
page_parent.remove(self.page_widget)
2009-09-18 14:24:48 +02:00
def __drawing_cb(self, button, cr):
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
alloc = self.get_allocation()
context = self.get_style_context()
context.add_class('toolitem')
context.add_class('toolbar-down')
if not self.is_expanded() or self.props.palette is not None and \
self.props.palette.is_up():
ToolButton.do_draw(self, cr)
_paint_arrow(self, cr, math.pi)
return False
Gtk.render_frame_gap(context, cr, 0, 0, alloc.width, alloc.height,
Gtk.PositionType.BOTTOM, 0, alloc.width)
_paint_arrow(self, cr, 0)
return False
2009-08-25 21:12:40 +02:00
class ToolbarBox(Gtk.VBox):
2009-08-25 21:12:40 +02:00
__gtype_name__ = 'SugarToolbarBox'
def __init__(self, padding=style.TOOLBOX_HORIZONTAL_PADDING):
GObject.GObject.__init__(self)
2009-09-18 13:25:32 +02:00
self._expanded_button_index = -1
2009-08-01 13:27:56 +02:00
self.background = None
self._toolbar = Gtk.Toolbar()
2009-07-31 12:25:01 +02:00
self._toolbar.owner = self
self._toolbar.connect('remove', self.__remove_cb)
2009-07-12 03:42:23 +02:00
2009-09-18 14:24:48 +02:00
self._toolbar_widget, self._toolbar_alignment = \
2013-05-18 04:27:04 +02:00
_embed_page(Gtk.EventBox(), self._toolbar)
self.pack_start(self._toolbar_widget, True, True, 0)
self.props.padding = padding
self.modify_bg(Gtk.StateType.NORMAL,
2013-05-18 04:27:04 +02:00
style.COLOR_TOOLBAR_GREY.get_gdk_color())
2009-09-18 14:24:48 +02:00
def get_toolbar(self):
return self._toolbar
toolbar = property(get_toolbar)
2009-09-18 13:25:32 +02:00
def get_expanded_button(self):
if self._expanded_button_index == -1:
return None
2009-09-18 14:24:48 +02:00
return self.toolbar.get_nth_item(self._expanded_button_index)
2009-09-18 13:25:32 +02:00
def set_expanded_button(self, button):
2014-03-29 20:25:34 +01:00
if button not in self.toolbar:
2009-09-18 13:25:32 +02:00
self._expanded_button_index = -1
return
2009-09-18 14:24:48 +02:00
self._expanded_button_index = self.toolbar.get_item_index(button)
2009-09-18 13:25:32 +02:00
expanded_button = property(get_expanded_button, set_expanded_button)
def get_padding(self):
2009-09-18 14:24:48 +02:00
return self._toolbar_alignment.props.left_padding
def set_padding(self, pad):
2009-09-18 14:24:48 +02:00
self._toolbar_alignment.set_padding(0, 0, pad, pad)
padding = GObject.property(type=object,
2013-05-18 04:27:04 +02:00
getter=get_padding, setter=set_padding)
2009-07-12 03:42:23 +02:00
def modify_bg(self, state, color):
if state == Gtk.StateType.NORMAL:
2009-07-31 09:10:17 +02:00
self.background = color
2009-09-18 14:24:48 +02:00
self._toolbar_widget.modify_bg(state, color)
self.toolbar.modify_bg(state, color)
2009-09-18 14:24:48 +02:00
def __remove_cb(self, sender, button):
if not isinstance(button, ToolbarButton):
return
button.popdown()
if button == self.expanded_button:
self.remove(button.page_widget)
self._expanded_button_index = -1
if hasattr(ToolbarBox, 'set_css_name'):
ToolbarBox.set_css_name('toolbarbox')
2009-09-18 14:24:48 +02:00
2009-08-25 21:12:40 +02:00
2009-08-01 13:23:06 +02:00
class _ToolbarPalette(PaletteWindow):
2009-08-25 21:12:40 +02:00
2009-08-01 13:23:06 +02:00
def __init__(self, **kwargs):
PaletteWindow.__init__(self, **kwargs)
self._has_focus = False
group = palettegroup.get_group('default')
group.connect('popdown', self.__group_popdown_cb)
2009-09-18 13:25:32 +02:00
self.set_group_id('toolbarbox')
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 = _PaletteWindowWidget()
self._widget.set_border_width(0)
self._setup_widget()
self._widget.connect('realize', self._realize_cb)
2009-09-18 13:25:32 +02:00
def get_expanded_button(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
return self.invoker.parent
2009-09-18 13:25:32 +02:00
expanded_button = property(get_expanded_button)
def on_invoker_enter(self):
PaletteWindow.on_invoker_enter(self)
self._set_focus(True)
def on_invoker_leave(self):
PaletteWindow.on_invoker_leave(self)
self._set_focus(False)
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)
self._set_focus(True)
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_leave(self):
PaletteWindow.on_enter(self)
self._set_focus(False)
def _set_focus(self, new_focus):
self._has_focus = new_focus
if not self._has_focus:
group = palettegroup.get_group('default')
if not group.is_up():
self.popdown()
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 _realize_cb(self, widget):
screen = self._widget.get_screen()
width = screen.width()
self._widget.set_size_request(width, -1)
2009-08-01 13:23:06 +02:00
def popup(self, immediate=False):
2009-09-18 13:25:32 +02:00
button = self.expanded_button
2009-08-01 13:23:06 +02:00
if button.is_expanded():
return
box = button.toolbar_box
_setup_page(button.page_widget, style.COLOR_BLACK.get_gdk_color(),
2013-05-18 04:27:04 +02:00
box.props.padding)
PaletteWindow.popup(self, immediate)
def __group_popdown_cb(self, group):
if not self._has_focus:
self.popdown(immediate=True)
2009-08-01 13:23:06 +02:00
2009-08-25 21:12:40 +02:00
class _Box(Gtk.EventBox):
2009-08-25 21:12:40 +02:00
def __init__(self, toolbar_button):
GObject.GObject.__init__(self)
self._toolbar_button = toolbar_button
def do_draw(self, cr):
self.get_child().do_draw(self, cr)
button_alloc = self._toolbar_button.get_allocation()
cr.set_line_width(style.FOCUS_LINE_WIDTH * 2)
cr.set_source_rgba(*style.COLOR_BUTTON_GREY.get_rgba())
cr.move_to(0, 0)
cr.line_to(button_alloc.x + style.FOCUS_LINE_WIDTH, 0)
2013-05-18 04:27:04 +02:00
cr.move_to(
button_alloc.x + button_alloc.width - style.FOCUS_LINE_WIDTH, 0)
cr.line_to(self.get_allocation().width, 0)
cr.stroke()
2009-08-25 21:12:40 +02:00
def _setup_page(page_widget, color, hpad):
page_widget.get_child().set_padding(0, 0, hpad, hpad)
2009-09-18 15:18:46 +02:00
page = _get_embedded_page(page_widget)
page.modify_bg(Gtk.StateType.NORMAL, color)
if isinstance(page, Gtk.Container):
for i in page.get_children():
i.modify_bg(Gtk.StateType.INSENSITIVE, color)
page_widget.modify_bg(Gtk.StateType.NORMAL, color)
page_widget.modify_bg(Gtk.StateType.PRELIGHT, color)
2009-08-25 21:12:40 +02:00
def _embed_page(page_widget, page):
2009-09-18 13:25:32 +02:00
page.show()
alignment = Gtk.Alignment(xscale=1.0, yscale=1.0)
2009-09-18 13:25:32 +02:00
alignment.add(page)
alignment.show()
2009-09-18 13:25:32 +02:00
page_widget.modify_bg(Gtk.StateType.ACTIVE,
2013-05-18 04:27:04 +02:00
style.COLOR_BUTTON_GREY.get_gdk_color())
2009-09-18 13:25:32 +02:00
page_widget.add(alignment)
page_widget.show()
2009-09-18 14:24:48 +02:00
return (page_widget, alignment)
2009-09-18 15:18:46 +02:00
def _get_embedded_page(page_widget):
return page_widget.get_child().get_child()
2009-08-25 21:12:40 +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 _paint_arrow(widget, cr, angle):
alloc = widget.get_allocation()
arrow_size = style.TOOLBAR_ARROW_SIZE / 2
y = alloc.height - arrow_size
x = (alloc.width - arrow_size) / 2
context = widget.get_style_context()
context.add_class('toolitem')
2009-07-30 13:29:52 +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
Gtk.render_arrow(context, cr, angle, x, y, arrow_size)