The code which sends the button events was checking whether there is a
focus widget with a button handler but then always sending the button
event to the grab widget. If the grab widget is different from the
focus widget at this point then it will check the wrong widget for a
button handler and potentially crash. It is also possible for there to
be no grab widget here in the following situation:
1. Press and hold down the left mouse button
2. Press and hold down the right mouse button
3. Release the left mouse button
4. Release the right mouse button
In this case the grab will be released at step 3 because the code only
keeps track of the grab for one button. Then it will try to send the
release event for the right mouse button to a NULL widget so it will
crash.
When a menu self-destructs, free also the widget and struct menu.
As menus are self-destructing, it does not make sense to store the
window pointer, since we cannot clear it automatically. Therefore,
rename window_create_menu() to window_show_menu() that does not return
the window pointer. It also calls window_schedule_redraw() internally.
Fixes Valgrind reported memory leaks.
The alternative would be to explicitly destroy the menu in application's
menu callback.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Input devices may hold a pointer to the widget being destroyed. Reset
such pointers in widget_destroy().
This fixes a use-after-free in window_destroy(), if an application
destroys its widgets before the window.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Fix a memory leak reported by Valgrind, by destroying the window
decorations widget, if it exists.
All widget pointers returned from toytoolkit to the application should
be destroyed by the application explicitly.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The decorations were not responding, could not move or resize the
dialog, and it painted with a black shade.
When the dialog is created, schedule a resize instead of a repaint. The
resize will initialise the widget tree, and let everything draw and work
as it should.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In the great toytoolkit widget revolution, wscreensaver demo mode lost
its window decorations. Bring them back.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Fixes the following build failure:
In file included from window.c:58:0:
window.h:194:16: error: redefinition of typedef 'widget_resize_handler_t'
window.h:178:16: note: previous declaration of 'widget_resize_handler_t' was here
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
With all input events going to widgets now, we can grab an input device
to a widget, so that all events are delivered to that widgets handlers.
This lets us implement the last bit of the menu behaviour, that is
the client side grabbing of events. The result is that we can now pop down
the menu when we receive clicks in the clients own windows and we
don't send motion and button events to other widgets.
This lands the basic behavior of the popup surface type, but there are still
a number of details to be worked out. Mainly there's a hardcoded timeout
to handle the case of releasing the popup button outside any of the
client windows, which triggers popup_end if it happens after the timeout.
Maybe we just need to add that as an argument, or we could add a new event
that fires in this case to let the client decide whether it ends the popup
or not.
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
Kristian Høgsberg
Neil Roberts
Pekka Paalanen