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>
So that we have an API for adding subpages that are build-conditional.
For example, CcPrivacy.bolt_page and CcPrivacy.location_page.
Normal static subpages should be statically defined in the respective
CcPanel .ui file.
So that hub panels can dynamically query what's been shown, since they
lost control over the navigation directly.
This is useful in Privacy, for example, where we check for the current
visible subpage to decide which documentation page to show.
When CcPanel.subpage is set it also now will check for the existence of
the subpage and handle its presenting itself.
This way hub panels will no longer need to do any static subpage
handling. (e.g. connecting to the "subpage" property).
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".
So that CcPanel implementations have a method to add their subpages to
the builtin CcPanel.navigation.
Hub panels like System and Privacy have their main landing page composed
in an AdwNavigationPage. Therefore we overwrite the CcPanel.child setter
to add these pages to CcPanel.navigation instead of overwriting
CcPanel.child like we do for all the other panels.
So that in the future panels with subpages don't need to have their own
navigation views.
As of now this is useless as implementations of CcPanel will reset the
CcPanel.child object.
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>
