AdwStatusPage can't be used with other widgets because it
contains a GtkScrolledWindow, so mimic AdwStatusPage to
show Wi-Fi Hotspot status.
Also:
- Add a mnemonic to the "Turn Off Hotspot..." button.
- Use the new strings from the latest mockups [1]
[1] cfb7cae4a9
When closing the lid on a laptop, the number of active monitors drops to
zero. However, `monitor_labeler_show()` always assumes at least one
monitor is active, as it unconditionally closes the `GVariantBuilder`.
This causes a crash when there is no monitor added to the
`GVariantBuilder`, however, as no value was added to it.
Instead, only close the `GVariantBuilder` when we're actually going to
use it and know a value was added.
Commit ca9228bb fixed a similar crash for when there are no outputs at
all. But in this case, there is still an output, it is just not active,
only with the active UI number as 0.
Fixes#3058
When resizing the parent window to its minimum size, the QR
code from the Share Network dialog becomes so small that it
can't be read. This regression appeared with the port to
AdwDialog.
To fix this, add min-width/height properties to the QR code
image and use a GtkScrolledWindow to make the dialog contents
scrollable.
Both AdwStatusPage and AdwPreferencesPage have a GtkScrolledWindow.
This can cause scrolling to break. To fix this, separate both widgets
into their own stack pages.
Also, remove "app_search_stack_page" object ID, as it's unused by the
C code.
Doing so, the search entry won't get hidden when scrolling
through the app list. This is neeeded to stop using the
"No Apps Found" together with AdwPreferencesPage, because
both widgets have a GtkScrolledWindow; this can cause
scrolling to break.
- Use modern widgets like AdwPreferencesPage/Group,
AdwEntryRow and AdwPropertyRow
- Set a minimum size for the window
- Add .error class to the printer name entry
when the name is invalid
- Restyle the printer name error message
- Add missing mnemonics
- Remove the "run_warning" method, as it's no longer needed
now that all AdwAlertDialogs are located in the .ui file
- Remove "clear_recent_button" object ID, as it's unused by
the C code
Also:
- Move the dialog to the .ui file, as this dialog is UI-related
- Don't destroy/force close the dialog, as it will be closed
automatically after the responses are triggered
Also:
- Move the dialog to the .ui file, as this dialog is UI-related
- Don't destroy/force close the dialog, as it will be closed
automatically after the responses are triggered
Also:
- Move the dialog to the .ui file, as this dialog is UI-related
- Don't destroy/force close the dialog, as it will be closed
automatically after the responses are triggered
Require the use of <child type="subpage"> for when an AdwNavigationPage
is expected to be added to CcPanel.navigation.
This way we can avoid programming errors when a child widget is wrongly
packed in the navigation view.
See also https://gitlab.gnome.org/GNOME/gnome-control-center/-/wikis/shell/CcPanel#child-packing
Co-authored-by: Matthijs Velsink <mvelsink@gnome.org>
Makes use of the cc_panel_push_subpage method.
The changes in cc-system-panel.ui are better reviewed without identation
changes, using "git diff -w", "git show -w".
Since GTK 4.8, gtk_widget_dispose_template() is available to
automatically unparent child widgets from templated GtkWidgets. This is
only needed for GtkWidget derived classes, as most other classes will
automatically unparent their children.
This makes widget implementations slightly simpler, and is also
recommended at
https://developer.gnome.org/documentation/tutorials/widget-templates.html
So, start using that function where we can.
Commit 340ee1dcfixed#1671, but the real cause of that issue was that
the widget is part of a GtkBox, which will always automatically unparent
child widgets. That caused #1671.
Also, the check for the parent is a left-over from the GTK3 days, and
its GtkContainer usage. In GTK4 there is no way a new widget will
already be inside the GtkBox to begin with.
So, don't unparent the widget at all, and stop checking for its parent.
In the GTK3 days, HdyPreferencesRow (and GtkListBoxRow) did not
automatically unparent children.
In GTK4, AdwPreferencesRow (and GtkListBoxRow) do, so stop manually
unparenting child widgets.
Also:
- Move the dialog to the .ui file, as this dialog is UI-related
- Don't destroy/force close the dialog, as it will be closed
automatically after the responses are triggered
Also:
- Move the dialog to the .ui file, as this dialog is UI-related
- Don't destroy/force close the dialog, as it will be closed
automatically after the responses are triggered
This is just unfortunate. It’s an aliasing violation to cast a pointer
to a pointer (and there’s no way round that), although in practice it
will not cause a problem. People do quite often compile with
`-Werror=strict-aliasing`, though, so fixing the warnings is helpful.
Warnings are of the form:
```
../../source/gnome-control-center/panels/keyboard/cc-keyboard-shortcut-dialog.c: In function ‘cc_keyboard_shortcut_dialog_finalize’:
../../source/gnome-control-center/panels/keyboard/cc-keyboard-shortcut-dialog.c:518:20: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
518 | g_clear_pointer ((GtkWindow**)&self->shortcut_editor, gtk_window_destroy);
/opt/gnome/install/include/glib-2.0/glib/gmacros.h:871:47: note: in definition of macro ‘G_STATIC_ASSERT’
871 | #define G_STATIC_ASSERT(expr) _Static_assert (expr, "Expression evaluates to false")
| ^~~~
../../source/gnome-control-center/panels/keyboard/cc-keyboard-shortcut-dialog.c:518:3: note: in expansion of macro ‘g_clear_pointer’
518 | g_clear_pointer ((GtkWindow**)&self->shortcut_editor, gtk_window_destroy);
| ^~~~~~~~~~~~~~~
In file included from /opt/gnome/install/include/glib-2.0/glib/gatomic.h:30,
from /opt/gnome/install/include/glib-2.0/glib/gthread.h:34,
from /opt/gnome/install/include/glib-2.0/glib/gasyncqueue.h:34,
from /opt/gnome/install/include/glib-2.0/glib.h:34:
../../source/gnome-control-center/panels/keyboard/cc-keyboard-shortcut-dialog.c:518:20: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
518 | g_clear_pointer ((GtkWindow**)&self->shortcut_editor, gtk_window_destroy);
/opt/gnome/install/include/glib-2.0/glib/glib-typeof.h:39:36: note: in definition of macro ‘glib_typeof’
39 | #define glib_typeof(t) __typeof__ (t)
| ^
../../source/gnome-control-center/panels/keyboard/cc-keyboard-shortcut-dialog.c:518:3: note: in expansion of macro ‘g_clear_pointer’
518 | g_clear_pointer ((GtkWindow**)&self->shortcut_editor, gtk_window_destroy);
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
I believe it’s better to fix these by expanding out the
`g_clear_pointer()` call, than by changing the types of variables — the
latter approach means everything becomes a `GtkWidget` or a `GtkWindow`,
which loses type specificity. So this approach is in contrast to that
taken in commit 1bafd46ea3, for example.
Alternative approaches would be:
1. Add internal `cc_clear_window()` and `cc_clear_widget()` helpers
which do this in a single line without aliasing violations.
2. Enforce compiling with `-Wno-strict-aliasing` if strict aliasing is
not something that g-c-c maintainers want to care about (which would
be fine, aliasing checks probably won’t catch any bugs in this kind
of code).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2563
This is another false positive, where the control flow conditions on
`modem_signal` prevent any reading of `refresh_rate` until after it’s
been initialised.
Compilers aren’t good at static analysis of conditional control flow,
though, so let’s just initialise both variables to safe defaults.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This fixes an error when building with `-Werror=maybe-uninitialized`.
It’s a false positive, because the `for` loop conditions ensure that a
`default:` case in the `switch` is never needed. However, compilers are
historically quite bad at static analysis of loop iteration count, so
let’s just initialise the variable to a safe default.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This fixes commit f00dc11f38. It’s needed
because the generated `enums.c` files refer to files in the
subdirectories by filename with no path.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
autoptr variables must *always* be initialised at the time of
declaration, as the compiler unconditionally inserts the free function
based on the control flow, and constantly re-checking the declarations
whenever you change the control flow in a function is tedious.
Better to just always initialise them to a safe value.
In particular, in these cases, a precondition failure in the function
would have caused the free function to be called on undefined memory,
which would have turned a potentially-graceful error recovery into a
crash.
Spotted by building with `-Werror=maybe-uninitialized`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
