You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
48ad255a78
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 | |
|---|---|---|
| bin | 13 years ago | |
| examples | 13 years ago | |
| m4 | 15 years ago | |
| po | 13 years ago | |
| src | 13 years ago | |
| tests | 13 years ago | |
| .gitignore | 13 years ago | |
| AUTHORS | 17 years ago | |
| COPYING | 17 years ago | |
| MAINTAINERS | 13 years ago | |
| Makefile.am | 13 years ago | |
| README | 17 years ago | |
| autogen.sh | 14 years ago | |
| configure.ac | 13 years ago | |
README
Sugar is the core of the OLPC Human Interface. The toolkit provides a set of widgets to build HIG compliant applications and interfaces to interact with system services like presence and the datastore.