kind of a workaround, this approach is pretty unmaintainable, I
hope we'll get a CSS property for spacing directly on the parent
container (a toolbar in this particular case).
See https://bugzilla.gnome.org/show_bug.cgi?id=762397
If a window is not resizable (with gtk_window_set_resizable ()),
the size given with gtk_window_set_default_size() is ignored.
The solution to this would be to use gtk_widget_set_size_request() but
that's a GtkWidget API and therefore does not take into account the
client side decorations when in use with GtkWindow.
Refactor the code so that gtk_window_set_default_size() (which is a
GtkWindow API) gives the expected result on non-resizable windows as
well.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762974
Will make GTK+ more willing to use CSD for all normal windows without
being asked to. Lack of desktop composition will, of course, prevent
it from using CSD (in theory).
GTK_CSD=0 will force CSD to NOT to be used whenever
possible (i.e. in cases where CSD is not specifically requested
by a window, by design).
https://bugzilla.gnome.org/show_bug.cgi?id=759899
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
When a gtk_widget_queue_allocate() on some widget increases the clip,
widget->parent's clip was not updated. This appraoch naively just
unions widget's new clip with widget->parent's clip.
This of course only works if widget and parent share the same GDK
window. In the cases where they don't we can't do anything and need a
better fix.
Fixes label-text-shadow-changes-modify-clip.ui reftest.
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
key repeat is handled client side, which means stalls in the compositor
dispatching key release events can lead to fictious repeat events.
This commit ties key repeat to a server roundtrip to ensure the client
and server are in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
We don't need the key repeat rate or anything like that when
handling key up events, so do key up events first before querying
for that information.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
deliver_key_event is sometimes called from a timeout handler and
sometimes called directly. We currently erroneously return TRUE
(G_SOURCE_CONTINUE) in the case where it's called directly, but to
no ill effect, since we ignore that return value. In the future,
we're going to need to call it directly in other parts of the code
where the return value would be relevant and handling TRUE, would
require adding redundant code.
Instead, this commit just changes the code to always reset the timer
manually, and never rely on glib's ability to automatically reset
the timer by returning TRUE. This makes the code smaller, too, since
there's less special casing required.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
The check is not working for many containers anymore as they are not the
direct parents of their children. We want to allow this behavior in more
places.
We are actually not using the crypt() in GDK-Broadway for quite a while,
so the code implementation for MSVC is actually not used. So, it's time
to get rid of this.
Search also for the headers in include/gio-win32-2.0, as gio.h will
include those headers at some point, and arrange the include paths in a
dependency hierarchy style, top-to-down.
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
We create and destroy gadgets inside the levelbar hierarchy here,
and if we don't explicitly remove their CSS nodes from the parent,
they stick around.
