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>
