[Sugar-devel] State of Palettes for GTK+ 3.x

[Daniel Drake]

On Thu, Nov 3, 2011 at 2:59 PM, Benjamin Berg <benzea at 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