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

[Marco Pesenti Gritti]

Hey,

isn't the problem going away with GTK 3.0? From the release notes

"GDK has been rewritten to use ‘client-side windows’. This means that
GDK maintains its own window hierarchy and only uses X windows where
it is necessary or explicitly requested. "

Of course it would be nice to decouple de-hippo from the gtk 3 port,
but I'm not sure there is a good solution for this with gtk 2.

Marco

2011/9/15 Daniel Drake <dsd at laptop.org>:
> 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
>