Removing the prerequisites from the gschemas.compiled rule broke
the build, as this is what triggers the generation of the actual
schema files expected by the rule's command.
Instead of just restoring the former dependencies, make sure that
the schema is validated before compilation, not after.
https://bugzilla.gnome.org/show_bug.cgi?id=622050
Use GSettings for all Shell configuration. GConf is kept to read
configuration from external programs (Metacity, Nautilus and Magnifier),
but ShellGConf is removed because it's mostly useless for the few calls
we still have. Also get rid of unused GConf code in ShellAppSystem.
A basic GConf schema is still used to override Metacity defaults and
configure Magnifier in a system-wide fashion. GConf is also used as
GSettings backend via the GSETTINGS_BACKEND environment variable.
All of this will be removed when these programs have been ported
to GSettings and able to use dconf.
GLib 2.25.9 is required. Schemas are converted to the new XML format,
and compiled at build time in data/ so that the Shell can be run from
the source tree. This also requires setting the GSETTINGS_SCHEMA_DIR
environment variable both when running installed or from source tree,
in src/gnome-shell.in and src/gnome-shell-clock-preferences.in.
https://bugzilla.gnome.org/show_bug.cgi?id=617917
This is a small memory usage optimization, and cleans up the code.
In particular, this will help for later patches which perform
more substantial operations on running apps.
https://bugzilla.gnome.org/show_bug.cgi?id=621203
The shell design says that upon launching an application,
no X window should have focus, and we should display an
animated launching indicator.
Implement this by in panel.js, keep track of the last started
application. If there isn't currently an X focus, show an animation
for the last starting application.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
Canonical replaced status icons with libindicator based solutions,
which don't work in the shell environment. Force the distro-patched
versions to fall-back to upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=621382
While zoomed out in drag mode, the workspaces at the left and right
of the active workspace are slightly transparent - when switching
workspaces, one of the transparent workspaces becomes the new active
workspace, but its opacity is not updated.
https://bugzilla.gnome.org/show_bug.cgi?id=620940
When in drag mode, the linear view raises a transparent actor
covering the entire stage. That way the view can handle events
like dragging items to the screen edges, but in order to not
disable any drop target not handled by itself, it duplicates
huge amounts of code from dnd.js.
Cleanup that mess by using the new drag monitoring support.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
Sometimes it is desirable to be able to react to DND events that
happen outside a target actor's bounds, e.g. to implement reactive
screen edges. Add a simple interface which allows to hook into
drag motion and drop handling without jumping through ugly hoops.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
The design calls for item to not appear abruptly, but not too slow
either - 100ms seems to be a good sweet spot for elements which are
supposed to appear "instantly".
Add a fade effect to the alt-tab popup and set the timings for other
fade effects to 100ms.
https://bugzilla.gnome.org/show_bug.cgi?id=621247
Nothing uses ShellOverflowList any more, so remove it. (Even if we
want that sort of functionality again later, we'd want it to be
StWidget-based, and with a name less likely to be confused with
StOverflowBox.)
https://bugzilla.gnome.org/show_bug.cgi?id=621582
This function reads a single image file which contains multiple
images internally.
The image file will be divided using @grid_width and @grid_height;
note that the dimensions of the image loaded from @path
should be a multiple of the specified grid dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
The framebuffer setup code can fail, e.g. when the texture used as
color buffer has a height/width of 0. In that case, the call to
cogl_pop_framebuffer() will crash the shell trigger an assert. Add
error checking to fail gracefully.
We query the transformed position and size of the popupMenu before actually showing
it which results into wrong positioning, when displaying it for the first time.
In case of the statusMenu this can even result into it being offscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=621385
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
Currently, we use 'gtk-yes', 'gtk-no' and 'gtk-media-pause' as
user status icons. It seems more logical to use the dedicated
icons from gnome-icon-theme instead.
https://bugzilla.gnome.org/show_bug.cgi?id=620374
Our behavior of reversing the animation when the widget's style
changes back to the previous one is sound. On the other hand, when
there's a change to a new style while a transition is active, we
simply cancel the ongoing transition. Updating the transition
correctly so that the new one starts from an intermediate state
is hard.
Nevertheless, if the style changes before any time of the transition
has elapsed, we should do better than the current behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=621140
First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
