With the new sidebar view in place, a new problem arose: we
need the current panel to be configured to update the title,
but cc_panel_list_add_sidebar_widget() changes the view while
activating the panel. That makes Settings crash.
Fix that by explicitly updating the headerbar widget, instead
of using notify::view of the panel list.
Instead of directly selecting the view that the panel
list will have, let it decide which is the previous
view instead.
This does not change anything functionality wise, but
in the future where we have sidebar widget (and thus
the main window does not control which view the sidebar
is display) this will be important.
It will be used by the next commits to look for the panel
name. That is because the panel name is what will be used
as the first headerbar title of panels with a sidebar widget.
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.
Panel icons should be consistent between the app and corresponding
search results in GNOME Shell, but currently the former uses the
symbolic variant while the latter uses the colored version.
Address this by converting icons to their symbolic variants when
building the model rather than later when consuming them.
https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/151
Whenever a panel is activated, there is a GtkBox that
is added between the window and the panel itself.
Investigating the history of this field, it originally
appeared at ec7f8c9b when the window started using
widgets rather than page numbers. Apparently, it was a
GtkBox to help dealing with the GtkNotebook (which was
later changed to the current GtkStack).
The field was renamed from 'current_panel' to 'current_panel_box'
at ab435aa9. But since the transition to GtkStack, there
is no real need to use the GtkBox anymore.
This patch removes this GtkBox, and as a consequence, the
code is slightly simplified.
The correct time to remove custom widgets is precisely
after we checked if the panel can be activated, and before
creating the panel. We were not following that, and it was
causing the panels with header widgets to never actually
show their custom widgets.
Fix that by calling remove_all_custom_widgets() at the
correct point in panel creation.
When changing panels, CcWindow can only remove the previous
panel's header widgets after making sure the new panel was
successfully set.
However, this is not the case, and when the current panel
fails to be set, the previous panel's header widget is
removed.
Fix that by waiting to remove the header widgets until the
panel is successfully set.
This field can be used to communicate the visibility of the
panel from a static context (i.e. without any instances of
a CcPanel nor any access to CcShell).
In order be able to modify panel information statically,
we need to have access to the CcShellModel from static
functions. CcApplication, thus, is a better place for the
model to live, since we can access it outside any scope
using g_application_get_default().
It also makes sense from the modeling point of view, since
the model is not tied to the shell anymore.
This never really worked on the new Setting layout
because it was historically implemented as "Back to
Overview", and we don't have an overview anymore.
This is fixed by morphing the implementation to be
"Back to previous panel", which forces us to actually
store the previous panel.
There is no overview anymore -- Settings is always
visualizing a panel at any given time.
I just noticed that the Alt+Left shortcut was always
broken too. This will be fixed in a following commit.
With this commit, a message dialog pops up whenever a
development build runs. This is meant to actually annoy,
so that we're always reminded that things may not work
as expected.
Since the dialog can be dismissed with a single button
press, it is not the end of the world. But people still
should be aware that Settings is ~not~ meant to run with
Flatpak, and that this is a development tool only.
When selecting the panel on startup based on the "last-panel" settings,
we need to make sure that the panel exists.
Note that this is a special case which does not use the internal
set_active_panel_from_id API. Using it is currently not possible because
the API does not report back the error and we would end up not selecting
any panel.
The helper function to get the icon name from a GIcon directly
returns the symbolic icon now. This makes it in turn possible
to also directly check if the theme has the icon with the symbolic
name instead of checking of for the full colored one and then
deriving the symbolic name from that. The latter (old) practice
will fail if there is a symbolic icon in the theme that has no
full color icon (like e.g. thunderbolt).
These were only used by CcApplication, and at this level
of the program we don't need to use any wrapper functions,
since we're certain that the CcWindow is a GtkWindow subclass.
There were leftover UI declarations in the source code, breaking
the nice split that it having the UI declared in the GtkBuilder
file while the logic is programmed.
This commit moves the remaining widgets declared in the source
code, the connected signals using and the binded properties to
the GtkBuilder file. This led to a nice cleanup in the source
code.
In an attempt to make the CcWindow code more organized and
structured, this commit reorganizes the source code to match
a recent pattern:
* Structure declarations, G_DEFINE_TYPE
* Function prototypes
* Auxiliary methods
* Callbacks
* Vfunc overrides
* class_init() + init()
* Public API
In practice, this is never uninitialized, but the
compiler is complaining anyway, so let's play the
conservative and make sure it's always initialized
to NULL.
It looks better to present the fallback app menu in the headerbar
instead.
This change assumes that client side decorations will be available,
and therefore a GtkHeaderBar.
https://bugzilla.gnome.org/show_bug.cgi?id=786692
When application menus are not supported by the desktop environment
or are disabled, Gtk+ makes the menu available with a fallback. For
client-side decorations the fallback consists of adding a menu
button at the begining of the titlebar. Since g-c-c has a split
headerbar, we need to explicitly handle the decoration layout.
This commit forces the "menu" to belong to the left headerbar, and
leaves the other buttons to ble placed at the right headerbar.
The "show-close-button" property has to be set in order to present
any type of decoration buttons in the header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=786692
Instead of using a callback on size-allocate, and setting
a custom size request. Using a sizegroup is much cleaner
and avoid some potential issues we could have in the future.
When passing --overview, Settings' new shell window accidentally
removes the newly selected panel.
We're considering the possibility of adding an overview page but,
since that won't happen for the next release, let's just make sure
something happens for now.
Fix that by simply changing the panel list view, which selects the
Wi-Fi panel if the user was in another view.
https://bugzilla.gnome.org/show_bug.cgi?id=786117
This commit updates the code to use the recently
introduced API. The new functions improve the
legibility and maintainability of the code, and
makes it easier to work on new features.
https://bugzilla.gnome.org/show_bug.cgi?id=766922
When using the small mode, and the scroll window's content
height is smaller than the screen, we'd end up with whitespace at the
bottom of the panel, as the panel's height is smaller than the window.
