Rather than require that the client implement two methods for every state,
simply have one global request, change_state, and one global event,
request_change_state.
Clients that need to be redrawn when the focus changes do that by
listening to focus_changed and scheduling a redraw.
This was causing unnecessary redraws in the clients, as could be
easily seen by changing focus on weston-flower.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Use a static assert to catch mismatch between implementation and
interface version. Fix window.c to not use XDG_SHELL_VERSION_CURRENT,
which will fail to catch version mismatches. The implementation version
must updated manually when the implementation is updated to use the new
interface.
Responsivenes is a per-client thing so we move the ping/pong functionality
to xdg_shell. Having this per-window was carries over from the EWMH
protocol, where the WM has no other way to do this. In wayland, the
compositor can directly ping the client that owns the surface.
This is used to figure out the size of "invisible" decorations, which we'll
use to better know the visible extents of the surface, which we can use for
constraining, titlebars, and more.
This is equivalent to WM_DELETE_WINDOW request under X11, or equivalent
to pressing the "close" button under CSD. Weston currently doesn't have
a compositor-side way to close the window, so no new code is needed on
its side.
When we set the fullscreen flag, we have to wait for the corresponding
configure event and then attach a buffer of that size to indicate
that we've successfully gone fullscreen/maximized.
Without this patch, we can schedule a redraw and go through with it after
setting maximize/fullscreen and end up attaching a buffer of the wrong size.
In practice, what happens is that pressing the maximize button triggers
setting maximized, but also triggers a redraw to paint the maxmize button.
Without this change, repainting the button triggers a repaint that attaches
the same size buffer immediately.
https://bugs.freedesktop.org/show_bug.cgi?id=71927
xdg_shell changes this around so that they are flags on the remote
object itself, not separate surface types. Move to a system where
we calculate the state from the flags ourselves and set the appropriate
wl_shell_surface type.
When we port to xdg_shell, we'll drop these flags and simply sync
on the client.
Transient windows, at least not as they are today, don't exist in
xdg_shell. Subsurfaces allow for specially placed surfaces relative
to a window, so use these instead.
The input region of the cursor surface is set to empty in
pointer_cursor_surface_configure(). Since during the commit process
this function is called before the pending input region is made
current, it empties surface->pending.input instead of surface->input.
But pointer_cursor_surface_configure() is also called from
pointer_set_cursor() in order to map the cursor even if there isn't a
subsequent attach and commit to the cursor surface. In that case,
surface->input is never emptied, since the configure function emptied
only the pending input region and there wasn't a commit that made it
effective.
Fix this by emptying both pending and current input regions. The latter
shouldn't cause problems since the surface can't have a role prior to
being assigned the cursor role, so it shouldn't be mapped in the first
place.
Also change toytoolkit so that it triggers the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73711
If we destroy a window with an active tooltip, we leave the tooltip
hanging around. Call tooltip destructor when destroying a window.
This fixes the stuck tooltip observed when unplugging a monitor with
an active tooltip on the panel.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72931
The subsurfaces example creates a subsurface widget and uses EGL to
render to it directly rather than using the cairo context from the
widget. In theory this shouldn't cause any problems because the westoy
window code lazily creates the cairo surface when an application
creates a cairo context. However commit fdca95c7 changed the behaviour
to force the lazy creation at the beginning of each surface redraw.
This ends up making the triangle surface get two attaches – one from
Cairo and one from the direct EGL.
It looks like it would be difficult to reinstate the lazy surface
creation behaviour whilst still maintaining the error handling for
surface creation because none of the redraw handlers in the example
clients are designed to cope with that. Instead, this patch adds an
explicit option on a widget to disable creating the Cairo surface and
the subsurface example now uses that.
Closes: https://bugs.freedesktop.org/show_bug.cgi?id=72854
It is quite possible for os_create_anonymous_file() to fail when trying
to allocate a new wl_shm buffer. Propagate this failure out from
shm_surface_prepare. Most parts of toytoolkit are already avoiding NULL
cairo surfaces.
If cairo surface allocation fails, do not try to call the widget redraw
functions, those are not prepared to deal with NULL. Also do not
schedule a frame callback, this allows us to retry drawing the next
time.
If redraw fails for the main_surface of a window, restore the widget
geometry to what the compositor currently is showing. This keeps the
window visual appearance in sync with application state, so interacting
with the application does not break too badly.
If the very first draw of any window fails, then forcefully exit the
program. E.g. if weston-desktop-shell fails to allocate buffers for the
unlock dialog, w-d-s exits, and weston unlocks the screen automatically.
This patch allows e.g. weston-terminal to stop from enlarging while
resizing, if new sized buffers can no longer the allocated. Even then,
the application stays usable, as it can often repaint in the last
successful size. It does not crash, and the user is able to resize it
smaller, too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Data device interface in client just handle with pointer's dnd.
If a touch screen trigger dnd, it will use pointer struct like i
nput->sx, input->sy, input->pointer_focus. So if pointer is moving
when touch screen trigeer a dnd, wrong behaviore will occur.
Before touch screen start dnd, system call touch_grab()
to mark the following drag and drop operation is generated by
touch screen.
Defined some common variables in struct input to track dnd.
Note, touch screen and pointer can't generate drag and drop at the
same time, becuae data device protocol can't identify the drag
and drop event is generated by touch screen or pointer.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Kristian Hogsberg <hoegsberg@gmail.com>
Adding the interface for touch screen event in clients/dnd.c, once
user touch down on this app, it will trigger a touch and drag
operation.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Kristian Hogsberg <hoegsberg@gmail.com>
It seems that this was only used by the popup menu infrastructure,
which can handle this all on its own. Implementing e.g. transients
in the future can be done with a simple xdg_shell_set_transient_for.
We used to ungrab first to stop any existing grab and then grab after
showing the menu. That was broken in c680e90489, which
moved the ungrab down below the grab, and as a result menus are now
shown without a grab. This commit moves the grab back up.
when output is removed, weston-desktop-shell should destroy panel
and background surface on destroyed output.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
