Re: Popup positioning API

[Michael Natterer <mitch gimp org>]

On Mon, 2010-11-29 at 21:09 +0100, Alexander Larsson wrote:
> I've not had (and will really not have) much time to think about this in
> detail, but I think we have an issue with our window placement APIs that
> we have to get right before the 3.0 release.
> 
> Right now the placement of GTK_WINDOW_POPUP windows (for instance
> tooltips and menus) are entierly based on override-redirect semantics,
> i.e. we can get the current exact positions of the toplevels and place
> at an exact position a new undecorated toplevel. This is not really
> gonna be enough for future backends.
> 
> For instance, wayland will not let apps control position of windows like
> this, so popups will need to be placed by offset from another toplevel.
> See
> http://lists.freedesktop.org/archives/wayland-devel/2010-November/000270.html
> 
> Another example is my html backend. I've been pondering using separate
> browser windows for each toplevel, but this breaks for menus and other
> popups. These will need to have be put inside the right real toplevel.
> So, here we also need positioning relative to another toplevel.
> 
> A bunch of current APIs might need to be extended to make this work, for
> instance the GtkMenuPositionFunc. I haven't had time to look into the
> exact details, but we really should do so before freezing the APIs

I probably can't dedicate time to that myself before the release but I
totally agree. To be more precise, a GTK+ API to position popups should
provide a number of things:

- Pop up relative to any widget
- Pop up relative to one of the widget's corners, or to a position
  inside the widget
- Pop up in a certain logical direction
- Abstract away space/size/monitor-constrained popping up
  above/below and left/right of the parent widget
- All that correctly transformed for offscreen widgets
- Take the possibility of generic window rotation into account.

Volunteers? ;)

ciao,
--mitch