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 <d...@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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel