A `GType` is not an integer, but either `size_t` or `uintptr_t`. So
casting it to int might lose bits of info, resulting in an invalid
`GType`.
Fixes#3062
The `set_subpage()` function already has good error checking for valid
tags, so reuse that for the `navigation.push` action callback.
Note that this likely won't fix#3062, as there the tag must exist in
the hashtable, as `g_object_new()` won't crash if you pass `NULL` to it.
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).
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.
We need to cancel internal operations before starting to create a new
panel, otherwise panels might be creating the same object for the cache
in parallel and this is not supported by the object cache.
The alternative to this would be to handle this inside the object
store to allow parallel creation of the same key.
Fixes: #1685
Rename the app-id to org.gnome.Settings since this is what
we've been calling it for many years now. Adjust all files
that derive from the app-id, such as the desktop file, D-Bus
service file names, search providers, GSettings schemas, to
match that.
Closes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/344
Make CcPanel override GtkBuildable, and special-case two types
of children: "content" for the main content, and "titlebar" for
the titlebar. Those two child types exist merely for convenience,
since it's still possible to override the entire panel with
adw_bin_set_child().
For now, no panel is using any of these conveniences.
Make the panel class provide a cancellable that will be cancelled when the panel
is destroyed. Panel implementations can use this and not have to mangage the
cancellable themselves. Consolidate cases where panels had multiple cancellables
that were all being used for this behaviour.
This is necessary for the application panel to warn that an element of
its sidebar has been activated so the window can focus on it when the
window will use a leaflet.
This vfunc is the entry point for panels that have
a sidebar widget. It must never return NULL.
At this point, nothing uses it and this vfunc does
not impact execution of the program.
These overrides were added eight years ago, as a port from
GTK3's size_request() deprecation, in commit f5f5aac5c0.
These overrides are not necessary these days, since they
just reproduce the default behavior now.
Remove these overrides then.
Only the date time panel used it, all other panels add their own shell using
cc_shell_embed_widget_in_header which was added after the date time panel was
written. Update the date time panel to use this method.
So the panel implementations will be able to set a custom widget
in the shell headerbar. It defaults to NULL, so by default panels
set the plain label with the panel title.
This reverts commit 31a8a99440.
This was meant for bgo#695885 which has stalled for a while, so this
feature has no in-tree user. This commit removes it for now, this can be
readded when users for it materialize.
https://bugzilla.gnome.org/show_bug.cgi?id=751597
Add a class method to CcPanel to get a GOptionGroup which will be added
to the main commandline parser. This gives panels the chance to have
commandline "--flags" in addition to the already available parameters.
This changes changes the way parameters are passed to panels: the first
entry in the GVariant array is always the a{sv} dictionary of
commandline flags, followed by the remaining free-form arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=696054
By using a GVariant of type "av" we can potentially pass more structured
data to panels, which will become relevant with the ability to invoke
them by GAction-based DBus-activation introduced in the following patch.
https://bugzilla.gnome.org/show_bug.cgi?id=696054
When re-activating the same panel, we could destroy and recreate the
panel, or better reuse the panel, and set the new argv
(usually to switch pages).
Since we're changing the "argv" property of panels to not be construct-
only anymore, we reviewed the panels for potential memory leaks as well.
https://bugzilla.gnome.org/show_bug.cgi?id=684490
This fixes problems with the CcEditableEntry type not being
registered and causing the printers and user-accounts panels not to
work. As we do not need to work on Windows, we do not need to split
out the library.
2011-11-07 18:03:14 +00:00
Renamed from libgnome-control-center/cc-panel.c (Browse further)
