Re: Having external control panels in System settings

[Federico Mena Quintero <federico gnome org>]

On Tue, 2012-01-24 at 13:16 +0000, Bastien Nocera wrote:

> And making it useful for people also means that we don't want random
> crap in the control-center that muddles the UI, and makes it less useful
> for people. We, GNOME System Settings developers and designers, have a
> big picture view that the writers of separate panels won't have.

I completely understand the sentiment behind this.  The current design
is really very nice - I saw all the work that went into making things
consistent and with as few panels as possible, and it's just top-notch
work.

The big picture view that you mention needs to be communicated to
external users, so that they can see the thinking behind the control
center's philosophy.  It's not a dumping ground for options; the wiki
page you linked ( https://live.gnome.org/Design/SystemSettings/ ) makes
it very clear that the control center is for settings that don't have
the context of an application.  We can communicate this philosophy in
the API docs, in the headers for the public API, etc.

One recurring pattern in Gnome is that downstreams implement the missing
bits they see lacking in Gnome; then they figure out that they have
implementations for similar things, and an effort gets made to
merge/upstream them.  The way to make that as easy as possible is by
having a well-documented and reasonably stable API - instead of pulling
out patches from disparate "gnome-control-center" packages, you can just
look at some nicely isolated plugins.

These two commits turned the public libcontrol-center into an internal
thing:

27c45abda - Moves cc-panel.[ch] and cc-shell.[ch] into shell/
6665b6042 - Tweaks #include paths in all the panels

Apart from changes made since then, it should be easy to revert the
effect of these commits and to make libcontrol-center public.  The first
commit mentions a problem with CcEditableEntry not being registered on
time - this can likely be solved by calling an appropriate
cc_editable_entry_get_type() function before the plugins are loaded.

The API is simple enough:

CcPanel - basically "here is a CcShell and an argv; give me back a
widget to embed in the shell".

CcShell - Give me the shell's toplevel widget for when GTK+ needs it.
Switch the shell to showing another panel (e.g. let the a11y panel
switch to the keyboard panel).  Have this other widget and embed it in
the shell's header.

CcShell is the parent class for GnomeControlCenter, which is the actual
visible shell.  None of the panels use the gnome_control_center_*()
functions, just the cc_shell_*() ones.  I don't know the purpose of
this; it's probably so that others can implement their own shells and
still reuse the machinery for individual panels.  I'm ambivalent to this
possibilty - the default shell seems generally good, but I can imagine
special environments needing a different shell (small screens?  who
knows).

[recommending that apps don't install random crap in the control center]
> We did that, and they still did. When we shipped with external control
> panels enabled. For one release.

Have some healthy contempt for them - it's *their* problem :)

  Federico