Devices are represented as susdut, not susbut (i.e. the percentage
is a double rather than a boolean) - apparently the wrong signature
works, but correct it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=660122
All the system status menus in the panel offer a
menu item to jump to a relevant part of the
control-center.
This means each status icon has the same, or nearly the
same bit of code to:
- Add a new "action" menu item and listen for its activation.
- Hide the overview if it's showing when the menu item is activated
- Find the relevant control-center panel from its desktop file
- Launch the control-center to the relevant panel
This commit consolidates all those details in a new method,
addSettingsAction. This refactoring reduces code duplication and
slight inconsistencies in the code resulting from that duplication.
It will also make it easier in subsequent commits to hide settings menu
items when the shell is used in the login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
A separator only makes sense if there are items on both
sides of it. There is quite a lot of code written
throughout the shell that manages the process of showing
and hiding separators as the items around those separators
change.
This commit drops all that code in favor of changes to the menu
implementation to dynamically hide or show separators as
appropriate, so the callers don't have to deal with it.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
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
On error, we tried to kill and respawn gnome-power-manager, but
as of commit c5676900 the DBus interface provided by g-s-d's power
plugin is used, so the respawning does not have any effect.
https://bugzilla.gnome.org/show_bug.cgi?id=654300
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
When UPower has not yet collected enough data to calculate a time
to discharge, it will report 0 minutes. Show "Estimating..." in
that case instead.
https://bugzilla.gnome.org/show_bug.cgi?id=642753
The DBus JS binding will complain if the signature of a method
or of a signal is undefined, so we need to define it even if it
is an empty string, and we need to use the correct property name
for signals.
https://bugzilla.gnome.org/show_bug.cgi?id=643374
Since we have to use pkill, kludgily, for the right combination of
portability and featurefulness, put the code in one place rather than
duplicating it everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=635089
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
Mixing submenu menuitems and toggle menuitems results in poor layout.
The fix is to right-align the submenu arrows. Since we already need to
right-align the battery percentages as well, add alignment support to
PopupBaseMenuItem.addActor(), and update stuff for that.
Also remove the "column" param from addActor() since it hadn't
actually been implemented correctly before.
https://bugzilla.gnome.org/show_bug.cgi?id=633476
We updated the normal devices part, but we forgot the part about
the primary device (possibly because it is not reported as such
in case it is fully charged). Update that as well, to avoid showing
weird GIcon serializations.
https://bugzilla.gnome.org/show_bug.cgi?id=635288
