Currently when you rename a printer through the print details page
there is no indication of errors produced by CUPS, most notable
about any invalid characters used. Adds a function to check
for invalid characters and shows a warning to users. No
attempt will be made to rename the printer if it contains an
invalid character. Users are currently shown an elevation prompt
before this fix
https://www.cups.org/doc/man-lpstat.html
Partially addresses #1008
Add a label immediately below the printer name entry in printer
details that warns the user if the printer name contains
invalid characters (or other errors) per the CUPS spec.
Ambient light sensors can be quite sensitive and the LightLevel
property might be changing very often. That has two undesired
consequences:
* The `als_enabled_state_changed` callback gets constantly called
due to a change in a property which it does not care about, as
only `HasAmbientLight` is relevant. Therefore, limit the code
execution to when something needs to be changed.
* During debugging, the terminal gets spammed with "ALS enabled: on/off"
messages.
AdwToasts replaces the GtkLabel inside revealer for notifications
and this simplifies handling the notifications and the toast-overlay
handles the complexities of when to show/withdraw them, the order
they are displayed, etc.
The sound plugin of gnome-settings-daemon which flushes the pulseaudio
sample cache does non-recursive monitoring of the sounds directory. If
the custom theme directory used for switching between bell sounds
already exists due to previous bell sound changes, subsequent changes
within that directory will not be noticed. The old bell sample will thus
remain in the cache until the next session restart. Avoid this problem
by manually updating the modification time of the directory.
The alternative solution of adding recursive monitoring to the sound
plugin would require significantly more complicated code as there is no
support for this in glib itself. Given that sound themes never really
caught on and there is an ongoing discussion of removing support for
them entirely, going with this simple solution seems like the better
choice.
Fixes: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/681
WirelessSecurityWPAEAP is a GtkWidget owned by the CEPage8021xSecurity
widget, which is supposed to "unparent" it on "dispose" (since parents
hold a reference to child widgets). Instead we were calling
g_clear_object on it.
Fixes#1671
Weak references are added when logical monitors are created, however we
don't remove them when destroying the display.
This means that if a monitor survives to the display finalization
(because may be referenced elsewhere) it will make g-c-c to crash
during its finalization, as that will trigger the weak reference
callback that will try to access to the already-finalized display.
getlogin() can fail for several reasons as detailed in the man page, and
the current behaviour is a segmentation fault when it fails with NULL,
such as due to an unset loginuid.
* Check return value for error and act accordingly.
* Change to getpwuid(getuid())->pw_name, which is less likely to error.
Instead of using a plain "flat" button positioned at the window corner,
let's use GtkWindowControls to wrap the close button and get the
default window control styling and alignment.
Fixes#1737
Make sure to keep a reference to the GoaObject of the account around so
that the GBinding that synchronises each switch widget and the account
properties don't get finalized on startup.
#0 0x00007ffff73c6a20 in g_binding_finalize () at /lib64/libgobject-2.0.so.0
#1 0x00007ffff73d3d22 in g_object_unref () at /lib64/libgobject-2.0.so.0
#2 0x00007ffff73c68e8 in weak_unbind () at /lib64/libgobject-2.0.so.0
#3 0x00007ffff73cf117 in weak_refs_notify () at /lib64/libgobject-2.0.so.0
#4 0x00007ffff72acd6c in g_data_set_internal () at /lib64/libglib-2.0.so.0
#5 0x00007ffff73d0195 in g_object_real_dispose.lto_priv () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff73d3c44 in g_object_unref () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff72b6793 in g_hash_table_remove_all_nodes.part () at /lib64/libglib-2.0.so.0
#8 0x00007ffff72ba723 in g_hash_table_unref () at /lib64/libglib-2.0.so.0
#9 0x00007ffff753403d in g_dbus_object_proxy_finalize () at /lib64/libgio-2.0.so.0
#10 0x00007ffff73d3d22 in g_object_unref () at /lib64/libgobject-2.0.so.0
#11 0x0000000000402d08 in glib_autoptr_clear_GoaObject (_ptr=0x5d59f0) at /usr/include/goa-1.0/goa/goa-generated.h:3265
#12 glib_autoptr_cleanup_GoaObject (_ptr=<synthetic pointer>) at /usr/include/goa-1.0/goa/goa-generated.h:3265
#13 on_application_activate_show_account_cb (application=0x49f2f0, argv=<optimized out>) at ../../../../Projects/jhbuild/gnome-control-center/panels/online-accounts/gnome-control-center-goa-helper.c:360
Closes: #1721
In the previous design of this panel, it made sense to show the
currently selected monitor because all editing widgets were in
the same page. With the new design, however, the monitor options
were moved to a separate page, and that page already shows which
monitor is being edited.
Remove the colored background of selected monitors.
Instead of updating the titlebar of the monitor preferences page in
the row clicked callback, update it in set_current_output(). This
ensures that the title of the page is always in sync with the monitor
it's displaying.
PpPpdOptionWidget and PpIppOptionWidget both use combo boxes for
certain types of selections. With GTK4, combo boxes no longer
support scrolling[0], which in turn causes problems setting some
things in the PpOptionsDialog[1].
This replaces instances of GtkComboBox with GtkDropDown which do
support scrolling. This change was applied to both PpIppOptionWidget
and PpPpdOptionWidget as both are used in PpOptions dialog.
Since the configuration values passed to CUPS can no longer be stored
in a GtkTreeModel alongside the displayed values, some logic changes
to update_widget_real in PpPpdOptionWidget to maintain the reference
to the ppd_option_t so the selected index can be mapped to the
configuration value.
[0] - https://gitlab.gnome.org/GNOME/gtk/-/issues/3674
[1] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1704
Those are not always present in the device string.
Guidance was taken from the usage on vendor websites.
NVIDIA actually has the rights to GTX™ but doesn’t seem to use it,
in contrast to RTX™.
