The current Network panel is composed of a single stack and
a treeview to select the currently visible stack page. Each
stack page represents a connection or device.
The new Network panel, however, has none of the concept of
selectable pages. In the new layout, all connections and
devices appear all at once in a more compact and simpler
fashion.
This commit, then, starts moving towards a unified, pageless
panel by adding all the connections and devices to different
stacks. These different stacks are transient to the network
object, and are added at appropriate boxes, giving the panel
a unified layout.
This has some serious implications in the design of the
current code. Most of the code removals were related to the
treeview and different pages handling. No more tree model
madness is present, and the devices are now stored in a
plain simple GPtrArray.
After this patch, NetObject:add_to_stack isn't a good code
design choice anymore. This will be addressed in a future
patch.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
This implements most of the new Display panel re-design by Allan
Day.
Left out for now is brightness setting which still is in the
Power panel because the plumbing layers don't yet associate backlights
with outputs.
Also left out is the presentation mode and trimming of options due to
hardware constraints since we don't have a mutter implementation for
those yet.
https://bugzilla.gnome.org/show_bug.cgi?id=785949
We often use rows representing different things in the same list
box. In these cases it's often desirable to have rows emitting their
own activation signals instead of having a single handler for the
whole list box that dispatches according to the activated row.
https://bugzilla.gnome.org/show_bug.cgi?id=785949
Multiple translations erroneously listed Toronto as "Tortola". There is
a city named Tortola, and appears as the next city in these records.
But in none of these languages is Tortola a translation of Toronto.
https://bugzilla.gnome.org/show_bug.cgi?id=785922
The current Network panel class relies on GtkBuilder
when it could use a more modern feature that is the
template class.
By making it a template class, not only the Network
panel is slightly more performant, but it's also
simpler and easier to read.
This commit, then, turns the Network panel into a
template class, and cleans up the code to make it
work.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
The Network panel UI file uses deprecated widgets and
has many lines of needless code. This commit just cleans
it up, as a preparation for turning the Network panel
into a template class.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
The Network panel is not really a deriverable type, and
since after 61d7abe795 we can use the
utility macros.
Thus, this commit removes all the boilerplate code and
turns CcNetworkPanel into a final class.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
The Network panel does not deal with Wi-Fi devices anymore,
and does not make sense to have the Airplane Mode switch in
there, since it is now available at the Wi-Fi panel.
This commit then removes the Airplane Mode switch from the
Network panel.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
All the new panels have a standard 24px margin now, so
since we're already splitting the info pages into separate
panels, also fix this minor annoyance.
https://bugzilla.gnome.org/show_bug.cgi?id=779216
Some panels shall be shown only in current design, And some other panels
shall be shown only in new Shell design. So let's have a code that
would help us do that
https://bugzilla.gnome.org/show_bug.cgi?id=779216
The displayed panel should always match the selection in the panel
list. That implies that after swapping out the list (for instance
by browsing Devices or Details), we need to update the panel rather
than keeping the old one around until the user manually selects a
row. The easiest way to achieve that is to activate the panel list
after a view change when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=783429
For shortcuts that support multiple bindings, the disabled state is
expressed as an empty list rather than a list with a single empty
element. While the latter certainly works as expected as far as the
actual keybinding is concerned, the shortcut will show up as modified
even if it is disabled by default. Explicitly setting bindings to the
empty list when a shortcut is disabled fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784620