Commit 0af108211c introduced a
regression where applications that appear in multiple categories were
duplicated in the "All Apps" list, because we switched from
uniquifying on desktop file ID to the GMenuTreeEntry.
Switch back to keeping the set of apps based on ID. To flesh this
out, we keep the ShellApp instance for a given ID around forever, and
when we're loading new contents, we replace the GMenuTreeEntry inside
the app. That means callers still get new data.
We still keep around the running app list, though we could just
recompute it from the app list now.
https://bugzilla.gnome.org/show_bug.cgi?id=659351
The apps and settings loading code duplicated the part to traverse a
GMenuTree. Unify this by adding a new function to return a flattened
set.
This will also be useful for a future change to how we store apps -
this way we can look at both the current set of apps and the new set.
https://bugzilla.gnome.org/show_bug.cgi?id=659351
Instead of doing complex computations in the shader just pass in the correct
fade area (taking padding, scrollbars and rtl into account) and just work
with that in the shader.
That fixes a bug where we would fade the scrollbar when padding is present.
https://bugzilla.gnome.org/show_bug.cgi?id=659159
The way the window dimmer shader is applied will cause rendering errors with
the rounded corners, invisible borders or shaped textures since it doesn't deal
well with the multitexturing used by the MetaShapedTexture. Use an off-screen
buffer to flatten the texture before being applied.
https://bugzilla.gnome.org/show_bug.cgi?id=659302
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
It was always taking the first .service.in file to create all .service
files: org.gnome.Shell.CalendarServer.service.in was the only one being
used.
https://bugzilla.gnome.org/show_bug.cgi?id=659194
Base ShellStack on StContainer rather than ClutterGroup, so that it
has StWidget-y features (and so we don't have to "cheat" in
shell_stack_allocate()). Implement navigate_focus() to only ever pass
focus into the top-most child, since doing otherwise would be
surprising.
https://bugzilla.gnome.org/show_bug.cgi?id=646934
The translation is taken from GTK+, so translations in the gnome-shell
domain are pointless - hide the string, so that it is not extracted
by xgettext.
In particular, document that you can ignore the get-preferred-*
signals if and only if you have a fixed width/height specified by some
other means.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
This patch fixes the "apps vanish from alt-TAB bug".
If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...). In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.
In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.
What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance. This ensures we preserve any state such as the
set of open windows.
This requires moving the running state into ShellAppSystem. Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.
This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation. As long as
we're on top of random broken tar+wget wrappers, it will be gross.
A slight future improvement to this patch would add an explicit
"merge" between the old and new data. I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=657990
This adds contacts search to shell, powered by libfolks.
Changes:
- Add Folks and Gee to the build system
- ShellContactSystem, a backend in C
- ContactDisplay, search frontend in JS
https://bugzilla.gnome.org/show_bug.cgi?id=643018
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
StAdjustment has some non-functional and unused animation vestiges
like the "elastic" property, st_adjustment_interpolate() and
st_adjustment_clamp().
This commit vacuums that stuff up so it doesn't tempt anyone into
trying to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
A network agent is a component that stores network secrets (like
wifi passwords) in the session keyring. This commit adds an
implementation of it to be used by the shell network dialogs. It
handles most of the keyring stuff, delegating the UI to upper layers.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
Adds get_state() and ::state-changed signals, that replace connecting
and ready, as well as providing indication of when the object was closed
or the connection to PulseAudio failed.
https://bugzilla.gnome.org/show_bug.cgi?id=645708
During a state transition from running to not-running for
window-backend apps, it's possible we get a request for the icon.
Avoid asserting here and just return an empty image.
https://bugzilla.gnome.org/show_bug.cgi?id=656546
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
As danw points out,
"It's unique during the lifetime of the window, but reasonably likely to be
reused by another window after this one is destroyed. Using
meta_window_get_stable_sequence() might be better."
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Add a helper function (mostly copied from gtkcalendar.c) for getting
the first week day for the current locale, using nl_langinfo if
available and falling back to the GTK+ gettext fallback otherwise.
Use that function in the calendar, so that the LC_TIME setting is
used if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=649078
If a container is not clip-to-allocation, then its get_paint_volume()
needs to include the paint volumes of all of its children, since they
(or their children) may paint outside the container's allocation.
Also, if the superclass get_paint_volume() returns FALSE, then the
subclass should return FALSE too.
https://bugzilla.gnome.org/show_bug.cgi?id=655812
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
