The broadway backend would move the focus from one window to another based on
where the mouse was (i.e. 'focus-follows-mouse' approach). Handling the focus
this wait didn't play well with widgets which rely on focus-in-event and
focus-out-event, like the GtkEntry when using a completion popup window, see
e.g:
https://bugzilla.gnome.org/show_bug.cgi?id=708984
So instead, setup broadway to require a click in a window to move the focus
(i.e. 'click-to-focus' approach):
* The implicit GDK_FOCUS_CHANGE events that were generated upon reception of
BROADWAY_EVENT_ENTER or BROADWAY_EVENT_LEAVE are removed.
* The broadway daemon will now keep track of which is the focused window
* Whenever the daemon detects an incoming BROADWAY_EVENT_BUTTON_PRESS, it will
trigger the focused window switch, which sends a new BROADWAY_EVENT_FOCUS to
the client, specifying which windows holds the focus.
* Upon reception of a BROADWAY_EVENT_FOCUS, the client will generate a new
GDK_FOCUS_CHANGE.
* gdk_broadway_window_focus() was also implemented, which now requests the
focus to the broadway server using a new BROADWAY_REQUEST_FOCUS_WINDOW.
This is based on an initial patch from Aleksander Morgado <aleksander@lanedo.com>.
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
We don't want to update the window size on configure event, only
the position, as the size is client side controlled. We were
updating to an old size during resizes which causes us to send
surfaces of the wrong size to the daemon.
When events are paused, we should not return TRUE from prepare() or check().
GTK+ handles this for events that are already in the GTK+ queue, but
we also need suppress checks for events that are in the system queue - if we
return TRUE indicating that there are events in the system queue, then we'll
call dispatch(), and do nothing. The event source will spin, and will never
run the other phases of the paint clock.
(Broadway doesn't have a window system queue separate from the GDK event queue,
but we write the function the same way for consistency.)
https://bugzilla.gnome.org/show_bug.cgi?id=694274
This (shouldn't) change any behaviour, but it moves the
webserver parts to a separate file, making the broadway display file
smaller and preparing for later separating out the server to its own
process.
We can't really know the client side keymaps, so we use the keysym
as the hardware keycode (essentially claiming to have a keyboard with
one key for all possible keysyms). This is not ideal, but its hard to
do better with no knowledge of the client side keyboard mappings.
(And html keyboard events suck badly...)
Event times come from the browser and may change weirdly when we reconnect
with another browser, so we normalize these to be strictly increasing
and with a 5 second gap for each reconnect.
This just runs:
for i in *.[ch]; do
sed -i s/DisplayX11/DisplayBroadway/g $i;
sed -i s/PrivateX11/PrivateBroadway/g $i;
sed -i s/ImplX11/ImplBroadway/g $i;
sed -i s/KeymapX11/KeymapBroadway/g $i;
sed -i s/ScreenX11/ScreenBroadway/g $i;
sed -i s/GdkX11Monitor/GdkBroadwayMonitor/g $i;
sed -i s/_X11/_BROADWAY/g $i;
sed -i s/x11/broadway/g $i;
done
