5 Commits (aa8a5e70c415e6c2acf4ff373d9b366ac4692bb1)

Author SHA1 Message Date
Pro-Panda aa8a5e70c4 Port from Python 2 to six
Signed-off-by: James Cameron <quozl@laptop.org>
5 years ago
Daniel Narvaez 01ed63ee4b Fixes for pep8 1.5 10 years ago
Daniel Drake 48ad255a78 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.
13 years ago
Sascha Silbe 820efa56b9 Run pygi-convert.sh for automatic conversion from GTK2 to GTK3 + pygi.
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>
13 years ago
Simon Schampijer 000ed75cbe Rename the module to sugar3
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>
13 years ago