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

[Walter Bender]

On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti <marco at marcopg.org> wrote:
> 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.

The hippo support is disappearing faster than perhaps we'll be ready
to complete the GTK 3 migration so we may have no choice... but the
problematic cases seem pretty marginal as things go: the clusters in
the neighborhood view. I cannot think of any other cases where our
icons get packed so tightly (maybe in the HomeView in the freeform
mode). So it maybe simpler to stick with Event Box and come up with a
short-term design work-around (I am thinking, for example, of just
lining up the buddies below the activity icon).

-walter
>
> 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
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org