First we needed to port the Palette code to use a minimum size. The default size
is two times the GRID_CELL_SIZE. Since the request-phase of the traditional GTK+
geometry management has been replaced by a height-for-width system [1] we have
to compensate for that. Furthermore we need to pass the invoker from the
PaletteWindow to the _PaletteWindowWidget for the gap calculation code for
drawing the border around the Palette.
We do the drawing of the border for the toolbutton in the base class, moved
this from the ToolbarButton and made sure we are drawing in the right order.
In the ToolButton we draw as well a black background for the ToolButton when
the Palette is up. While the mouse is over the button we can do that in the
theme, but not when the mouse moves over the Palette.
[1] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1525688
Signed-off-by: Simon Schampijer <simon@laptop.org>
This draws the grey line around the toolbutton icon with a gap at the
bottom and a grey line at the top of the subtoolbar. Furthermore it
gets the highlightning of the button correct, in the pressed and hover
state. This patch depends on the sugar-artwork patch with the id
7464b808eb12b1df650952e3c8214acff1d1360f.
Signed-off-by: Gonzalo Odiard <gonzalo@laptop.org>
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
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.
With PyGTK, all parameters of the Alignment constructor had defaults [1].
With GTK3+pygi, when using the explicit constructor (Alignment.new() resp.
gtk_alignment_new() [2]), all values would need to be passed. However when
using the GObject constructor, named properties can be passed in instead and
we only need to pass those that different from the default.
[1] http://developer.gnome.org/pygtk/stable/class-gtkalignment.html#constructor-gtkalignment
[2] http://developer.gnome.org/gtk/stable/GtkAlignment.html#gtk-alignment-new
Signed-off-by: Simon Schampijer <simon@schampijer.de>
[assembled from several patches; replaced description]
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
The following data fields that were provided by PyGTK are not accessible
directly in GTK3+pygi and need to be replaced by accessor calls:
Adjustment.lower
Adjustment.page_size
Adjustment.upper
Adjustment.value
Bin.child
Widget.parent
Widget.style
Widget.window
Based on patches by Daniel Drake <dsd@laptop.org>.
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
This is only on a best-effort basis; the code will be in a broken state after
this patch and need to be fixed manually.
The purpose of committing the intermediate, non-working output is to make it
reproducible. It's impractical to manually review the changes.
The exact version used was 4f637212f13b197a95c824967a58496b9e3b877c from the
main pygobject repository [1] plus a custom patch [2] that hasn't been sent
upstream yet.
[1] git://git.gnome.org/pygobject
[2] https://sascha.silbe.org/patches/pygobject-convert-sugar-20111122.patch
Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
The old gtk-2 based module will be present in
the 0.94 branch in the sugar-toolkit.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Sascha Silbe <silbe@activitycentral.com>
