GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
It seems that posix_fallocate gives an ENODEV error when
called on an fd opened with shm_open on freebsd. Fix up
the error check to only trigger if we get ENOSPC.
https://bugzilla.gnome.org/show_bug.cgi?id=742980
In various places, the broadway backend was just using
the default display and assumed that it is the broadway
display. That may not be the case in a multi-backend world,
so instead iterate over all displays and use the first
broadway display - still not perfect, but enough to survive
for now.
The current implementation of this script generate headers with \x-escaped
strings that can become too long (> 65535 characters) for Visual Studio
to consume, hence the build of broadwayd would break on Visual Studio.
This changes the script to instead format the string as an array of hex
characters, not unlike what GResource does, so that builds can continue as
normal on Visual Studio builds as well.
https://bugzilla.gnome.org/show_bug.cgi?id=739001
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
At the present time broadway listens only for TCP/IP incoming
display connections. This patch implements the support for listening
on unix domain sockets too, adding the broadway_server_on_unix_socket_new()
constructor and the commandline option --unixsocket [path] to broadwayd.
https://bugzilla.gnome.org/show_bug.cgi?id=734420
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
eb1ab0dac2 removed support for authentication
based on crypt()-hashed passwords but it didn't remove the header.
Finish up with the removal.
This allows the broadway backend to build on FreeBSD (which has no
crypt.h).
https://bugzilla.gnome.org/show_bug.cgi?id=726149
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
We add a custom im module for broadway that calls some broadway
specific APIs to show/hide the keyboard on focus in/out. We then forward this
to the browser, and on the ipad we focus an input field to activate
the keyboard.
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
This is based on the rolling hashes code from
http://cgit.freedesktop.org/~krh/weston/log/?h=remote
It works by incrementally calculating hashes for every 32x32 block
in each frame sent, and then refering back to such blocks when
encoding the next frame. This means we detect when a block matches
an existing block in the previous frame in a different position.
This is great for detecting scrolling, which we need now that
the gdk level scrolling is neutered.
If we're going to run off the end due to an invalid message,
we're going to run off the end. We'll protect this by doing
proper bounds checking in the future, but the malloc gives
us nothing for now.
We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
-Don't include unistd.h unconditionally as it's not available in Visual
Studio, but include io.h where necessary.
-Avoid C99isms, and use _chsize_s in place of ftruncate when unistd.h is
not available (as in the case of Visual Studio)
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
A function was doing nothing but calling a function that was in its own
source file doing nothing but calling a function in its own source file
that did nothing.
This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
This way we don't have to reopen all the time for pure updates,
and we can immediately unlink the shm file to avoid "leaking" them
on improper shutdown.
We now only update surface data after we have painted. Before we painted
in an idle, which meant we might send black data some times if we e.g.
resized the window and had not painted yet. Also, it means we're updating
less often to the daemon, saving resources.
We still have to queue a flush in the idle for non-draw operations,
otherwise e.g. resize of a toplevel will never be flushed if the clock
is frozen (e.g. during toplevel resize).
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.
Requests are not limited in size by BroadwayRequest, as
BroadwayRequestTranslation can be of variable size. No need
to copy the request anymore though, because requests are aligned
now.
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
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
With this we always roundtrip position change to the webbrowser.
This avoids conflicts when things change from both directions (app and user).
Also, we fake configure evens when there is no web client to ensure
apps get the events.
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.
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
g_checksum_get_digest checks to ensure that the passed digest_len is long
enough to hold the digest, before setting it to the actual length of the
digest returned. Digest_len is uninitialized in the code, so if you're
lucky it will be larger than 20 and everything will work fine. If you're
unlucky, g_checksum_get_digest will return either -1 or some number less
than 20, and the g_assert(digest_len==20) will fail.
Allows more modern browsers eg. firefox 5+ to use gtk/broadway
Auto-detects protocol version, and can switch between them at
as you connect a different browser.
This works to some extent, but seems to hang sometimes, for
instance the "button box" test in testgtk never shows up.
In 2.x, the !HAVE_XCONVERTCASE fallback of keyval_convert_case() was
implicitly used as implementation for all !X11 backends.
In 3.x, when this function was virtualized in GdkDisplayManager,
this fallback was moved to the X11 backend and the other backends
"equipped" with /* FIXME implement */ implementations of
keyval_convert_case() which don't convert anything.
Move the fallback code back to gdk/ as default implementation
of GdkDisplayManager::keyval_convert_case() and remove its
implementations is all backends but X11. Also remove the
implementation in Wayland which was a plain copy of what
is now the default implementation.
(cherry picked from commit f46c1b76d8)
The zlib compressed xmlhttprequest thing was a nice hack, but it doesn't
really work in production. Its not portable, doesn't have enought API
(missing notification for closed sockets) and having to synchronize
between two different connections in a reliable way is a pain.
So, we're going everything over the websocket. This is a pure switch,
but after this we want to modify the protocol to work better over
the uncompressed utf8 transport of websockets.
Some special key keycode values as seen in keydown actually match
normal keys (like "." has a keyCode 46 on keyPress, which is the same
as Delete, but 190 for KeyDown). So we must match the special keys on
keypress. However, some things must be checked on keydown as they are not
generating keypress events.
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...)
We're using the noVNC keyboard even handling model (and some of the
code with permissions). This means we combine data from keydown and
keypress to figure out the translated keysyms according to the keyboard
layout at the users machine.
As soon as something changes, even if it was a request from the user
we send a configure event. If not we might race with a app-side
generated configure event.
For instance, a create + resize might create only a configure event for
the create in the browser, but that may get to the app after the app-side
configure event for the resize, overriding the new size.
* Always calculate the context, don't store in surface.
* Store the toplevel element (frame or canvas) for easy access.
* Always use visibility hidden rathern than display none to hide windows,
as this means we can always rely on dom positioning info.
When syncing windows, make sure we set transient-for before showing
the window to avoid it being visible with the wrong transient-for
(i.e. possibly on the wrong browser window).
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 mode makes each toplevel window get its own browser window, with
popup windows using the browser window of their transient parent.
Its not idea, as you can't get rid of all browser chrome by default, and
it means popups (like menus) can't extend outside the toplevels. But, it is
kinda cool.
Since we're really only initializing grabs (except for implicit
grabs at least) from the client side we might as well do all the grab
time checks on the client side to avoid unnecassary roundtrips.
Ensure that we're writing all the updates for a single rendering op
in one go without callbacks inbetween. That way some rendering will
be delayed, but the user will never see partial renderings.
We do this because we need to be able to switch to using sync reads
when we're doing a roundtripping call, and that is too complex
with the async code.
The true diff only works if the destination keeps perfect 32bit
canvas data, which is not always true. So, instead we send only
changed pixels, masking the others to 0 via alpha 0.
