Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 9:38 PM, Marco Pesenti Gritti ma...@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. Interesting, thanks for pointing that out. But I wonder how much this affects my question. Just ran some experiments. Regardless of the underlying implementation (X11 window or not), some widgets still have a GdkWindow associated with them, and some do not. In order to receive clicks and mouse movement events, you need to use a widget with an underlying GdkWindow. When painted on top of each other, GdkWindow-based widgets seem to continue to occupy a rectangular region and clip overlapping widgets with their background colour. So even though one of the lower levels has changed internally, the problem is still the same. However, with GTK3's change to directly pass in a cairo context to the expose/draw handler, it doesn't feel as hacky to set an alpha channel on it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 18 September 2011 18:19, Daniel Drake d...@laptop.org wrote: So even though one of the lower levels has changed internally, the problem is still the same. However, with GTK3's change to directly pass in a cairo context to the expose/draw handler, it doesn't feel as hacky to set an alpha channel on it. If my understanding is correct (I haven't tested) in GTK3 you should be able to get transparency by using either cairo_set_source_rgba in expose, gdk_window_set_background_rgba on a GdkWindow, or by specifying it in a theme css. None of these is an hack. At lower level what we get should be pretty much the same as hippo. I'm not sure about GTK2. I suppose it might work if X supports composite, you set an rgba colormap on the widget and you use cairo_set_source_rgba. I'm not quite sure it's worth to spend time on it because the results might vary depending on X/graphics hardware and we are going to use the client side path very soon anyway with the GTK3 port. So getting back to your question, I think we should go with the transparency option because it's not nasty but properly supported in GTK3. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
Trying to answer your initial email more clearly... 2011/9/15 Daniel Drake d...@laptop.org: 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. Without having tested, I don't think it's nasty in GTK3, it seems like a legitimate, supported use case. 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. Wouldn't solving this issue generally require to test if the mouse event is contained in the widget shape? Anyway I'm not sure this is something we need to solve now, I can't think of cases in our UI where it's important and it would not be a regression compared to hippo. Just my $0.01. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 18 Sep 2011, at 21:59, Marco Pesenti Gritti wrote: Trying to answer your initial email more clearly... 2011/9/15 Daniel Drake d...@laptop.org: 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. Without having tested, I don't think it's nasty in GTK3, it seems like a legitimate, supported use case. 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. Wouldn't solving this issue generally require to test if the mouse event is contained in the widget shape? Anyway I'm not sure this is something we need to solve now, I can't think of cases in our UI where it's important and it would not be a regression compared to hippo. Also worth noting that, in the case of potential touch, or touch only UIs, the design needs to avoid such close overlaps between finger sized targets. Accurate masks are great for Asteroid game type collision detection but not a good requirement for fat fingered, or poor motor controlled cursor interactions. Finger and cursor click target noise are fat and round, I love to hear there are some low level 'where statistically did the user really intend to hit' type events, am I dreaming? This obviously also causes issues for targets at the screen edge, but that's another issue... --Gary Just my $0.01. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 9:49 PM, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:48 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: On 15 September 2011 21:45, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti ma...@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... Why is that the case? I mean it seems like there shouldn't be an issue to keep depending on hippo with gtk2 and without introspection... Marco Maybe I am mistaken, but I thought hippo was dropped from F15 and had to be backported. No, the maintainer orphaned the package so it was going to be dropped for F-16 but I picked it up and will limp it along until we're ready to retire it. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
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
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti ma...@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 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 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 15 September 2011 21:49, Walter Bender walter.ben...@gmail.com wrote: Maybe I am mistaken, but I thought hippo was dropped from F15 and had to be backported. It seems to be included in stock F15 (and sugar is running on it). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 4:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: On 15 September 2011 21:49, Walter Bender walter.ben...@gmail.com wrote: Maybe I am mistaken, but I thought hippo was dropped from F15 and had to be backported. It seems to be included in stock F15 (and sugar is running on it). Marco So all the more reason not to go to far in working around Event Box for GTK 2. Let's move on to GTK 3 !!! -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On Thu, Sep 15, 2011 at 4:48 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: On 15 September 2011 21:45, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti ma...@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... Why is that the case? I mean it seems like there shouldn't be an issue to keep depending on hippo with gtk2 and without introspection... Marco Maybe I am mistaken, but I thought hippo was dropped from F15 and had to be backported. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 15 September 2011 21:45, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti ma...@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... Why is that the case? I mean it seems like there shouldn't be an issue to keep depending on hippo with gtk2 and without introspection... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
