Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
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
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
Application search results are internally categorized in four sets,
multiple and single prefix matches and multiple and single substring
matches. Each set is currently sorted alphabetically by application
name when concatenating the sets to the final result.
Change the last step to sort each set by usage frequency instead,
which is more likely to favor the most relevant match than
"arbitrary" alphabetic order.
https://bugzilla.gnome.org/show_bug.cgi?id=623372
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
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
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
While the extension system already uses an XDG location (XDG_CONFIG_HOME),
other components use the deprecated $HOME/.gnome2 directory.
Replace both with XDG_DATA_HOME - the existing data (app usage stats,
looking glass history and extensions) is not migrated to the new location.
https://bugzilla.gnome.org/show_bug.cgi?id=617555
We were holding on to UsageData structure pointers in previously_running,
but those can be purged by the unused app cleanup. Instead just hold
onto dup'd copies of the application id strings.
The synchronous close causes us to block in fsync() which has extremely
poor interactivity implications on ext3.
Also, the 5 second timeout was an accidental commit from debugging, 5
minutes is fine.
https://bugzilla.gnome.org/show_bug.cgi?id=602456
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
