It does not make a great amount of sense to have this function
on the login screen. And worse, it does not work, since the greeter
is currently a modal dialog, so interaction with the opening
window is impossible.
https://bugzilla.gnome.org/show_bug.cgi?id=659164
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
Wireless and 3g dialog code has moved to gnome-control-center, so
we can stop calling out to nm-applet. Also, we can now enable the
notifications provided by the shell and kill a bit of code about
auth that is not actually needed.
https://bugzilla.gnome.org/show_bug.cgi?id=650244
It is not possible to connect to hidden access points without
knowing the SSID, and it should be done using the control center
panel and the appropriate dialog. At the same time, this should
fix some warnings from libnm-glib and dbus-glib.
https://bugzilla.gnome.org/show_bug.cgi?id=646454
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
Since this link in the keyboard menu points to Region and Language
Settings in System Settings, we should be consistent and use that
term instead of "Localization Settings"
Also, this removes ellipsis from "Show Keyboard Layout" since it
doesn't require further input.
https://bugzilla.gnome.org/show_bug.cgi?id=652984
Keeping the volume menu open after setting the desired volume isn't that
useful and forces a second click (or an Esc press) to dismiss it. Allow for
the sliders to be used with a single click-hold-move-release.
https://bugzilla.gnome.org/show_bug.cgi?id=649586
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
When one of the networks in the main menu is removed and we have
a More... submenu, we can take the first out from the submenu and
show it in the main menu.
https://bugzilla.gnome.org/show_bug.cgi?id=647175
Use the new PopupSwitchMenuItem functionality when bluetooth cannot
be enabled. Use it also for showing "connecting..." when activating
device items.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
Moves and converts NMDeviceTitleMenuItem from network.js into
PopupSwitchMenuItem, so that it can show both a switch and a
greyed-out status label. This will be soon used by the Bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=648048
_createNetworkItem was always appending access point at the end of
the menu when their position was < 5 (NUM_VISIBLE_NETWORKS), ignoring
the presence or absence of _overflowItem, which thus ended in the
middle of the network list. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=652313
If we have more than 5 (which can happen with VPN connections), place
them into a More... submenu, which also becomes scrollable if needed.
To protect from race conditions and ordering issues while reading
connections, sort them in alphabetic order when the timestamp is equal.
https://bugzilla.gnome.org/show_bug.cgi?id=651602
Some users are confused when their devices are not shown in the
network menu, even if they configured them manually. Mark their presence
by showing them in the menu, even if they cannot be otherwise
interacted with.
Also add a status string for deactivating devices (none currently,
soon will appear in NetworkManager).
https://bugzilla.gnome.org/show_bug.cgi?id=646946
All WPA APs were getting set as WPA2 due to the check for privacy;
WPA/WPA2 APs *must* set the Privacy bit according to the standard,
so we'd never end up in the case for NMAccessPointSecurity.WPA.
Fix that, and also add flags for WPA[2] Enterprise which we'll
use a bit later for the first-time connect case for 802.1x enabled
access points.
Instead of rolling our own code, use new libnm-glib functions to do
the same thing. Requires libnm-glib as of
779215c742bbe29a2c66202ec7e2e6d43edeb8ff (which will be part of 0.9).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=648648
Previously, we skipped rebuilding device items in case the device
had already been seen, but this caused the connected switch not to
be updated. Now it has been refactored to update in case the device
changes, and to create only when the device is completely new.
https://bugzilla.gnome.org/show_bug.cgi?id=647565
Adds a function that compares wireless networks and keeps them sorted
at all times. Order is: first already configured connections, then
first secure networks, then alphabtic. Also, the appearance of a new access
point no longer causes the whole menu to be rebuilt (but it still linear
searches for the position, I guess that could be skipped), which caused
the addition of more code for tracking the active access point.
https://bugzilla.gnome.org/show_bug.cgi?id=646580
The IP_CHECK and SECONDARIES states should be considered part of the
"connecting..." phase.
DEACTIVATING should be its own stage, but that would break string
freeze, so we just treat it like DISCONNECTED for now.
UNMANAGED needs to be treated differently in 3.2, but it is too late
to fix it for 3.0.1.
https://bugzilla.gnome.org/show_bug.cgi?id=646946
When more than one device exists, we need to reset the section title's
device to null, and in that case we must show nothing (neither the switch
nor the label, but an empty label is OK anyway). Also, we need to
update the device statusItem immediately when constructing it, as we
may not get any state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=646074
NMDeviceModem._createSection was not checking whether it should have
shown the connection list, resulting in status item shown even if
the device was in an invalid state.
Also, fix a logic error when creating the operatorItem and fix overriding
_clearSection protected method.
https://bugzilla.gnome.org/show_bug.cgi?id=646395
NMApplet connects to each NMDevice's state-changed signal and stores
the signal handler id on the NMDevice itself. However, it was using
the same name as NMDevice itself was using to store the handler ID for
the underlying GObject's state-changed signal, thus overwriting it,
and resulting in *neither* signal handler getting removed if the
device went away. (This probably isn't a problem, since the device is
going away, but it causes a warning.)
Also, at least for WWAN devices, the device state changes to UNMANAGED
immediately before disappearing, but getStatusLabel() wasn't handling
that case and printed a warning instead. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=646708
If you restart NetworkManager, then the list of active connections
is emptied, then comes back with the same GObjects in it. If the
_primaryDevice field isn't cleared on the object, then we won't
know we need to set it back on the device, resulting in the active
device not showing up in the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=646558
A notify signal does not include the new value of the property in
its signature, so the handler was trying to compare a GParamSpec with
a number when updating. Fix it to always retrieve the value from the
object.
https://bugzilla.gnome.org/show_bug.cgi?id=646443
