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
shell_global_get_memory_info() is a new function which extracts a few
global counters we have already, namely glibc's mallinfo, spidermonkey's
JSGC_BYTES, and gjs' counters for boxed/object/etc wrappers.
There is some slight overlap with perf; ultimately though I'd
like this function to do some more extensive analysis, so it wouldn't
be quite the same.
perf is going to be mainly concerned with how big the whole process
over time is; memory_info is for debugging memory leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=650692
A new envrionment variable GNOME_SHELL_ENABLE_CLEANUP is added which
causes us to attempt freeing global data. The reason this isn't
enabled by default is that it's a waste of time at best, and at
worst in corner cases could cause crashes which would fill up
crash databases. Better to leave it as a developer-only tool.
Start stubbing out some cleanup in ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=649517
shell-global had become a dumping ground for functions that didn't
have anywhere else to be. Make shell-util the dumping ground instead,
and have shell-global only have methods that involve the ShellGlobal
object.
https://bugzilla.gnome.org/show_bug.cgi?id=648755
