Specifying the session mode on the command-line doesn't play
well with session management (since the saved session desktop
file well either drop the specified session mode, or force it
always, even if the user picked a different mode at the login
screen)
This commit adds support for specifying the session mode via an
enviroment variable. For now, keep the old command line interface
for backward compatibility
https://bugzilla.gnome.org/show_bug.cgi?id=720894
All get_app_from_*() helpers are transfer full, but
get_app_from_gapplication_id() was directly returning the result
of lookup_app(), which is transfer none.
https://bugzilla.gnome.org/show_bug.cgi?id=721439
The hash table must keep a copy of the IDs, because the GAppInfos
are unreferenced (and thus freed) at the end of the function.
This was possibly not a problem if the GAppInfos were referencing
the memory-mapped cache, but it becomes one for regularly parsed
desktop files in ~/.local.
https://bugzilla.gnome.org/show_bug.cgi?id=721039
get_secrets_keyring_cb() contained an optimization (copied over from
nm-applet) that avoided a D-Bus round-trip when NetworkManager sent
secrets hints that were not satisified by the user. This code did
not properly handle empty hints though, and proceeded to always
request new secrets whenever empty hints were sent. Remove this
code entirely since the complexity is not worth it (per Jasper).
Second, get_secrets_keyring_cb() was mishandling VPN secrets which
were marked as "always ask". Because the VPN secrets are not GObject
properties because they cannot be pre-defined, they are passed in
a hash table that is a GObject property marked 'secret'. Unfortunately,
that means that the shell agent cannot determine their secret flags.
But since the VPN plugin auth dialogs have much better information
about what's required than the shell agent does, always ask the VPN
auth dialogs to handle the secrets requests after grabbing any that
already exist from the keyring. This is also what nm-applet does.
https://bugzilla.gnome.org/show_bug.cgi?id=719815
Filtering out "non-interesting" windows beforehand as we currently do
means that we may get properties that should be based on all windows,
like the last time the application was used, wrong.
Just track all windows and filter out non-interesting windows manually
in the one place we actually care about the difference.
https://bugzilla.gnome.org/show_bug.cgi?id=719824
Sorting actors by the distance in the axis of movement first and against
the axis otherwise means that if we have a situation like:
A F
B
where "F" is the focused actor, and it slightly overlaps with B vertically,
then we'll choose "B" to go left, rather than "A", which is most likely
what the user intended.
This is especially apparent in the overview where slight window size
differences mean we might not get an exact grid shape.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
Rather than scanning all apps for searching, use Ryan's new desktop
file index and the glib support APIs for app searching instead of our
own system.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
While unfortunate that we still have to scan all apps with get_all(),
support for this feature will be short-lived, so hopefully we can drop
it in the future as new apps adapt to the desktop file / app ID
recommendations.
For now, simply scan all desktop IDs.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
Systemd-for-the-user-session would also do this, but that's a deeply
invasive change that I may not actually get to this cycle. This
change is tiny and non-invasive, but provides an important benefit:
You can actually reliably tell *which* applications are logging which
messages (assuming they're launched by the shell).
This actually complements a recent change in DBus:
See https://bugs.freedesktop.org/show_bug.cgi?id=68559
which does a similar thing for bus activated apps.
https://bugzilla.gnome.org/show_bug.cgi?id=711626
Rather than create all ShellApps up-front, create them lazily. We really
had no reason to do this before as we were scanning GMenu to get all the
apps, but doing this can remove a need for get_all, which is slow and
memory-hungry.
We want to transition to a system in the future where we have a desktop
file cache. As we no longer differentiate categories or similar, it no
longer makes sense to have app visibility based on categories. Thus,
we no longer need to use gnome-menus to list all apps. The potential
issue here is reloading all desktop files when new files are created,
but this can be dealt with individually.
The "All Applications" view still uses gnome-menus.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
Since appDisplay.js makes its own GMenu tree, it's not necessary
anymore. This does mean that searches will show apps in NoDisplay
categories, but that's an obscure enough edge case not to matter.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
This does remove support for legacy prefixed app infos with
subdirs, but since we want to remove support for the menu spec,
let's not even bother.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
It's a broken method when it comes to giving us a useful GDesktopAppInfo,
and it's hard to fix libgmenu properly, so simply recreate the app info
using the desktop file ID that libgmenu has.
We want to move away from gnome-menus eventually, so the simple
utility method isn't really worth keeping around. Reimplement it
in the one place that uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
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
gcr/gnome-keyring don't handle the case where prompt_password_async()/
prompt_confirm_async() return their result from within the function
very well (or rather: break badly). Calling gcr_prompt_close() instead
is safe, but to avoid these kind of errors in the future, modify
shell_keyring_prompt_cancel() to work as expected in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=708187
Commit 4095a58eb9 introduced a
regression, since we have to take into account four cases,
top, bottom, right, and left, and that can't be merged into
two like that commit did.
So fix it to make fade effect works again.
https://bugzilla.gnome.org/show_bug.cgi?id=708256
The vvalue and hvalue uniforms are only used to decide whether we
should do fade the edges or not based on the fade_edges uniform.
The result does not change accross fragments so there is no reason
to recompute it for every fragment (pixel) so just split the edge
fade into two uniforms and compute the "should we fade the edges"
boolean once for every direction (when setting the uniforms) instead
of for every single fragment twice.
This reduces the number of uniforms as well as the the number of instructions
which are limited on older hardware. It should also be more efficent.
https://bugzilla.gnome.org/show_bug.cgi?id=708007
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
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
The Mutter plugin manager has now been changed so that it itself will
pass on the events through Clutter so there is no need to do this in
Gnome Shell anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=707467
shell_app_compare() (which is only used as sort function for
shell_app_system_get_running() nowadays) currently takes the
visibility of an app's windows into account, e.g. applications
with visible windows (non-minimized windows on current workspace)
sort earlier than applications without.
This translate traditional window-switcher behavior to applications,
but we stopped sorting by workspace in the app-switcher a while ago,
and with the new auto-minimization behavior of fullscreen windows
it is more confusing than helpful - in fact, since mutter commit
7e61ef09369a we no longer do this for the window list, so it
makes sense to apply the same to application sorting.
https://bugzilla.gnome.org/show_bug.cgi?id=707663
In specific cases, GTK+ does not have enough information to set a correct
opaque region, in which the recommended fix is to set your window as
app-paintable. In the tray icon case, the socket window was considered
opaque but GTK+ as it had a solid window background, but it cannot have an
opaque region set, as the plug isn't composited against the socket, but
instead punches through the socket window.
https://bugzilla.gnome.org/show_bug.cgi?id=707614
Using the same idea that shell-generic-container. It implements
AtkValue with a dummy implementation based on signals. Javascript
code would connect to that and returns the proper value.
https://bugzilla.gnome.org/show_bug.cgi?id=648623
In the common case, the accessible object is created by the
own widget. In some cases it is needed to specify a custom
accessible, as some of the logic will be implemented on the
javascript code (extend functionality using Components vs Hierarchy).
https://bugzilla.gnome.org/show_bug.cgi?id=648623
Build gnome-shell for x11, and gnome-shell-wayland for wayland
(as well as the associated libgnome-shell and libgnome-shell-wayland).
The first one links to libmutter, the second to libmutter-wayland.
libgnome-shell and libgnome-shell-wayland are now compiled from
libgnome-shell-base (with all sources that are independent of mutter),
libgnome-shell-menu (with the copy-pasted gtk sources), plus the
sources that use mutter API
https://bugzilla.gnome.org/show_bug.cgi?id=705497
It's mostly equivalent to "jhbuild run gnome-shell", which is
the preferred way. Also, running from the source tree can't be
supported at this point, and the wrapper is getting in the way
of having two binaries, one for wayland and one for X11.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
The MetaWindowActor isn't painted, and we empty its input shape in
the X scene graph, but Clutter still picked it. Set it as unreactive
so that it can't be picked.
https://bugzilla.gnome.org/show_bug.cgi?id=706536
Ever since we stopped reparenting status icon windows to the stage, tray icons
haven't been inferiors and thus we don't have to filter out enter/leave events
for them, as we never show them outside of a modal.
https://bugzilla.gnome.org/show_bug.cgi?id=706536
Unfortunately, display configuration can and does fail, due
to unspecified HW constraints, drivers bugs, unsupported exotic
configurations or just bad luck.
So when the user makes a change in the control center, show
a dialog asking him if it looks OK, and revert back after 20 seconds
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=706208
With StBoxLayout using the Clutter layout manager, it will now respect
actors' expand/align properties. However for the change to be transparent,
we need to support the existing child meta properties as well. Do
this by simply translating them to the corresponding ClutterBoxChild
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=703810
With the BoxLayout containers in St and Mx and the ClutterBoxLayout
manager, we now have three more or less diverged implementations of
the same layout policy.
While removing StBoxLayout entirely in favor of ClutterLayoutManager
would be the fashionable thing to do, there are obvious drawbacks:
- it is the only actor we have that implements the scrollable interface
- it conveniently exposes its spacing property in CSS
- last but not least, it is used all over the place
So do the next best thing and make our implementation use the
Clutter layout manager internally - that way, the change is
transparent to users, while we get to refer most of the tricky
bits to Clutter. win-win!
https://bugzilla.gnome.org/show_bug.cgi?id=703810
Replace more direct XFixes usage with a the appropriate abstraction
API from mutter, which is guaranteed to work in wayland too.
It doesn't yet replace pointer position tracking, although probably
it should.
Also, because now we're using Mutter API, we lose the standalone
test case.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Mutter now includes an object with the same purpose and functionality
as ShellXFixesCursor, so we can replace our XFixes code with it
and work under wayland too.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
In the new application model, there is one ID shared by GApplication,
DBus and .desktop files, so we can use that for the association,
instead of fiddling with badly cased wm classes.
https://bugzilla.gnome.org/show_bug.cgi?id=706252
This is needed to handle applications that are converted to
reverse dns notation, if their application ID includes capital
letters (as it is often the case for DBus names)
https://bugzilla.gnome.org/show_bug.cgi?id=706252
This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
Commit cfecd063c9 changed the allocation logic to not allocate
scrollbars when the *_visible booleans are false. This breaks the
fade effect as well as the NEVER policy. We do not paint scrollbars
when they are not supposed to be visible, so not allocating them
and thus leaving them in a "needs allocation" state just causes problems.
I am not convinced that it solved any problem to begin with (we don't paint
them anyway).
As the previous condition has basically always been true, just do it
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=705664
Chromium (but not google-chrome) has a StartupWMClass in the desktop
file, so we must match the instance part first to have chrome
web apps working.
Also, we must take care of apps without a wm_class or instance at
all.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
Some applications (such as most Java apps, as well as Chrome Web apps) ship
with desktop files that have the wrong name, but whose StartupWMClass
field contains the right value. Therefore first check that key, against
both the class and instance part of WM_CLASS, and only use the filename
if nothing else works.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
The point of fading the icon is to make the text displayed over the
icon more legible. In RTL layouts, the text is displayed on the left
of the icon, so fading the right-hand-side of the icon doesn't work
well.
https://bugzilla.gnome.org/show_bug.cgi?id=704583
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
When the St theme is changed, the StThemeContext unrefs all the theme
nodes cached in it's internal hash table, then emits a signal to
notify all theme nodes that the current theme has changed.
The problem is that the first StWidget to catch a theme changed signal
will trigger a "style-changed" signal catched by its children first.
So the theme changed signal can't be processed properly to cleanup
StThemeNodePaintState before recomputing the theme.
This patch adds a weak ref to the StThemeNode in the
StThemeNodePaintState to ensure paint states are properly cleaned up
when the associated StThemeNode is freed.
https://bugzilla.gnome.org/show_bug.cgi?id=703859
Commit 318283fc70 optimized box-shadow rendering by not recreating
shadow materials on every allocation change. Other handles cannot
be reused and are updated regularly, however the patch missed the
cached corner materials - while those can be reused, we still need
to ensure that the currently used paint state references them.
https://bugzilla.gnome.org/show_bug.cgi?id=703909
It is the job of layout containers to arrange their children; having
a hidden feature that *also* allows children to be positioned freely
outside the parent's allocation is just odd.
With the last user of the feature gone, kill it.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently the box-shadow is rendering is done like this :
The first time we want to render a node that requires a box-shadow, St
creates an cogl offscreen surface of the size of the allocation and
renders the box into this offscreen buffer using modulation on the
alpha channel, this buffer is then blurred according to the CSS
parameters.
The problem with this method is that every time an StWidget is
resized, its box-shadow offscreen buffer has to be resized and
therefore rendered and blurred.
This patches propose an optimization for this use case by rendering
the box-shadow only once but at a size that is independent of the
StWidget's size. Then every time we need to paint this box-shadow, we
just render this offscreen buffer using a 9-slices.
This method only works when the allocation of the widget is bigger
than the minimum shadow size on which we can apply a 9-slices, that is
given my the radius of the corners. If the allocation is smaller than
this minimum size, we then fallback to the fully render/blur the
shadow (like before this patch).
https://bugzilla.gnome.org/show_bug.cgi?id=689858
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
This causes a debug SpiderMonkey build to fail when it throws an
exception for the missing symbol, but doesn't properly return FALSE
when executing the script.
https://bugzilla.gnome.org/show_bug.cgi?id=703442
While it is obviously still an error to call get_theme_node() on a
widget that hasn't been added to the stage hierarchy yet, asserting
on it hasn't proven too successful in avoiding those errors - it's
likely the most frequent reason for crash reports. Just accept that
there'll always be code paths where we can hit this case and make
it non-fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
We will allow to use mode-specific overrides; in preparation for that,
move the code so that we only override preferences after initializing
the session mode.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
Otherwise they break the "top level window" detection used by the
unredirect code in mutter, causes game windows not to be unredirected
when tray icons are present.
https://bugzilla.gnome.org/show_bug.cgi?id=701224
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
As with the screen recorder, the magnifier already adds its own
copy of the system cursor, so we should not add it again. Just
as in the screen recorder case, we don't address the case where
the cursor should not be included in the screenshot, but the
magnifier adds it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=700488
The magnifier adds its own copy of the system cursor to apply the
expected transformations, so we don't need to add it again in the
recorder; this avoids two different cursors showing up in recordings,
but doesn't address the case where the cursor should not be recorded
at all, but the magnifier adds it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=700488
It looks a bit unpolished to overlap our own chrome with the recording
icon, which may happen when an existing adds UI at the bottom edge.
Fix this by using the primary monitor's workarea for the position rather
than the entire monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=700409
Attaching gdb and running with G_DEBUG=fatal-warnings is not a very
fast to debug a specific issue (especially if you have warnings at
startup, since then you need to run the shell from a terminal).
Instead, introduce a new SHELL_DEBUG environment variable that can
be set to backtrace-warning, causing a gjs_dumpstack() after every
warning or critical.
https://bugzilla.gnome.org/show_bug.cgi?id=700262
Wrap new GtkMenuTracker API that adds an easy way to bind to
tracker items, and use it to add back support for submenus.
This also adds support for a submenu feature that we didn't
have support for before, action namespaces.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This pulls in new upstream API that Ryan will maintain, removing
code on our side.
Currently, our implementation of submenus will be gone, but this
will be fixed in a few commits.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
We'll need some of these pieces to be introspectable when we port to
GtkMenuTrackerItem. Due to technical limitations in introspection, we
can't put Gtk-prefixed items in the shell namespace, so add them to
a new introspection library instead.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This is a hack we have in our local fork as compared to upstream;
work on a generic "hook" system in here is ongoing, but until then,
this is the easiest way to do it.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
This includes a rename from the G* namespace to the Gtk* one, which
will help us with introspecting this code. Note that this removes
some of the custom code we added to GActionMuxer to relay event times
to the remote action group. We'll add this back soon.
https://bugzilla.gnome.org/show_bug.cgi?id=700257
Currently we will always record the entire screen. It has been requested
to support recording a specified area analogous to the screenshot API as
well, so add a set_area() method which allows this.
https://bugzilla.gnome.org/show_bug.cgi?id=696247
It is currently not always possible to predict the actual output filename
of a recording - the file-template does not necessarily use an absolute
path and may contain %d and %t escape sequences.
This is OK for fire-and-forget uses like the existing keyboard shortcut,
but we will soon expose the functionality on DBus and consumers of that
API might very well need to access the file after the recording. So do
the same as our screenshot API and add an optional (out) parameter to
record().
https://bugzilla.gnome.org/show_bug.cgi?id=696247
Some callers of the keyring prompt keep the dialog up while
processing the prompt. Allow the user to cancel the prompt
while in this state.
This is propagated to the caller, who can cancel the operation
in question when this occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=682830
The shadows are currently rendered by painting the actor we want to
apply shadow on, in an offscreen buffer. The problem is that when this
actor has an allocation padding (ie allocation that isn't at 0x0
relatively to its parent), this padding is added within the offscreen
buffer and as a result the shadow rendering is truncated because the
offscreen buffer size is the size of the allocation box, not the
allocation box + padding.
This patch reposition the actor at 0x0 with rendering it by changing
the initial transformation matrix when rendering the actor offscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=698301
This makes it much easier to implement correct popup-menu behavior
in the case of nested bins.
This fixes the context menu key in application search results when a
result has focus.
https://bugzilla.gnome.org/show_bug.cgi?id=699800
The comment clearly intended that for this to be the case, but a typo
prevented this from actually being done. This fixes the focused state
of the search field not working more than once.
https://bugzilla.gnome.org/show_bug.cgi?id=699799
In most cases, we'll transition between two states on hover / focus.
Instead of recalculating and repainting our resources on state change,
simply cache the last state when we transition.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
The background image, background image shadow and border image are
allocation-indepedent, so we can keep these in the node. Given that these are
are likely cached in the StTextureCache, the slight increase in code complexity
may not be worth caching these textures and materials -- we might be better off
just computing when we need to paint.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
This ensures that two widgets sharing the same theme node won't trample
on each other's prerendered materials if the actors are of different
sizes. This also tries to be very careful to share as much as possible
during a transition.
This has the side effect that if a widget changes state a bunch of times,
we won't cache every state. Since we expect that state changes are
infrequent and that most cases we'll be able to use the texture cache
to do most of the heavy lifting, this cost is much more insignificant
than rendering a number of different actors with the same theme node
and different sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
Since we now share theme nodes between, we shouldn't cache the paint state
across all nodes. As a first step towards putting this in the actor, split
out the state into another structure. Keep it in the theme node for now
so that we don't make too many changes in one commit.
It's possible that some of these pieces of drawing state could be shared
between theme nodes. For the sake of simplicity, assume that none of them
are shared or should be shared. A future commit could identify those that
could be shared and move them back into the theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
We want to put the paint state in the actor rather than in the theme
node, as having two actors with different sizes but the same theme node
is now much less efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=697274
This simplifies the code required to build remote menus and
put all the items in the right place, and makes us share our
implementation with GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=698427
Similar to the existing generic getter methods, add lookup functions
for URL properties like the standard background-image/border-image
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=693688
The changes from commit b4f5f1e461 and b394d184cc increased the
instructions required for the fade fragment shader. This is over the limit
for some hardware (like intel gen3), which causes the driver to fallback
to software rendering for the shader. The result is that painting a scrollview
that has a fade effect takes around 30 (!!) seconds.
So lets go back to the old effect for 3.8 until we find a solution.
https://bugzilla.gnome.org/show_bug.cgi?id=696404
Previously when a client requests that a window should be docked the
shell would reparent the socket window onto the stage's window and
then use ClutterX11TexturePixmap to get a texture to represent the
window. This will not work if Clutter is no longer using the X11
winsys for example if it becomes its own display server. Instead this
patch leaves the socket window as a child of the root window and lets
mutter create a MetaWindow out of it. If Mutter is acting as a display
server then this mechanism will still work via the headless x server.
The ShellGtkEmbed instance now registers for notification of the
‘window-created’ signal of the display so that it can find the
MetaWindow that gets created to represent the socket window. When this
window is found it is prevented from being displayed on the screen by
setting the actor's opacity to 0. An input shape is then set on the
window to prevent it receiving any input.
Instead of being a subclass of ClutterX11TexturePixmap, ShellGtkEmbed
is now a subclass of ClutterClone. When the MetaWindow is found for
the socket window the clone's source is set to the invisible actor for
the window so it can be displayed in the panel as before.
The ShellEmbeddedWindow no longer needs to know what the stage is
because it no longer reparents the socket window. Therefore the
ShellTrayManager doesn't need to know the stage either so
shell_tray_manager_manage_stage has been replaced with just
shell_tray_manager_manage_screen.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
Pointer tracking is broken when the pointer is over the stage input
area. This is apparently fallout from mutter going to XInput2.
This commit changes the mouse event handling code to also use XInput2.
https://bugzilla.gnome.org/show_bug.cgi?id=695324
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the cut/copy actions for
password entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
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
Since commit b4f5f1e461, the effect is eased in at the scroll
view's edges so that it does not appear out of nowhere. However,
the linear easing used is not the best option, as now the effect
appears so late that content near the edges ends up just being
cut off rather than faded out.
So adjust the easing function to have the effect appear faster.
https://bugzilla.gnome.org/show_bug.cgi?id=694327
g_str_has_prefix() will assert when passed NULL, so we need to make
sure that we are passed a non-NULL log_domain first.
Spotted by <goughost<at>yahoo.com.cn>
https://bugzilla.gnome.org/show_bug.cgi?id=663601
If enabled, scrollbars take away from the allocation given to the
view's content. This is usually preferrable to painting the bars on
top of the content, but there are exceptions, for instance when the
content needs to be centered with regard to the view as a whole.
Add a :overlay-scrollbars property to account for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
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
We cannot reset the cursor at the next leave event, as that might
happen on a NULL stage and cause a BadWindow error, so do it on
unmap (which is guaranteed to happen before the stage is cleared).
https://bugzilla.gnome.org/show_bug.cgi?id=694057
As we use g_slist_prepend for efficiency when building the list
of results before ordering it, we need to make sure we traverse
the list of previous results backwards so that it's built in
the same order.
https://bugzilla.gnome.org/show_bug.cgi?id=693936
GdkPixbuf is stored in memory as individual bytes, in strict red-green-blue-alpha
order, while cairo image surfaces are stored as 32bits units whose
order depends on the endianess.
It is probably possible to do something better, taking advantage
of cogl and the GL using the actual component order, but for now
it is easier to use the GDK utility to convert the cairo surface.
https://bugzilla.gnome.org/show_bug.cgi?id=693931
While we were relying on gtk_icon_info_load_icon and friends being
thread-safe, there was no such guarantee, and recent caching that
was added to GTK+ made it non-threadsafe. To replace it, _async()
variants of the icon loading code were added that are thread-safe.
Use those instead of using our own worker threads.
https://bugzilla.gnome.org/show_bug.cgi?id=692845
Use GdkPixbuf rather then cairo_surface_write_to_png_stream when saving
screenshots because this allows us to embedded metadata into the file which
is used by the background control panel to filter out screenshots.
https://bugzilla.gnome.org/show_bug.cgi?id=693737
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
We have to mark the cairo_surface dirty after modifying the data behind
cairo's back.
Also use CAIRO_FORMAT_ARGB32 rather then CAIRO_FORMAT_RGB24 for the
surface to be consistent with the rest of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=691715
Instead of using Clutter to add an event filter for X events it now
uses the GDK API. The Clutter API won't work if Clutter is not using
an X11-based backend such as if Mutter is directly running with the
KMS backend. This is a step towards making Mutter be its own display
server and a step towards being a Wayland compositor. In this case GDK
will still be using the X backend because it will connect to the
headless X server.
https://bugzilla.gnome.org/show_bug.cgi?id=693438
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
Before version 1.2 of GLSL it would not implicitly convert from int to
float which meant that if you compare a float variable with an integer
constant it will generate a compile error. In particular this means
that on GLES2 (which uses GLSL 1.0) the scroll view shader will not
compile on pedantic compilers, which includes Mesa. This patch just
changes it to use floating point constants.
https://bugzilla.gnome.org/show_bug.cgi?id=693339
Instead of directly using symbols from GLX to check for the swap event
notification, the plugin now first verifies that the Cogl renderer is
actually using the GLX winsys and then indirectly fetches the pointers
for the GLX functions using cogl_get_proc_address. That way it will
continue to work if Cogl is using an EGL winsys.
Nothing in the Gnome Shell plugin now directly uses symbols from libGL
so we don't need to link to it. This helps to avoid problems linking
against two GL APIs when cogl is using a non-GL driver such as GLES2.
https://bugzilla.gnome.org/show_bug.cgi?id=693225
Cogl sets this for us since commit 2701b93f159bf2d3387cedf2d06fe921ad5641f3.
Setting it twice is illegal and causes compile failures:
error C0204: version directive must be first statement and may not be repeated.
This commit removes all the code in charge of playing with the database of
mobile providers, which was originally included in order to perform
MCCMNC->OperatorName and SID->OperatorName conversions.
This logic is now exposed by libnm-gtk.
https://bugzilla.gnome.org/show_bug.cgi?id=688943
Environment variables should be checked for zero length,
instead of non-zero. This prevented the script to run
correctly in a jhbuild shell for example.
https://bugzilla.gnome.org/show_bug.cgi?id=693031
Clutter translates keyboard state internally, and clears the lock bits
from modifier state, so translating again results in the wrong keysym.
Given that Clutter already gives us a fine keysym, we don't need this.
https://bugzilla.gnome.org/show_bug.cgi?id=692586
As theme nodes keep a cache of matched properties, we need to make
sure to update it when the list of stylesheets changes. In particular
this fixes a regression from commit dc2ec0a8f9, which caused
extensions with stylesheets to crash the shell when re-enabled (for
instances when coming back from the lock screen).
https://bugzilla.gnome.org/show_bug.cgi?id=692994
StThemeNodes cache matched properties from stylesheets, so when the
list of custom stylesheets changes, the node may miss better matches
(when a stylesheet was added) or have pointers to invalid memory in
the list (when a stylesheet was removed).
In order to allow theme nodes to listen for stylesheet changes, add
an appropriate signal to StTheme.
https://bugzilla.gnome.org/show_bug.cgi?id=692994
gnome-control-center is planning on removing its own tree in the
future. Since it already installs these applications into
/usr/share/applications, just use this for now.
https://bugzilla.gnome.org/show_bug.cgi?id=692483
Since we also support passing a basename now, clients might be
interested in knowing the path used to save the file.
Add an out argument to the interface for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
If a non-absolute path is passed to the screenshot methods, treat it as
a basename for the output image, and automatically try to save it in
$XDG_PICTURES_DIR, falling back to $HOME if it doesn't exist.
https://bugzilla.gnome.org/show_bug.cgi?id=688004
According to css3-transition, transition-duration is expressed
as a time, that is, in seconds or milliseconds. Fix that by
recognizing numbers with units and implicitly converting to
milliseconds after parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=681376
The code here before was added as dummy code to satisfy an error
in the missing switch, and wasn't ever tested due to the lack of XI2
in mutter. Use the same math as GtkRange does to calculate scroll bar
positions from raw XI2 deltas to allow for proper smooth scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=687573
realpath() does a series of lstat() on each path component to resolve
symbolic links, but we just want to get an absolute path, and we don't
really care if it is physical or not. Going through a GFile does the
canonicalization we need, and is a lot faster.
https://bugzilla.gnome.org/show_bug.cgi?id=687881
StWidget considers "same theme node" as an indication that the style
did not change, and skips emitting style-changed in that case. This
means that icon theme changes are not picked up by StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=689353
Decorations are fairly uncommon in gnome-shell, so it's
worthwhile to avoid effort creating empty attr lists. This
can also help prevent a relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=689400
Coverity rightly complained about the context < 0 comparison.
In addition, context was shadowing the parameter of the same
name, and the loops over the attributes were unnecessarily
running all the way.
https://bugzilla.gnome.org/show_bug.cgi?id=689325
This was due to incorrect pixel clamping, which bounced the height
of the actor between values. Just remove pixel clamping, as Clutter
will correctly do it for us.
https://bugzilla.gnome.org/show_bug.cgi?id=689243
This doesn't (or shouldn't) change the visual appearance of the fade
effect, but does do all the testing math inside the shader, rather
than on the CPU. This will make fading the offset much easier in
the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689249
GLSL 1.20 is a better language, and we'll rely on it in future updates.
This doesn't have any additional constraints, since GLSL 1.20 was
standardized before GLSL-supporting drivers came out.
https://bugzilla.gnome.org/show_bug.cgi?id=689249
Theme nodes are interned and shared with other widgets, so they cannot
be disposed, otherwise we blow useful resources, and in particular we
break the parent-child chain.
https://bugzilla.gnome.org/show_bug.cgi?id=689029
We where not setting a duration for the frames, which caused the resulting videos to
have a broken header.
Fix that by making the source a live source and setting the correct frame duration.
https://bugzilla.gnome.org/show_bug.cgi?id=688487
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component. Also, there is a race if it is displayed before the images
are loaded: there is no child yet and thus we get this._frame = NaN
which leads to a crash.
Switch to a play/stop API instead, and add a load event callback to the
TextureCache.load_slice_image to exactly know when we can start using
the images.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
We are currently using a hack to allow a select set of keybindings
in the overview. Implement the new MetaPlugin keybinding_filter
hook, which provides a cleaner way to achieve the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
It appears to be somewhat common for st_widget_style_changed() to be
called when no style-relevant attributes have, in fact, changed. Now that
we cache theme nodes, we're likely to get the same theme node back from
the cache. If we do, we don't need to waste time asking whether its
geometry and painting are equal to itself: we can just note that nothing
really changed and get on with our lives.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If you copy a theme node's paint state into itself, it should be an
inexpensive no-op. What actually happened was that we destroyed the
old paint state, re-initialized to blank, then copied the blank state
back into itself. In the process, we lost (for instance) the textures
for rounded corners.
Until I introduced the texture cache, this never actually happened,
because when st_widget_recompute_style() calls st_widget_get_theme_node(),
we'd always get a fresh theme node. Now, we get a theme node T back
from the cache, notice that paint_equal(T, T) is true, short-circuit
slightly by copying its drawing state into itself, and destroy drawing
state that we still needed.
I'm going to fix this in recompute_style() too, but as a general
principle, self-assignment ought to be harmless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Because we calculate and cache CSS properties once per StThemeNode,
and only a certain set of attributes can affect the CSS properties,
it's advantageous for as many widgets as possible to share a single
StThemeNode. Similarly, if a widget changes state and then changes back
(e.g. gaining and losing the :hover pseudo-class), it should ideally
get its original StThemeNode back again when it returns to the old
state.
Here, I'm using the StThemeContext as the location for a cache.
StThemeNodes are currently never freed: this seems OK for Shell's usage
(a finite number of IDs, classes, pseudo-classes and types).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
In my testing this cuts the longest time to dispatch(), when showing the
calendar menu for the first time, from 604 to 442 milliseconds,
while reducing additional_selector_matches_style() from 32% to 13% of
CPU time used.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687465
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
The descriptions for keybindings shared with Metacity are now
duplicated in Mutter, so only use the latter to avoid duplicate
entries in System Settings.
https://bugzilla.gnome.org/show_bug.cgi?id=687672
The screen grabber was a workaround for an extremely slow path in Mesa
when reading back pixel data from the frame buffer. It was using pixel
buffer objects by directly calling into GL to hit a fast blit path in
Intel's driver. This should no longer be necessary with the latest
Mesa because the normal read pixels path now has a fast path to just
memcpy the data. Using PBOs in that case just adds an extra
indirection because the data is read into an intermediate buffer and
then copied back out again.
We want to be able to remove the dependency on linking against libGL
directly from Gnome Shell because that will not work if Cogl is
actually using GLES. Also libGL includes GLX which means gnome-shell
ends up with a hard dependency on Xlib which hinders the goal of
getting Gnome Shell to be a Wayland compositor.
https://bugs.freedesktop.org/show_bug.cgi?id=46631https://bugzilla.gnome.org/show_bug.cgi?id=685915
shell_mobile_providers_parse() was returning the country information split
into a hash table with providers and a hash table with country names. This
patch merges both outputs into a single per-country object, so the parse()
method now returns a GHashTable with the following element-type:
(element-type utf8 ShellCountryMobileProvider>)
This also avoids more complex setups like returning lists inside of hash tables,
which was actually breaking either g-i or gtk-doc.
shell_mobile_providers_parse() was also modified to allow inputting the paths
of the country codes and provider list files to use. If paths are not given, the
default ones will be used. This helps us to provide test files during unit
tests.
Both the findProviderForMCCMNC() and findProviderForSid() methods are exported
out of the GSM and CDMA specific classes, and new unit tests for them are
implemented. Tests can be run manually with:
$> ./tests/run-test.sh tests/unit/mobileProviders.js
https://bugzilla.gnome.org/show_bug.cgi?id=687356.
Rather than using a complicated set of function calls across
library boundaries and our own scanning logic, use strtok(),
which glibc already provides, and is probably much more optimized.
https://bugzilla.gnome.org/show_bug.cgi?id=687465
* Fix wrong parameter name to on_name_appeared callbacks
* optparse doesn't just leave extra command line arguments, it
errors out, so don't try to pass through extra arguments -
instead add explicit passthrough for '--replace'
* Fix usage of Gio.DBusProxy
* Add a default value for --perf so that if it's not supplied
things don't die with a mysterious error message. (This wasn't
needed when --perf enabled perf-mode)
https://bugzilla.gnome.org/show_bug.cgi?id=687287
The libedataserverui dependency is a relic of the old E-D-S API.
As of 3.6.0, E-D-S now centralizes authentication prompts so clients
don't have to display their own. This also allows trading the GTK+
main loop for a plain GMainLoop in gnome-shell-calendar-server.c.
https://bugzilla.gnome.org/show_bug.cgi?id=687189
Often the first thing a user wants to do after making a recording
is post it somewhere.
This commit adds the video to recently used items, so that it shows
up prominently in open file choosers.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
Recording continues for some time after the recorder object
is closed, since closing isn't a synchronous operation.
This commit defers quiting the test-recorder application until
the recording is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
We want to make sure the recorder isn't finalized until the
saved recording hits disk. This means the pipeline object needs
a hard reference on the recorder.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
The stage is a floating object. We don't own a reference
to it, so we shouldn't unref it.
This commit removes the erroneous unref call and makes sure
we call clutter_actor_destroy on the stage when we're done
with it.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
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
Currently we miss changes to a file referenced in background-image
or border-image.
Connect to the StTextureCache::texture-file-changed signal to keep
up with file changes and update the drawing state if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
For textures loaded from files, the cache might hide image changes
by keeping the data of a previous version around indefinitely. For
instance AccountsService will notify of avatar changes, but as new
image is copied over the old one, we will continue to use the old
image data.
Install a file monitor for each file resource we load and clear
the corresponding data from the cache on changes, emitting the
new StTextureCache::texture-file-changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
ClutterText will only queue a relayout after font changes if it has
any contents other than the empty string. As a result, its height
request may change after the first character has been entered. To
avoid this visual glitch, force a relayout on actual font changes.
https://bugzilla.gnome.org/show_bug.cgi?id=685534
The actor's GtkIMContext is freed in dispose and reset in unrealize - as
ClutterActor's dispose will unrealize the actor if necessary, chaining
up to the parent after clearing the im context will result in warnings
if the actor is still realized, so chain up first.
https://bugzilla.gnome.org/show_bug.cgi?id=686016
The application menu is currently unusable with non-maximized
windows when using focus-follows-mouse mode. Override mutter's
focus-change-on-pointer-rest preference, so that the actual
focus change is delayed until the pointer stops moving.
https://bugzilla.gnome.org/show_bug.cgi?id=678169
The signals for the action group were being disconnected when the action
group was explicitly removed from the GActionMuxer but the same was not
being done when it was finalized.
This means that a change in the state of an action group that used to be
associated with a finalized GActionMuxer would result in a crash. This
would happen for stateful application actions after closing a window.
https://bugzilla.gnome.org/show_bug.cgi?id=681399
For performance reasons, resources required to paint a widget are
aggressively cached; we know of at least one case where our caching
prevents updating the used background-image correctly, so add explicit
API to clear all associated cache data.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
StThemeNode caches its resources aggressively to keep the required
work on paint to a minimum - right now, resources are only recreated
on allocation changes.
In order to update the background-image property correctly when the
underlying file changes, resources need to be recreated without a
size change, so add an explicit method for that.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
The current API assumes that image data loaded from files remains
valid during the life time of the shell. This assumption is mostly
valid for image files we provide ourselves (with the exception being
designers working on those files), but not necessarily for "external"
files - provide API to explicitly remove cached data associated with
a URI for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
The screenshield requires gdm 3.5, which can be problematic in
jhbuild configurations, or distributions that don't use GDM as the display
manager. Allow transparent fallback to gnome-screensaver in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
The speed and quality properties have been removed in favor of properties
closer to the upstream library.
Removing the properies from the pipeline would result into a huge
slowdown so we have to map the old values to the new ones.
According to the source code of the old vp8enc element quality maps to
(int)(63 - quality * 6.2) for min_quantizer and max_quantizer, while
speed maps to cpu-used = speed == 0 ? 0 : (speed - 1).
So set min_quantizer and min_quantizer to 13, and cpu-used to 5 based on
the above formulas.
https://bugzilla.gnome.org/show_bug.cgi?id=684206
Remove the PlacesManager, its search provider and all associated code.
Places search is now provided by nautilus using the external search
provider API.
https://bugzilla.gnome.org/show_bug.cgi?id=683506
Rather than unconditionally removing a focus root in remove_group(),
decrement a counter that add_group() increments, and only actually
remove a focus root when the counter drops to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
When using an input method like IBus, the IM is expected to process
key events before anything else. Currently this doesn't always work
as expected, as the event filtering is done in the default handlers
of the key-press and key-release events, e.g. only after other
handlers have been run.
To allow the IM to filter events earlier, move the code to a
captured-event handler instead.
https://bugzilla.gnome.org/show_bug.cgi?id=658325
If an actors is not mapped (visible and all parents visible), then don't
allow navigating focus to it.
This fixes a regression in the keyboard navigation of the panel with
invisibile items.
https://bugzilla.gnome.org/show_bug.cgi?id=683529
st_texture_cache_load_from_raw() enforces a square ClutterTexture,
resulting in the texture being stretched if the passed in image
data has a different width:height ratio.
Add padding in those cases as we already do when loading from pixbufs.
https://bugzilla.gnome.org/show_bug.cgi?id=683483
Clutter will try to unmap during a dispose if we have a parent, so if we
set our own actor to NULL before the chain up, we're going to attempt to
unmap our own NULL actor. Fix that by swapping the order in which we
chain up.
https://bugzilla.gnome.org/show_bug.cgi?id=672790
The default filename isn't localized and isn't the same one that
the shell sets. Just remove the fallback mechanism, and abort
recording if somebody didn't set the filename
https://bugzilla.gnome.org/show_bug.cgi?id=677434
Components are pieces of the shell code that can be added/removed
at runtime, like extension, but are tied more directly to a session
mode. The session polkit agent, the network agent, autorun/automount,
are all components, keyring, recorder and telepathy client are all
now copmonents.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
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
Introduce a StShadowHelper to manage drop shadows from JS (which
cannot use Cogl directly), and use it in a new StWidget-derived
JS class to draw the arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
Reroute setting those properties to a GIcon. API users are expected
to create GIcon directly now.
The advantage is that from a StIcon you can now create a similar one
by accessing :gicon.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.
https://bugzilla.gnome.org/show_bug.cgi?id=670168
If the user is already active when the notification pops up, we
won't get an idle watcher because there's no transition from
active to idle or vice versa. Correct this by initializing the
state correctly from XSync.
StScrollBar was intercepting motion events by using captured-event on
the stage, which required additional dirty tricks, which required
additional hacks. Simplify it by just using clutter_grab_pointer()
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=671001
It doesn't make sense to have multiple ShellIdleMonitors, since
each has its own GDK filter function, but they all get the same
events. In preparation for having it accessed from other places
than the message tray, make it a singleton.
https://bugzilla.gnome.org/show_bug.cgi?id=682041
Add support for the CSS "background-repeat" property. Currently, this
only supports on/off, rather than allowing tiling in each individual
dimension. It is supported for both the cogl and cairo rendering paths.
https://bugzilla.gnome.org/show_bug.cgi?id=680801
gnome-session and gnome-settings-daemon rely on the screensaver
interface to know the locked state. Since gnome-screensaver is no
longer running, it's up to gnome-shell to provide it.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
To allow more than one summary icon actor for a source we split
the model of the source icon (which is iconName, if the default
implementation is used, or a GIcon otherwise) and replace
createNotificationIcon() with a generic createIcon(size). Also,
the actual source actor is split into a separate class, that handles
the notification counter automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
The :reactive property is used on StButton to like the :sensitive
property on GtkWidgets, that is, to indicate that the user is not
(yet) expected to click the button, and therefore should affect
styling too.
This allows to remove some code at the JS layer.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
While modal dialogs were attached to the parent's titlebar, it
made sense to leave the top of the parent window at full color.
With the new position of modal dialogs, it makes more sense to dim
the entire parent window, so we can use a combination of Clutter's
BrightnessContrast- and DesaturateEffect instead of our own custom
shader.
https://bugzilla.gnome.org/show_bug.cgi?id=674499
We used to use realize/unrealize instead of map/unmap in ShellEmbeddedWindow
because there originally was no map/unmap. The days of this are long gone...
https://bugzilla.gnome.org/show_bug.cgi?id=672790
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
