Commit 6c2f3d1d17 moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.
Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
https://bugzilla.gnome.org/show_bug.cgi?id=695487
Rework the way we re-exec the shell on OpenBSD so that it does not only
work the first time it is re-exec'd.
Plug a small leak in the __linux__ case while here.
https://bugzilla.gnome.org/show_bug.cgi?id=727763
It can be useful to augment the shell's search path by doing
GNOME_SHELL_JS=resource:///org/gnome/shell:<mypath>
But this doesn't work because resource: is split off. Special
case path elements that are just 'resource' and recombine
them with the next element.
https://bugzilla.gnome.org/show_bug.cgi?id=730409
Currently we update the scale factor on startup and when we get a
monitors-changed signal, which is not the only cases where the setting changes. We cannot listen for gdk-window-scaling-factor changes because it is not
exported to gdk.
So use gtk-xft-dpi which also indicates a scale factor change.
When someone changes gtk-xft-dpi directly without changing the scale factor
we will just re-read the gdk-window-scaling-factor so no harm is done.
https://bugzilla.gnome.org/show_bug.cgi?id=726238
clutter_device_manager_get_core_device calls XIGetClientPointer, which
requires a round-trip to the server. Since we do this on StWidget
creation, this means a full round-trip for every created StWidget.
Replace this with get_device with the ID of the VCP/VCK, since mutter
doesn't support MPX, and we know this is what the device is.
If gdk_screen_get_setting fails, like if it's running without XSettings,
then the GValue will have a value of 0. A lot of code tries to divide by
the scale factor. This produces NaN, and combined with the fact that NaN
is "leaky", we very quickly end up spinning out of control.
In cases where we have an array of 0 elements or similar, the
data returned may be NULL. Since g_file_replace_contents will
assert in this case, simply check for this and delete the file
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Gdk uses Xwayland, so it only sees the events we forward to X11
clients. Instead, we can use the abstraction API provided by
mutter and get the right value automatically.
Also, we need to use MetaCursorTracker to handle the cursor
visibility too.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
We need to call into MetaScreen to set the cursor, but we can't
do that from libst, so add a hook that libgnome-shell can fill,
and remove more ClutterX11 usage.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
When running as a wayland compositor, the clutter stage doesn't
have an usable window for IPC, so just create another one.
Also, disable freezing the keyboard when running on wayland, as
we can't do it really.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
The duality of the Clutter's key focus and mutter's window focus has long been
a problem for us in lots of case, and caused us to create large and complicated
hacks to get around the issue, including GrabHelper's focus grab model.
Instead of doing this, tie basic focus management into the core of gnome-shell,
instead of requiring complex "application-level" management to get it done
right.
Do this by making sure that only one of an actor or window can be focused at
the same time, and apply the appropriate logic to drop one or the other,
reactively.
Modals are considered a special case, as we grab all keyboard events, but at
the X level, the client window still has focus. Make sure to not do any input
synchronization when we have a modal.
At the same time, remove the FOCUSED input mode, as it's no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Currently we simply set the gsettings key when activating an input
source. This obviously introduces a time window, between the event that
activates the switch and when the switch is complete, under which key
events are being delivered to applications and interpreted according
to the previous input source.
The patches in bug 696996 introduce a DBus API in g-s-d that allows us
to know when an input source if effectively active. Using that and
freezing keyboard events in the X server until we hear back from g-s-d
we can ensure that events won't be misinterpreted after an input
source switch.
https://bugzilla.gnome.org/show_bug.cgi?id=697007
Doing so causes useless full stage redraws and breaks culling
as clutter cannot know how the signal handler affects painting.
So use clutter_threads_add_repaint_func_full instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694988
This commit updates the code to use mutter's new background
api, and changes the shell's startup animation to be closer
to the mockups.
Based on initial work by Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=682429
The notifications spec has two hints for playing a sound, sound-file
and sound-name. We can support them using the existing code that
wraps libcanberra.
https://bugzilla.gnome.org/show_bug.cgi?id=642831
As pressure barriers need a signalling mechanism to provide
information about when and where they are hit, an object which
provides a signal is a more appropriate abstraction for a pointer
barrier than a functional ID-based approach. Mutter has gained
pointer barrier wrappers, so use its objects instead of ours.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
While looking at how the plymouth implementation was built, I was so
short-sighted and focused on the string "_XROOTPMAP_ID" that I didn't
realize it was the name of the standard background on the root window.
Remove our own implementation, and switch to using a standard mutter
MetaBackgroundActor.
https://bugzilla.gnome.org/show_bug.cgi?id=682428
The supposed reason for launching the calendar server in a peculiar
way was so that the process would be killed when the Shell was killed,
but that didn't actually work. Launch the calendar server through auto-start,
and persist all throughout the session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
This currently causes the shell to freeze very often in a thread
deadlock, and the gjs garbage collector behavior is currently getting
fixed at the right level in gjs itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679832
Instead of falling back to a set of default values or crashing the
window manager when an invalid mode is specified, check the value
of the ShellGlobal:session-mode property before taking over as WM
and make a clean exit if it cannot be resolved to an existent mode.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Add a session-mode property on ShellGlobal which corresponds to the
new --mode switch. Make the existing ShellGlobal:session-type property
readonly and base it on ShellGlobal:session-mode to avoid conflicts.
https://bugzilla.gnome.org/show_bug.cgi?id=676156
Recent mutter changes made MetaShapedTexture not a ClutterTexture,
but instead a special ClutterActor subclass that implemented the texture-y
bits itself. Use recently introduced API in MetaShapedTexture so that we can
get the raw texture data and spit it out as a PNG.
Use the new meta_shaped_texture_get_image() to get a window's texture data.
meta_shaped_texture_get_image() flattens the image against any mask it may
have, so a screenshot of it should look exactly as it does on the display.
https://bugzilla.gnome.org/show_bug.cgi?id=662486
For the Intel drivers, using glReadPixels() to read into client-memory
directly from the frame buffer is much slower than creating a pixel
buffer, copying into that, and then mapping that for reading. On other
drivers, the two approaches are likely to be similar in speed. Create
a ShellScreenGrabber abstraction that uses pixel buffers if available.
Use that for screenshots and screen recording.
https://bugzilla.gnome.org/show_bug.cgi?id=669065
Use the correct clip offsets when taking the screenshot of a window, to
exclude possible invisible borders and to include the case where the
window doesn't have any frame itself.
Writting the screenshot to a file can take a relativly long time
in which we block the compositor, so do that part in a separate
thread to avoid the hang.
https://bugzilla.gnome.org/show_bug.cgi?id=652952
Allow push_modal to optionally only work with a keyboard only grab and
use that in altTab as a fallback to allow switching windows while a pointer grab
is in effect (like during DND operations).
https://bugzilla.gnome.org/show_bug.cgi?id=660457
shell_global_get_memory_info tries to zero initialize the output
parameter with memset, but it passes the wrong size (because of
a missing *). There's no reason to do the memset, though. In the
normal case all members of the struct gets initialized before the
function returns anyway.
This commit drops the memset call in favor of one explicit 0 assignment
that only gets executed on on atypical platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=662236
While I've been trying to make the GC kick in more often, I've decided
it's a better tradeoff to aggressively GC at "leisure", for multiple
reasons.
We can and should revisit this at a later time, but basically:
* The shell doesn't generate *that* much JS data - garbage collection
is very fast here.
* Long periods without GC mean we're not calling free() when we
could, which in turn makes heap fragmentation much worse.
* Ensuring the GC runs at idle makes it much less likely we'll take
a random large GC hit in the middle of an animation.
https://bugzilla.gnome.org/show_bug.cgi?id=659254
This commit introduces a "session type" for
gnome-shell. It essentially defines what
mode of operation the shell runs in
(normal-in-a-users-session mode, or at-the-login-screen mode).
Note this commit only lays the groundwork. Actually
looking at the key and appropriately differentiating
the UI will happen in subsequent commits.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
shell_global_get() currently implicitly instantiates the shell
global singleton the first time it's called. This means there's
no opportunity to set construction-time properties on the singleton.
This isn't an issue yet, because there aren't any. We will need it
in the future, though, when we grow a --gdm-mode that gets exposed as
a property through the global singleton.
This commit adds a new _shell_global_init() function that must be
invoked before shell_global_get() can be called.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Adds methods to shell_global to allow taking screenshots
save the result into a specified png image.
It exposes three methods via shellDBus applications like
gnome-screenshot:
*) Screenshot (screenshots the whole screen)
*) ScreenshotWindow (screenshots the focused window)
*) ScreenshotArea (screenshots a specific area)
https://bugzilla.gnome.org/show_bug.cgi?id=652952
MetaPlugin wraps a bunch of compositor (and plain metacity) methods
that we can just call ourselves, so just do that. (Presumably this
dates back to some ancient time when it was imagined that plugins
wouldn't need access to the full metacity API.)
https://bugzilla.gnome.org/show_bug.cgi?id=654639
Rather than constantly asking mutter for the MetaScreen, and then
figuring out the MetaDisplay/Display/etc from there, just keep track
of everything we care about inside ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=654639
Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=636963
