[PATCH weston] window.c: Set the input region of the tooltip to empty

[Pekka Paalanen]

On Fri, 9 May 2014 20:09:43 -0400
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> This requires a bit of insider knowledge: we're planning on
> adding a set_window_geometry request to xdg_shell explicitly
> override the window geometry rectangle for a surface. I don't
> think we've talked about this on the list before.

I may have seen a word fly by, maybe, but certainly I do not recall
seeing anything real. Thanks for the note.

> This makes subsurfaces viable for tooltips, with the caveat that
> the compositor can't do things like fade them in or out for
> create/destroy effects. The more I think about this, the more OK
> I am with it. The client should probably fade in/out tooltips
> themselves if it really wants fancy effects.

Right, if you say so.

> On Fri, May 9, 2014 at 3:48 PM, Kristian Høgsberg
> <hoegsberg at gmail.com>wrote:
> 
> > On Wed, May 07, 2014 at 11:47:08AM +0300, Pekka Paalanen wrote:
> > > On Tue, 6 May 2014 14:40:53 -0700
> > > Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> > >
> > > > On Mon, May 05, 2014 at 05:02:15PM +0300, Ander Conselvan
> > > > de Oliveira wrote:
> > > > > From: Ander Conselvan de Oliveira
> > > > > <ander.conselvan.de.oliveira at intel.com>
> > > > >
> > > > > Otherwise it might receive touch events.
> > > >
> > > > I think a better approach is to just hide the tooltip if it
> > > > (or the panel) gets touch events.  I don't think I agree
> > > > with Pekka that we can't use subsurfaces for this, but I
> > > > guess I'm not sure what the problem he sees there is.
> > >
> > > The panel is not a window, so sub-surfaces can be made to
> > > work there well enough.
> > >
> > > It is for normal windows like registered with xdg_shell where
> > > sub-surfaces are not suitable for tooltips. A sub-surface is
> > > a part of the window, not another window. A tooltip is not
> > > expected to change the window geometry, but a sub-surface
> > > does count into the window geometry. Extruding sub-surfaces
> > > therefore affect the (parent) window geometry. It is in the
> > > protocol spec.
> >
> > No, sure if no other geometry information is available.  For
> > xdg-shell windows, the window geometry overrides that though.
> > And I don't think there's a clear distinction between being
> > part of the window or being a separate window here, and I don't
> > see why it would useful...

If that removes the need for the compositor to ever identify tooltip
surfaces, then I suppose that is ok.

Would not even tiling window managers need to identify tooltips?
Otherwise they might accidentally clip away everything that goes
outside of the defined window geometry, especially if there is
another window next to it. Unless you add a special rule in the
window manager, that all sub-surfaces are drawn on top of all main
surfaces... but if the adjacent window also uses a sub-surfaces, the
tooltip might still get clipped by sub-surfaces but not the main
surface, which would look even funnier. Up to you, I've never dealt
with window management.

Hmm, I suppose the same question applies to also floating window
management. If you trigger a tooltip in a window that is not
top-most, would you expect that the tooltip may be obscured by
another window? If you use sub-surfaces instead of a specific
tooltip surface type, you cannot change this behaviour by a
compositor choice.

Don't forget to be explicit in the xdg_shell specification though,
that it overrides the wl_subcompositor specification, which is not
limited to desktop systems.


Thanks,
pq