Refactor NMDeviceVPN to be more like the other NMDevices, including
having a valid getSectionTitle() and emitting signals when the
underlying connection changes state.
Use the existing notification infrastructure to hook these signals
to actual notifications (including some code consolidation).
https://bugzilla.gnome.org/show_bug.cgi?id=676330
Ensure that the UI is updated when a connection changes name or id,
even if it was already known by a device.
Also, use less private properties on NMConnection objects, as they
can become stale and cause problems.
https://bugzilla.gnome.org/show_bug.cgi?id=677097
For most subclasses, this is a direct swap -- a lot of the time, the
constructor was a blank class that override createNotificationIcon,
and called _setSummaryIcon in _init.
https://bugzilla.gnome.org/show_bug.cgi?id=661236
We seem to have a lot of code that does something along the lines of:
if (condition)
actor.show();
else
actor.hide();
ClutterActor already has such a thing for exactly this purpose: the 'visible'
property. Use it instead of the mess above.
https://bugzilla.gnome.org/show_bug.cgi?id=672272
nm_active_connection_get_devices() has a (questionable) special case
for the no devices case (which happens if the DBus object is
destroyed because NM went down): it returns null instead of an empty
array. Handle that instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=673043
Previously the code in _accessPointAdded was iterating over the
the network list to find a good place, and at that time, added both
the network to the list and the item to the menu. When I refactored
to call queueCreateSection, I forgot to add code to insert the
network in the list.
Add it now, using the new Util.insertSorted function.
https://bugzilla.gnome.org/show_bug.cgi?id=666429
By using Main.queueDeferredWork, we can ensure that most of the
menu contents (in particular, the heaviest parts like the list of
wifi networks) are not updated immediately as we receive signals
from NetworkManager. Instead, the menu is rebuilt some time later,
or as soon as the user opens the menu.
This means that it is no longer needed to optimize for the
access-point-added case, replacing a lot of buggy code with a safer
call to _queueCreateSection, which in turn should ensure that the
more menu, if existing, is always at the end and that at most 5 networks
are visible outside it.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
When wifi or wwan are blocked by hardware killswitch, we should not
allow changing the switch (it won't work anyway), and show
"hardware disabled" instead, similar to what we already do in the
bluetooth menu.
https://bugzilla.gnome.org/show_bug.cgi?id=665194
When placing networks in _createSection, we were taking in
consideration that _activeNetwork is always first, by adding 1,
but then kept this offset also for networks following it (normally,
all of them, since _activeNetwork is also the most recently used),
that instead should not be affected by the movement.
This resulted in the menu showing 4 networks + More... instead of
5.
https://bugzilla.gnome.org/show_bug.cgi?id=664124
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Third step in the class framework port, now it's the turn of
MessageTray.Source and MessageTray.Notification, as well as
the various implementations around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
When changing _findNetwork with _findExistingNetwork, I changed
the return value to avoid searching twice for the access point,
and changed some names. I forgot to update all points where those
names were used.
https://bugzilla.gnome.org/show_bug.cgi?id=663278
Previously, we connected to notify::strength only if there was
already a signal connected, and the AP changed (thus, by induction,
we never connected). As a result, the icon became stale and different
from that shown inside the menu (which is correctly updated).
https://bugzilla.gnome.org/show_bug.cgi?id=650007
PopupMenu.firstMenuItem returns a PopupMenuItem, not an apObj. We
need to retrive the latter using the _apObj property.
Also, somehow the property from the number of elements in a menu
was changed from .length to .numMenuItems, and this broke the
destruction of the menu upon emptying it.
https://bugzilla.gnome.org/show_bug.cgi?id=659277
Calling nm_access_point_get_ssid() in the handler of the
access-point-removed signal can result in DBus request, which will
then fail because the object was already removed at the server side.
Instead, use a difference function to retrieve the access point
object (the network), that compares directly by object identity.
https://bugzilla.gnome.org/show_bug.cgi?id=651378
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
When the active AP disappears, it is possible to receive the
"access-point-removed" signal before the "notify::active-ap" (as
dbus-glib + libnm-glib property notifications are not reliable).
In that case, we would remove the AP from the network object, thus
an attempt to update the UI would create an item for an empty
network.
https://bugzilla.gnome.org/show_bug.cgi?id=658150
Current code is sometime attempting to create menu items for wifi
networks that have no visible AP. I have no idea why this is
happening, but it should fix the symptoms and avoid exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=658150
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
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
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
