Features/GTK3/Shell/Hippo Removal - Revision history

Manuq at 02:30, 28 June 2012

2012-06-28T02:30:31Z

← Older revision		Revision as of 22:30, 27 June 2012
Line 33:		Line 33:
	Implementation: In the Neighborhood view we use the [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line143 SpreadLayout] to position the icons. All the icons are part of the grid in order to do collision detection. We use the exiting [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/snowflakelayout.py snowflakelayout] to do the grouping of the buddy icons around an activity.		Implementation: In the Neighborhood view we use the [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line143 SpreadLayout] to position the icons. All the icons are part of the grid in order to do collision detection. We use the exiting [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/snowflakelayout.py snowflakelayout] to do the grouping of the buddy icons around an activity.

			===Journal Detail View===
			To get back the layout of the Journal Detail View a few things have been done. However we should look forward to do them with CSS in GTK+3. They are:

			* Setting the background color of the [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/journal/expandedentry.py#line61 ExpandedEntry] is done wrapping the container inside a gtk.EventBox as explained [http://www.pygtk.org/docs/pygtk/class-gtkwidget.html#method-gtkwidget--modify-bg here].

			* Setting the paddings of the different widgets is done wrapping them inside gtk.Aligment widgets. Example [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/journal/expandedentry.py#line73 here]. Paddings were managed before using hippo.CanvasBox.

			As said above, the intermediary code could be simplified after the switch to GTK+3. Today seems not possible, but should be doable in the future. There is a bug filed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=678790

	* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]		* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]

Walter: /* Shell */

2012-06-24T12:18:22Z

Shell

← Older revision		Revision as of 08:18, 24 June 2012
Line 10:		Line 10:

	==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 the 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:		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:
Line 19:		Line 19:
	Implementation: Implements a [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/viewcontainer.py SugarViewContainer] a GTKContainer which provides adding/removing of children. It expects to be passed an owner_icon and optionally an activity icon and a LayoutManager to take care of the positioning and sizing of the icons. There are different LayoutManagers adopted to the specific needs in each view. When the allocation happens the first time a setup is run to [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line55 create a grid] and allocate and position the owner icon. The grid is part of the ViewLayout: we will always have at least the owner icon in the Views with a fixed position so we need the grid in all of the views, the Grid is created the first time we are called to allocate the icons because we make it dependent on the requested allocation size of the container		Implementation: Implements a [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/viewcontainer.py SugarViewContainer] a GTKContainer which provides adding/removing of children. It expects to be passed an owner_icon and optionally an activity icon and a LayoutManager to take care of the positioning and sizing of the icons. There are different LayoutManagers adopted to the specific needs in each view. When the allocation happens the first time a setup is run to [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line55 create a grid] and allocate and position the owner icon. The grid is part of the ViewLayout: we will always have at least the owner icon in the Views with a fixed position so we need the grid in all of the views, the Grid is created the first time we are called to allocate the icons because we make it dependent on the requested allocation size of the container

	The owner icon (+ activity icon) is positioned in the center: this is done when we do allocate the icons because we need to know the allocation size requested for the container in order to calculate the exact position, this is only done once on setup of the ViewLayout, this must happen before we add the other icons otherwise we risk collisions (maybe that is a bug in the grid, ideally if you add an icon with a fixed position and there is an icon at this position already the non-fixed one should be moved away, but this is not the case ~~atm~~). The icons are added only once to the grid: when we need to allocate the size for the icons we do check if they are in the grid already, we use the positions if they are in the grid otherwise add them to the grid and get the position from the grid, this way the icons keep their positions when new icons are added or removed.		The owner icon (+ activity icon) is positioned in the center: this is done when we do allocate the icons because we need to know the allocation size requested for the container in order to calculate the exact position, this is only done once on setup of the ViewLayout, this must happen before we add the other icons otherwise we risk collisions (maybe that is a bug in the grid, ideally if you add an icon with a fixed position and there is an icon at this position already the non-fixed one should be moved away, but this is not the case at the moment). The icons are added only once to the grid: when we need to allocate the size for the icons we do check if they are in the grid already, we use the positions if they are in the grid otherwise add them to the grid and get the position from the grid, this way the icons keep their positions when new icons are added or removed.

	In the ViewLayout used in the Home View only the owner and current activity icon are added to the grid. The activity icons do already have collision detection in their layout algorithms.		In the ViewLayout used in the Home View only the owner and current activity icon are added to the grid. The activity icons do already have collision detection in their layout algorithms.

Erikos: /* Shell */

2012-06-24T11:58:01Z

Shell

← Older revision		Revision as of 07:58, 24 June 2012
Line 17:		Line 17:
	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.		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.

			Implementation: Implements a [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/viewcontainer.py SugarViewContainer] a GTKContainer which provides adding/removing of children. It expects to be passed an owner_icon and optionally an activity icon and a LayoutManager to take care of the positioning and sizing of the icons. There are different LayoutManagers adopted to the specific needs in each view. When the allocation happens the first time a setup is run to [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line55 create a grid] and allocate and position the owner icon. The grid is part of the ViewLayout: we will always have at least the owner icon in the Views with a fixed position so we need the grid in all of the views, the Grid is created the first time we are called to allocate the icons because we make it dependent on the requested allocation size of the container

			The owner icon (+ activity icon) is positioned in the center: this is done when we do allocate the icons because we need to know the allocation size requested for the container in order to calculate the exact position, this is only done once on setup of the ViewLayout, this must happen before we add the other icons otherwise we risk collisions (maybe that is a bug in the grid, ideally if you add an icon with a fixed position and there is an icon at this position already the non-fixed one should be moved away, but this is not the case atm). The icons are added only once to the grid: when we need to allocate the size for the icons we do check if they are in the grid already, we use the positions if they are in the grid otherwise add them to the grid and get the position from the grid, this way the icons keep their positions when new icons are added or removed.

			In the ViewLayout used in the Home View only the owner and current activity icon are added to the grid. The activity icons do already have collision detection in their layout algorithms.

	===Group View===		===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.		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.

	~~Implements a [http~~://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/viewcontainer.py SugarViewContainer] a GTKContainer which provides adding/removing of children. It expects to be passed an owner_icon and optionally an activity icon and a LayoutManager to take care of the positioning and sizing of the icons. There are different LayoutManagers adopted to the ~~specific needs in each~~ view~~. When the allocation happens~~ the ~~first time a setup is run to~~ [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#~~line55 create a grid~~] and allocate and position the owner icon. The grid is part of the ViewLayout: we will always have at least the owner icon in the Views with a fixed position so we need the grid in all of the views, the Grid is created the first time we are called to allocate the icons because we make it dependent on the requested allocation size of the container		Implementation: In the Group view we use the [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line143 SpreadLayout] to position the icons. All the icons are part of the grid in order to do collision detection.

	~~The owner icon (+ activity icon) is positioned in the center: this is done when we do allocate the icons because we need~~ to ~~know the allocation size requested for the container in order to calculate the exact~~ position~~, this is only done once on setup of~~ the ~~ViewLayout, this must happen before we add the other~~ icons otherwise we risk collisions (maybe that is a bug in the grid, ideally if you add an icon with a fixed position and there is an icon at this position already the non-fixed one should be moved away, but this is not the case atm). ~~The icons are added only once to the grid: when we need to allocate the size for~~ the icons ~~we do check if they~~ are in the grid ~~already, we use the positions if they are~~ in ~~the grid otherwise add them~~ to ~~the grid and get the position from the grid, this way the icons keep their positions when new icons are added or removed~~.

	===Neighborhood View===		===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.		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.

			Implementation: In the Neighborhood view we use the [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line143 SpreadLayout] to position the icons. All the icons are part of the grid in order to do collision detection. We use the exiting [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/snowflakelayout.py snowflakelayout] to do the grouping of the buddy icons around an activity.


	* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]		* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]

Erikos: /* Shell */

2012-06-24T11:50:57Z

Shell

← Older revision		Revision as of 07:50, 24 June 2012
Line 21:		Line 21:
	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.		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.

			Implements a [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/viewcontainer.py SugarViewContainer] a GTKContainer which provides adding/removing of children. It expects to be passed an owner_icon and optionally an activity icon and a LayoutManager to take care of the positioning and sizing of the icons. There are different LayoutManagers adopted to the specific needs in each view. When the allocation happens the first time a setup is run to [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port/blobs/master/src/jarabe/desktop/favoriteslayout.py#line55 create a grid] and allocate and position the owner icon. The grid is part of the ViewLayout: we will always have at least the owner icon in the Views with a fixed position so we need the grid in all of the views, the Grid is created the first time we are called to allocate the icons because we make it dependent on the requested allocation size of the container

			The owner icon (+ activity icon) is positioned in the center: this is done when we do allocate the icons because we need to know the allocation size requested for the container in order to calculate the exact position, this is only done once on setup of the ViewLayout, this must happen before we add the other icons otherwise we risk collisions (maybe that is a bug in the grid, ideally if you add an icon with a fixed position and there is an icon at this position already the non-fixed one should be moved away, but this is not the case atm). The icons are added only once to the grid: when we need to allocate the size for the icons we do check if they are in the grid already, we use the positions if they are in the grid otherwise add them to the grid and get the position from the grid, this way the icons keep their positions when new icons are added or removed.

	===Neighborhood View===		===Neighborhood View===

Erikos: /* Shell */

2012-06-24T11:34:47Z

Shell

@@ Line 11: / Line 11: @@
 ==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.
 * [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]

Erikos at 11:25, 24 June 2012

2012-06-24T11:25:58Z

← Older revision		Revision as of 07:25, 24 June 2012
Line 5:		Line 5:

	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.		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.

			* [http://git.sugarlabs.org/~erikos/sugar-toolkit/erikos-shell-port toolkit-gtk2 implementation]
			* [http://lists.sugarlabs.org/archive/sugar-devel/2012-June/038198.html toolkit-gtk3 patch]

			==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.



			* [http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port shell port repository]

Erikos: Toolkit

2012-06-24T11:16:50Z

Toolkit

New page

==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 [http://developer.gnome.org/gtk3/3.4/GtkEventBox.html 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.