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