[Sugar-devel] de-hippo'd CanvasIcon: windowed or not?

[Daniel Drake]

Hi,

Me and Raul spent most of Sugarcamp Paris working on the no-hippo
project. We made great progress - many hacks in the previous efforts
were replaced with real code, and many temporarily removed bits of
functionality were restored.

However, we were left with one area of uncertainty: CanvasIcon.

To recap, CanvasIcon is currently a widget that shows an Icon and
tracks clicks and mouse cursor presence (to fire off a palette), that
can be placed in a hippocanvas. It is used for all the icons on the
home, friends and neighborhood views.

The biggest part of this project is replacing CanvasIcon with a
standard GTK-like widget, and replacing HippoCanvas with custom
gtk.Container code at the same time which can render its child widgets
(such as the new-style icon widget) at specific locations.

Hippo-style CanvasIcons do not have a window associated with them.
However, in our initial reimplementation, we have replaced it with a
windowed widget (using an EventBox). This seemed like the obvious
choice, given that mouse clicks and mouse enter/exit must be tracked.

This was all working well until we realised that we have the
requirement of partially overlapping icons in some cases. For example,
when loads of buddy icons are grouped in a circle around an activity
icon in the neighborhood view, they can sit together veeery snugly and
partially overlap. With our current choice of windowed icons (with
windows naturally rectangular in shape), this would not work well, as
the underlying rectangles would overlap neighbors and clip them badly.

We have thought up two possible solutions...
Firstly, we already catch expose events in our icon class so that we
can let cairo do the painting, we could simply make the windows
transparent at the same time as described here:
http://stackoverflow.com/questions/3908565/how-to-make-gtk-window-background-transparent

Or alternatively, we could make the icon widgets non-windowed, and
implement code in the (windowed) container class that tracks mouse
movements and tells its children about mouse-in/mouse-out/click
events. Presumably hippo had similar logic.


The transparency option seems rather simple, but is perhaps nasty in
that it basically decides to mess around with core window stuff when
GTK+ has its back turned. Also, when icons are overlapping, it seems
like the on-top window would receive the mouse event, even if the
mouse is physically closer to the centre of an icon that is sitting on
a lower layer.

The non-windowed icon idea sounds attractive in that it would
presumably result in less resource usage (fewer windows) but would
need some careful coding in the container classes. It would also avoid
the mouse event assignment problem as the distance to the centre of
each icon from the mouse cursor could be computed before deciding
which icon to pass events to.

Thoughts?

Replies before Sunday would be much appreciated - we'll be continuing
work on this then, and this is quite a pivotal decision for the
remaining tasks.

cheers
Daniel