The current "Wired" section UI is still optimized for
the old, multi-page panel layout. Recent work [1],
however, suggest that this should change and the standard
widgets be rearranged.
This commit, then, implements this new UI for the wired
devices UI by using a listbox row when there's only one
profile (ditching out the old info labels), and moving
and deleting the bottom action buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
After introducing the new single-column layout,
we can easily hit the case where there are too
many connections and/or devices and the panel
gets way too tall.
To fix that, wrap all the widgets inside a
scrolled window that only scrolls vertically.
https://bugzilla.gnome.org/show_bug.cgi?id=785581
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
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
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
We just present the printer "Model" when printer_make_and_model
is different than NULL OR not an empty string.
We were using the wrong logic operator in the conditional that
toggles the visibility of this info.
The glory moment has come. The new Wi-Fi panel is finally
introduced using a different code style from the rest of
the Network panel, since Control Center itself is written
using the GTK+ C code style.
The Wi-Fi panel uses modern GTK+ features like template
classes and new widgets. The files are stored together
with the Network panel so that we can reuse the abstraction
layer that the Network panel has to manage devices.
https://bugzilla.gnome.org/show_bug.cgi?id=784818
When there are multiple Wi-Fi devices, we must show a stack
switcher in the header of the Wi-Fi panel with the name of
the device.
The problem is that, currently, NetDeviceWifi does not add
its widgets to the main stack setting a stack title, and so
the stack switcher is empty.
Fix that by always adding the widgets to the stack using the
device product name as title.
https://bugzilla.gnome.org/show_bug.cgi?id=784818
The UI definitions of the Wi-Fi devices currently contain many
widgets in the stack, such as the tower icon, the enable/disable
switch and the status.
In the new Wi-Fi panel, all those widgets will clutter the
interface and break the entire UI.
Fix that by splitting those widgets in two different containers:
1. The header_box container, with the menu button and the
enable/disable switch.
2. The center_box widget, with the title and status labels,
which will be consumed by the Wi-Fi panel to be the center
widget of the headerbar.
This commit also introduces two getters that expose those two
containers. With that, another load of code could be simplified.
https://bugzilla.gnome.org/show_bug.cgi?id=784818
The Wi-Fi devices are going to be managed with the
to-be-introduced Wi-Fi panel, and don't need to
be available in the Network panel anymore.
This patch then blacklists Wi-Fi devices and doesn't
let the Network panel manage them.
https://bugzilla.gnome.org/show_bug.cgi?id=784818
The Network panel uses a GtkNotebook internally to manage
the different setup pages of the network devices. While it
does the job, we now have a modern widget for that: GtkStack.
With GtkStack, managing the pages becomes a lot easier and
we gain almost for free the nice transition between pages,
besides of course being a widget that consumes slightly less
resources.
Besides all these gains, using a GtkStack will allow us to
implement the new Wi-Fi panel in a more cohesive manner,
sharing large portions of code and avoiding copy pasta.
This commit then turns the GtkNotebook into a GtkStack, and
renames and adapts the code to reflect that. Fortunately,
the code got actually simpler with the move.
https://bugzilla.gnome.org/show_bug.cgi?id=784818
Whether a mode is interlaced or not is now exported by adding a
'is-interlaced' (b) value to the mode properties variant. Implement the
is_interlaced() vfunc using this information.
The mode format communicated via the new D-Bus API changed to
specifying modes using a per monitor unique mode ID string. The uint
'flags' was also changed to more flexible a{sv} 'properties' structure.
The wacom panel expects all tablet devices to have the "tablet"
device type flag set on the GsdDevice, otherwise devices won't get
recognized and paired with the other devices for the same tablet.
Uncovered now that GTK+ correctly uses GDK_SOURCE_TABLET_PAD for
pad devices on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=784882
For the new or alternative version of Control Center, the Bluetooth
empty state will be vertically alligned to the center for any
app window size. Otherwise when the Bluetooh is powered and available,
the align will be as always.
This changes do not affect to the old version because the windows
size (for the old version) is always the same and small
enought to be in the center in any case.
https://bugzilla.gnome.org/show_bug.cgi?id=784720
While we are now able to find conflicts for a particular key combo in
non-primary bindings, in the case of resetting a shortcut we need to
check all key combos in case the shortcut itself has multiple bindings
by default.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
We now have everything in place to extend the uniqueness check to
consider all bindings of an item rather than just the first one.
With this it is finally possible to set Alt+Tab as binding for
"Switch windows" without keeping the hidden Alt+Tab binding of the
"Switch applications" shortcut ...
https://bugzilla.gnome.org/show_bug.cgi?id=673078
Comparing masks is currently part of the early checks we perform to
determine that two bindings are different. There's some convenience
in that, however logically the mask is part of the binding, and
separating the mask check from comparing the "rest" of the binding
makes it harder to extend the comparison to consider multiple bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
When comparing keys for uniqueness, we currently apply various tests to
check whether shortcuts are different, until we decide that we found a
conflict if none of the tests passed. That approach is a bit weird for
shortcuts that have a reverse item - when comparing a binding to two
different shortcuts, it should always be different from at least one of
them, so there should never be a conflict for any reversible shortcuts.
The reason it does work anyway is that reverse items usually only differ
in modifiers, which is_shortcut_different() currently doesn't consider at
all. We are about to change that however, so refactor the code to set the
conflicting item as soon as we find a match rather than as fall-through.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
For shortcuts that support more than one binding, we currently simply
ignore all but the first. This makes some sense as we only expose a
single binding in the UI anyway, however it means that any extra
bindings are not taken into account for conflict resolution. In order
to address this in the future, start tracking all bindings of an item.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
We currently store keyval, keycode and mask that make up a particular
key combo separately. However as we want to consider multiple bindings
for a single item, it makes more sense to combine them in a dedicated
struct type.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
Some shortcuts allow multiple bindings for the same actions, which
we mainly use to keep supporting old settings when changing defaults.
Multiple bindings are not exposed in the interface though, so when
changing a shortcut with multiple bindings, we previously only updated
the first one and left additional bindings untouched. This is confusing
however, precisely because additional bindings are not shown in the
UI - for instance, this makes it impossible to actually disable
such a shortcut completely. The less confusing option is to clear
any additional bindings when changing a shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
When the Language is changed in the Region panel, a "Restart"
notification is shown, but if the user closes the window without
acting on the restart session notification, there is no way to
get back to it.
This way we create a temporary file in the g_get_user_runtime_dir ()
directory flagging whether we should present the "Restart"
notification.
https://bugzilla.gnome.org/show_bug.cgi?id=702351
It seems like (at least some versions of) gdk don't set
GDK_SOURCE_TOUCHPAD on synaptics devices. In this case though, we
don't need the additional check. Just knowing if there's any device
being driven by this X driver is enough.
https://bugzilla.gnome.org/show_bug.cgi?id=784266
Commit cf408c27b0 changed how the values stored in the "area" key were
calculated in order be compatible with its updated schema. Unfortunately,
it overlooked the fact that updated schema also changed the order of the
values from "left, top, right, bottom" to "left, right, top, bottom".
Because of this, corrections intended to be applied to the top and right
screen edges were swapped. This can cause a noticible cursor offset to
occur after finishing calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
The calibration utility was modified in cf408c27b0 to return unitless
padding measurements instead of axis values for storage in gsettings.
Unfortunately, the code still assumes in some places that it is working
with axes rather than paddings. This causes subtle math errors that
result in undesired cursor offsets after the calibration is applied.
Fortunately, this can be simplified, since tablet area is always reset
to the default state before starting calibration, we are sure that the
value will remain constant. Since both axes are in the same 0..1 scale,
calibration code doesn't need to swap X/Y back and forth to calculate
each axis scale.
Additionally, the code to get the calibrated axis values has been moved
into its own function along with a new function that returns padding
values suitable for consumption by g-c-c. All calculations are performed
internally in the 0..1 range.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
Co-Authored-By: Carlos Garnacho <carlosg@gnome.org>
Filtering on the name currently only matches the string as a whole,
not individual words as expected, for instance "home fo" and "ho fo"
should both match "Home Folder".
https://bugzilla.gnome.org/show_bug.cgi?id=784357
