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
Due to lockdown settings or Polkit policy, shutdown may not be
available. If this is the case, the "Power off ..." action should
be hidden from the user status menu.
https://bugzilla.gnome.org/show_bug.cgi?id=652038
The screen panel in System Settings has a preference whether the
screen should be locked on suspend. This works fine when suspending
by closing the lid, but the "Suspend" menu item in the user status
menu ignores the setting and always locks the screen.
Fix by activating the screen saver before suspending rather than
locking explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=652327
Right now, the user status menu always contains actions to logout
and lock the screen, and the user switching action only depends on
the technical availability of the functionality.
All those items should honor the lockdown settings defined in
org.gnome.desktop.lockdown.
https://bugzilla.gnome.org/show_bug.cgi?id=645335
In commit 9bd22dc0, I introduced an API to load an arbitrary
.desktop file, not necessarily from the menu path. It turns
out this function was broken because it created ShellApp instances
that were *different* from ones that were cached normally.
As far as I can tell, we didn't initially use it. Then later
Util.spawnDesktop was created which used this function.
Remove this broken function and all callers; if we're loading
.desktop files from *outside* the menu path, we can look at
readding.
This patch also kills off Util.spawnDesktop in favor of callers
talking to ShellAppSystem directly, now that the latter reports
errors.
https://bugzilla.gnome.org/show_bug.cgi?id=644402
Around 2.91.90, gnome-session-save was renamed to gnome-session-quit.
This commit restores compatibility with the older gnome-session, for
those testing under GNOME 2.32 or below, by calling the DBus methods
directly.
https://bugzilla.gnome.org/show_bug.cgi?id=644591
Make all subclasses of PopupMenuBase accept a params argument, which
can be used to make the item non reactive, not responsive to hover
and, as a new feature, with a different style class.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
It doesn't currently work, so hide it for now.
It's not clear it's going to stay around long term,
anyway. If it doesn't we can delete the code, then.
Otherwise, we can add the code back when we have
something that works.
https://bugzilla.gnome.org/show_bug.cgi?id=636680
Add Util.spawn, Util.spawnCommandLine, and Util.spawnDesktop for
spawning a command/argv/.desktop file in the background, automatically
handling errors via MessageTray.SystemNotificationSource(), and
Util.trySpawn, Util.trySpawnCommandLine, and Utils.trySpawnDesktop
that don't do automatic error handling (but do at least clean up the
error message in the exception a bit).
Update various other bits of code around the shell to use the new
methods.
https://bugzilla.gnome.org/show_bug.cgi?id=635089
According to the HIG we should use ellipsis when:
"Label the menu item with a trailing ellipsis ("...") only if the command requires further
input from the user before it can be performed. Do not add an ellipsis to items that only
present a confirmation dialog (such as Delete), or that do not require further input
(such as Properties, Preferences or About)"
So adjust the use of ellipsis to match that.
Pointed out by Michael Monreal.
It was decided at GNOME Summit that we would remove the invisible
setting until we have a better story for how it works with chat
and other sharing/messaging applications. We'd also need to
figure out how it relates to busy.
The action is far less common than powering off. It is mostly
used for performing system updates so the update tool should
offer the option directly. Also, currently the Shut Down option
dialog offers Restart anyway. We would like to keep the number
of entries in this menu as limited (close to 7) as we can.
Switch from St.TextureCache.load_named_icon() to using St.Icon for named
icons. Along with the advantage of getting colorization right for symbolic
icons, this allows moving some icon sizes into the CSS.
In the CSS, the system status icon size is changed to be 1em (=16px for the
default font size), at the request of the artists. See bug 613448.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
Adding a "PopupMenuRadioButtonItem" wouldn't work well, because we'll
need radio-button indicators on multiple different styles of menu
item. Also, the current design draws the indicator in the menu item's
padding, so it's sort of special anyway. So just add support at the
BaseMenuItem level.
Also, redo the menu/menuitem padding so that all the horizontal
padding is in the menu item, or else the indicator dot will show up in
the wrong spot.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
Rename a few, and add Suspend and Restart, although currently they do
the same thing as Shut Down (ie, they bring up a dialog that lets you
do any of those three). This will be fixed later when we have the
in-shell modal dialogs for these features.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
In the new mockups, the user menu icons are on the right, not the
left.
Also, get rid of the idea of optional icons; the design doesn't have
icons on those items, and there probably aren't going to be symbolic
versions of some of those icons anyway. So if the caller specifies
PopupImageMenuItem, then always show an icon, and just use regular
PopupMenuItems for the items that don't have icons in the current
design.
https://bugzilla.gnome.org/show_bug.cgi?id=631193
Icons can be loaded as St.Icon.SYMBOLIC, FULLCOLOR, APPLICATION or
DOCUMENT. The first will look for a symbolic equivalent, the second
looks for a full-color version (and does fallback, eg, from
"drive-harddisk-usb" to "drive-harddisk"). APPLICATION and DOCUMENT do
full-color icons without fallback (as specified by the icon spec).
And update various callers to use the right flags.
Based on a patch from Matt Novenstern.
https://bugzilla.gnome.org/show_bug.cgi?id=621311
Solved by splitting the base class (PanelMenuButton) in a separate
module, ui.panelMenu, which is meant to hold also other reusable
button classes.
https://bugzilla.gnome.org/show_bug.cgi?id=621705
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
In all the cases where we activate GNOME 2 UI, e.g. the shutdown
dialog, pop out of the overview. Otherwise, it's fairly broken
since you won't see the result of your action.
https://bugzilla.gnome.org/show_bug.cgi?id=620525
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
