Re: [Sugar-devel] State of Palettes for GTK+ 3.x
On Thu, Nov 3, 2011 at 2:59 PM, Benjamin Berg ben...@sugarlabs.org wrote: Palettes are still very broken in the sugar-toolkit-gtk3 branch. The problem is not very simple, and there is some unexpected trouble that we have not been able to figure out yet. For those that haven't heard any details, I'll try to explain what is going on here. In GTK+ 3.x we are not able to use the current hack to embed menus into normal palettes. The idea that we came up with during the Hackfest was to create two separate implementations (the API stays the same). So that either a sugar palette is popped up, or a sugarized GTK+ menu. Alone the fact that we are using a normal GTK+ menu means, that we need to handle grabbing correctly (ie. the opened menu/palette gets all the events). At the same time, doing this also results in proper touchscreen support because palettes can be dismissed by clicking anywhere on the screen. What happens during a grab is, that one widget receives all events. These can be forwarded to other widgets so that they can act upon them. The palettegroup already forwards the mouse-enter/mouse-leave events to all invokers; the idea is that they can keep track of their state. The behaviour that we are currently trying to achive is, that the palette should close after a while when the mouse is outside of the invoker/palette. The trouble is, that we have not been able to figure out how the mouse-enter/mouse-leave events to achieve this. The result of this is that the menu palettes will continuously pop up and down again. We have now fixed this in the branch. While the suggested approach of making the non-menu style palettes perform a grab (like GtkMenu does) may have some value, we have managed to avoid this for now. The non-menu window style palettes are all working as before, and do not perform a grab. The menu-style palettes use GtkMenu and this does perform a grab, but we managed to figure out how we can handle events to do what we want. Marco determined how to filter the incoming enter/leave events in order to accurately determine when the mouse is inside/outside the palette. Unfortunately we do not always have access to enter/leave events for the invoker (try hovering over a toolbar palette invoker button, then moving the mouse away from the button without entering the palette -- no event generated), so we use motion events to track the position of the mouse relative to the invoker to determine when the mouse is inside/outside the invoker. Combining those things mean we have all the palette use cases working fine. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] State of Palettes for GTK+ 3.x
Hello, On Thu, 2011-11-03 at 23:54 +, Gary Martin wrote: This could only really work sanely from a design point of view if exposing a palette via a cursor hover/loiter also went away i.e. having to click outside somewhere to dismiss a palette that was auto triggered by a hovering action would be a painful UX. I guess this all stems from the design decision to have widgets with hover/right-click context menus that also have primary left-click actions. For touch, we'll need to cover this cast by having a touch and hold gesture mimic our current hover/right-click behaviour. Hm, I had not thought about the primary action yet. A touch and hold gesture seems like a pretty good solution. I guess we will also want the action to be accessible from a button inside the palette itself. I am wondering about the buttons that only use palettes as tooltips. In this case requiring the user to hold down for a while might be a bit weird, even if it is consistent with other palettes. But then, without hover you never get normal tooltips ... Benjamin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] State of Palettes for GTK+ 3.x
Hello, Palettes are still very broken in the sugar-toolkit-gtk3 branch. The problem is not very simple, and there is some unexpected trouble that we have not been able to figure out yet. For those that haven't heard any details, I'll try to explain what is going on here. In GTK+ 3.x we are not able to use the current hack to embed menus into normal palettes. The idea that we came up with during the Hackfest was to create two separate implementations (the API stays the same). So that either a sugar palette is popped up, or a sugarized GTK+ menu. Alone the fact that we are using a normal GTK+ menu means, that we need to handle grabbing correctly (ie. the opened menu/palette gets all the events). At the same time, doing this also results in proper touchscreen support because palettes can be dismissed by clicking anywhere on the screen. What happens during a grab is, that one widget receives all events. These can be forwarded to other widgets so that they can act upon them. The palettegroup already forwards the mouse-enter/mouse-leave events to all invokers; the idea is that they can keep track of their state. The behaviour that we are currently trying to achive is, that the palette should close after a while when the mouse is outside of the invoker/palette. The trouble is, that we have not been able to figure out how the mouse-enter/mouse-leave events to achieve this. The result of this is that the menu palettes will continuously pop up and down again. I am actually thinking about removing the popdown when the user leaves the palette with the mouse. My idea for the following steps and bugfixes would be: 1. Make normal palettes grab the input, as the menu palette does. 2. Forward mouse click events to the invoker so that it is still possible to interact with them (this is not possible right now) 3. Remove the popdown on mouse leave (only makes sense if 1. is done) 4. Add the title to the menu palette (menuitem likely to be set to insensitive so that it cannot be selected) At that point we should we should have usable palettes, that need to be dismissed by clicking somewhere outside. Hrm, this was longer than expected; I hope it makes sense without too much background, Benjamin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] State of Palettes for GTK+ 3.x
On 3 November 2011 20:59, Benjamin Berg ben...@sugarlabs.org wrote: I am actually thinking about removing the popdown when the user leaves the palette with the mouse. Do you mean change how the palettes behave? Or is just an implementation detail? Maro ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] State of Palettes for GTK+ 3.x
Hi Benjamin, On 3 Nov 2011, at 20:59, Benjamin Berg ben...@sugarlabs.org wrote: I am actually thinking about removing the popdown when the user leaves the palette with the mouse. This could only really work sanely from a design point of view if exposing a palette via a cursor hover/loiter also went away i.e. having to click outside somewhere to dismiss a palette that was auto triggered by a hovering action would be a painful UX. I guess this all stems from the design decision to have widgets with hover/right-click context menus that also have primary left-click actions. For touch, we'll need to cover this cast by having a touch and hold gesture mimic our current hover/right-click behaviour. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
