It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Closing a GdkDisplay during an event handler is not currently supported by Gdk
and it will result in a crash when doing e.g. 'mutter --replace'. Using an idle
function will close it safely in a subsequent main loop iteration.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/595
Commit 840378ae68 changed the code to use XmbTextPropertyToTextList()
instead of gdk_text_property_to_utf8_list_for_display(), but didn't
take into account that the replacement returns text in the current
locale's encoding, while any callers (rightfully) expect UTF8.
Fix this by converting the text if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
The WM_NAME property is of type TEXT_PROPERTY, which is supposed to be
returned as UTF-8. Commit 840378ae68 broke that assumption, resulting
in crashes with non-UTF8 locales; however the "fix" of converting from
LATIN1 to UTF8 is wrong as well, as the conversion will spit out garbage
when the input encoding isn't actually LATIN1.
Now that the original issue in text_property_to_utf8() has been fixed,
we can simply revert the relevant bits of commit d62491f46e.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.
In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.
Closes: #273
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
XcursorLibraryLoadCursor can return 'None' if the current cursor theme
is missing the requested icon. If XFreeCursor is then called on this
cursor, it generates a BadCursor error causing gnome-shell to crash.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/254
Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.
If we wait with opening the X11 window decoration GDK connection, we
might end up with a terminated X11 server before we finish
initializing, depending on the things happening after spawning Xwayland
and before opening the MetaX11Dispaly. In gnome-shell, this involves
e.g. creating a couple of temporary X11 connections, and on disconnect,
if they happen to be the last client, the X server will terminate
itself.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
