Difference between revisions of "Features/GTK3/Shell/Hippo Removal"
(→Shell) |
|||
| Line 11: | Line 11: | ||
==Shell== | ==Shell== | ||
In th Shell we need to adopt to the new SugarCanvasIcon. There had been a rename to SugarEventIcon to better match the implementation. Furthermore we have to adjust to the API change that the size' property is now called 'pixel-size' to reflect that we expect a 'pixel-size' and not a [http://developer.gnome.org/gtk3/3.4/gtk3-Themeable-Stock-Images.html#GtkIconSize GtkIconSize] as we use for most of the cases in the SugarIcon. | In th Shell we need to adopt to the new SugarCanvasIcon. There had been a rename to SugarEventIcon to better match the implementation. Furthermore we have to adjust to the API change that the size' property is now called 'pixel-size' to reflect that we expect a 'pixel-size' and not a [http://developer.gnome.org/gtk3/3.4/gtk3-Themeable-Stock-Images.html#GtkIconSize GtkIconSize] as we use for most of the cases in the SugarIcon. | ||
| + | |||
| + | Then the hippo-based layout in the Views has to be switched to use a GTKContainer instead of a the hippo layout management. The layout is the following: | ||
| + | |||
| + | ===Home View=== | ||
| + | Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size and the current activity icon below it. We have different layouts that can be applied to position the icons and have them at different sizes. A special mode is here the random layout where icons can be dragged around to change their position. | ||
| + | |||
| + | |||
| + | ===Group View=== | ||
| + | Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size. We have here an N number of buddy icons spread out over the view. There has to be some error handling that the icons do not overlap. | ||
| + | |||
| + | |||
| + | |||
| + | ===Neighborhood View=== | ||
| + | Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size. We have here an N number of buddy icons, activity icons and network icons spread out over the view. In addition the buddy icons can be grouped around an activity icon. There has to be some error handling that the icons do not overlap. | ||
* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository] | * [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository] | ||
Revision as of 07:34, 24 June 2012
Toolkit
The main thing in the toolkit is to remove the hippo dependency from the SugarCanvasIcon (icon.py) which is used in the shell in the Views (e.g. the activity icons, the buddy icons and the network icons) and in the Journal. The requirements to that widget are that it is an icon that can receive events. Attention has to be made to make sure that there is no visual nastiness when the icons are drawn closely together (e.g. buddy icons grouped around an activity).
A GtkEventBox can be used to receive the events even so the widget you place into that box does not have it's own window. We can put the IconBuffer from icon.py into that box, which is only used for drawing the icon, all the events are then handled by the GtkEventBox.
There is an attribute whether the event box uses a visible or invisible child window. However in GTK3, windowed widgets are no longer windows at the X level, so they can theoretically overlap without visual nastiness.
Shell
In th Shell we need to adopt to the new SugarCanvasIcon. There had been a rename to SugarEventIcon to better match the implementation. Furthermore we have to adjust to the API change that the size' property is now called 'pixel-size' to reflect that we expect a 'pixel-size' and not a GtkIconSize as we use for most of the cases in the SugarIcon.
Then the hippo-based layout in the Views has to be switched to use a GTKContainer instead of a the hippo layout management. The layout is the following:
Home View
Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size and the current activity icon below it. We have different layouts that can be applied to position the icons and have them at different sizes. A special mode is here the random layout where icons can be dragged around to change their position.
Group View
Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size. We have here an N number of buddy icons spread out over the view. There has to be some error handling that the icons do not overlap.
Neighborhood View
Requirement: In the center of the view we do have an the owner buddy at a fixed position in a specified size. We have here an N number of buddy icons, activity icons and network icons spread out over the view. In addition the buddy icons can be grouped around an activity icon. There has to be some error handling that the icons do not overlap.