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
This was causing a segfault when the user clicks the cancel button
on add new printer dialog (in case when no printers are listed, and no
printers are added).
output from sanitizer:
==22669==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fe1c7a4d409 bp 0x7ffd179f6410 sp 0x7ffd179f6410 T0)
#0 0x7fe1c7a4d408 in g_str_hash /home/sadiq/jhbuild/checkout/glib/glib/ghash.c:1882
#1 0x7fe1c7a4c814 in g_hash_table_lookup_node /home/sadiq/jhbuild/checkout/glib/glib/ghash.c:379
#2 0x7fe1c7a4c814 in g_hash_table_lookup /home/sadiq/jhbuild/checkout/glib/glib/ghash.c:1153
#3 0x55cef023a121 in new_printer_dialog_response_cb /home/sadiq/jhbuild/checkout/gnome-control-center/panels/printers/cc-printers-panel.c:914
https://bugzilla.gnome.org/show_bug.cgi?id=783406
Create 2 veth interfaces without any names with, as root:
ip link add veth0 type veth peer name veth1
ip link set dev veth0 up
ip link set dev veth1 up
And run:
(gnome-control-center:28176): GLib-CRITICAL **: g_utf8_collate: assertion 'str1 != NULL' failed
(gnome-control-center:28176): GLib-CRITICAL **: g_utf8_collate: assertion 'str2 != NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=783996
