Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On Fri, 9 May 2014 20:09:43 -0400 Jasper St. Pierre jstpie...@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 hoegsb...@gmail.comwrote: 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 hoegsb...@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.olive...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
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 hoegsb...@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.olive...@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... Kristian Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On Tue, 6 May 2014 14:40:53 -0700 Kristian Høgsberg hoegsb...@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.olive...@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. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On 05/07/2014 01:47 AM, Pekka Paalanen wrote: 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. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Events aren't delivered to surfaces. They're delivered to clients. On Wed, May 7, 2014 at 2:02 PM, Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 01:47 AM, Pekka Paalanen wrote: 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. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Sorry, what I meant was the surface id and xy location in events. If a subsurface belongs to a different client than the parent surface, though, does this mean the child client will get events that have an xy position relative to the parent surface? On 05/07/2014 11:05 AM, Jasper St. Pierre wrote: Events aren't delivered to surfaces. They're delivered to clients. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On 7 May 2014 20:23, Bill Spitzak spit...@gmail.com wrote: If a subsurface belongs to a different client than the parent surface, though, does this mean the child client will get events that have an xy position relative to the parent surface? As a fundamental design point of the Wayland protocol is that clients cannot reference objects from other clients, this cannot happen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
Please always use reply-to-all, you have dropped a lot people from CC. On Wed, 07 May 2014 11:02:56 -0700 Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 01:47 AM, Pekka Paalanen wrote: 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. Are you saying that a sub-surface that extends outside the area of the parent surface should cause mouse/touch events in this extended area to be delivered to the parent? No. If a sub-surface can receive input events, the input events will refer the sub-surface's wl_surface. However, the window geometry for window management purposes is a very different thing. My personal feeling is that the intuitive approach that events are delivered normally to subsurfaces is the correct one. Especially if subsurfaces are going to be the method of embedding one client inside another. I think it is ok to say that subsurfaces with non-empty input areas are broken in toytoolkit. Sub-surfaces cannot be used to embed another client. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] window.c: Set the input region of the tooltip to empty
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Otherwise it might receive touch events. https://bugs.freedesktop.org/show_bug.cgi?id=78207 --- clients/window.c | 1 + 1 file changed, 1 insertion(+) diff --git a/clients/window.c b/clients/window.c index b7febed..f667cdf 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1992,6 +1992,7 @@ window_create_tooltip(struct tooltip *tooltip) widget_set_allocation(tooltip-widget, tooltip-x, tooltip-y + offset_y, extents.width + 20, 20 + margin * 2); + widget_input_region_add(tooltip-widget, NULL); return 0; } -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window.c: Set the input region of the tooltip to empty
On Mon, 5 May 2014 17:02:15 +0300 Ander Conselvan de Oliveira conselv...@gmail.com wrote: From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Otherwise it might receive touch events. https://bugs.freedesktop.org/show_bug.cgi?id=78207 Hi, I added a comment to the bug, as I am not sure the below change implements an expected behaviour, but I suppose it at least is an improvement nevertheless. Note, that at least I never added sub-surface input support to window.c, I always just ignored that case and assumed the app sets the input region to empty, as that was all that subsurfaces demo needed. Panel's tooltips must use a completely different implementation than normal window's tooltips, assuming xdg_shell gets the explicit tooltip protocol. Jasper? I suppose we can keep this patch for now, and come back to it when more xdg_shell work lands in master. I just wanted to make the note, that patch is not the end of the story. Thanks, pq --- clients/window.c | 1 + 1 file changed, 1 insertion(+) diff --git a/clients/window.c b/clients/window.c index b7febed..f667cdf 100644 --- a/clients/window.c +++ b/clients/window.c @@ -1992,6 +1992,7 @@ window_create_tooltip(struct tooltip *tooltip) widget_set_allocation(tooltip-widget, tooltip-x, tooltip-y + offset_y, extents.width + 20, 20 + margin * 2); + widget_input_region_add(tooltip-widget, NULL); return 0; } ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
