In Gtk+ 3.20, you need to use the css name to select elements,
rather than the gtype name. Therefore, these must be added.
The css name must be set before the class instances are created, as
it effects the class rather than the instance. This is why it must
be places after the class definition.
Remove the vertical padding from the box that contain the toolbar, and
change the order of drawings in the container widget so that the
outline looks right. This has been tested with screenshots, see the
gif animation attached to the ticket.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
This adds a property that indicates that a Palette should
behave in a locking manner. The behaviour is the same
as with the secondary Toolbars: when you hover over the invoking
widget the Palette will popdown and react to mouse movements,
leaving the invoker area or the Palette itself will popdown
the Palette again. When you click the invoking widget
the Palette will be locked. You have to unlock it again
to pop it down.
This patch makes the DescriptionButton and the Colorbutton
work.
If the DescriptionButton or the Colorbutton are placed in
the primary toolbar they will share the locked state with
the secondary toolbars. Only one can be locked at a time.
When a secondary toolbar is unlocked we do force that the
open Palettes are closed. Having a locking Palette in
a subtoolbar will also work (Activity Toolbar case or
ColorButton case in a few examples). There is no state
sharing implemented here at the moment, but so far we
do only have cases with one lockable Palette in a
subtoolbar.
This will also fix the case where we want to use the
OSK to edit the description of the activity SL #3887.
Signed-off-by: Simon Schampijer <simon@laptop.org>
Acked-by: Manuel Quiñones <manuq@laptop.org>
- remove set_app_paintable from _Box to fix the bad coloring of
subtoolbars. The documentation say we can't rely on it to paint the
themed background when this is set [1].
- don't call Gtk.EventBox.do_draw in the _Box do_draw because that
will not paint the child toolbar. Call the child do_draw instead.
- revert 7fc29c9d which was a workaround for the most frequent usage
[1] http://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-app-paintable
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
The styling of this toolbar elements should be ported to the theme at
one point.
Signed-off-by: Manuel Quiñones <manuq@laptop.org>
Acked-by: Simon Schampijer <simon@laptop.org>
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>
