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.
Instead of just sorting by the name the sort order will now be:
1. Panels whose name match a search term
2. Panels whose keywords match the most search terms
3. Panels whose description match the most search terms
4. The remaining panels by name
https://bugzilla.gnome.org/show_bug.cgi?id=729027
- set "All Settings" as title of the headerbar
(in the overview page)
- set the name of the each panel as title of the headerbar
- remove "hide-titlebar-when-maximizes" property
- add separator and close button to the headerbar
(set "show-close-button" property as true)
https://bugzilla.gnome.org/show_bug.cgi?id=704217
