Arora Configuration System Proposal

Introduction

First, I'd like to show you two mock-ups that I've created so you get
a feel at where I am going.

Here's the first screenshot where I used colors for each individual
section:

And here's another with the same colour for each section:

Every webbrowser has a multitude of configuration settings. Some of
them should be easily accessible by the user and some of them are for
fine-tuning and usually only the defaults should be used. There are
settings of different complexity that require different degrees of
prior (technical) knowledge. For example, an easy setting that every
user should understand is "Restore window position and size when
starting". This is just a simple checkbox in the settings dialog that
a user can either check or not check . A far more complex setting
would be a default stylesheet that should be applied to all web-pages.
First, creating such a stylesheet requires technical knowledge and
second the implications of providing such a stylesheet is not very
easy to understand.

Suggestions

My opinion is that there should be a settings-dialog that is
convenient and includes just the settings that Arora chose to be
accessible to the normal user. For advanced users, there is a
about:config page which includes all settings. But the about:config
should be nothing like Firefox's about:config. Firefox's config-page
is only for hackers and lacks usability. Here's how I'd imagine
Arora's about:config:

First of all, Opera has a nice config-page which we can base on.
You can see a screenshot here:

Navigate to opera:config and you can see it. It consists of many
sections which can be opened and closed. Every section includes
multiple settings, which sometimes have custom editors. The editors,
however, are not as convenient as they could be. For example, to enter
a color, you have to type in the hexadecimal color-value instead of
using a color-picker dialog. Every section includes a "Save" and
"Abort" button, which is very reasonable. If there was no explicit way
to save, you'd have to save after every change of the setting. And
saving often means rebuilding or redrawing something, which can be
quite annoying when just changing one simple value.

Opera has meaningful captions of each setting, too. Firefox, on the
other side, only displays the internal setting-name (which often is
quite verbose, but not as good as Opera's captions). What even Opera
is missing, though, is a description of a setting. I find that very
important, although it is, of course, very much work.

A search-functionality is also present. It even behaves awesome. If
an item in section matches, the section is displayed. Inside the
section only matching items are displayed. This way you get to the
settings you're looking for quite quickly. I think, additionally, the
config-page could include some more filters. Something like filters to
show only users or experts settings. With these filters, the
config-page could even fully replace the settings-dialog. IMHO, this
would be really cool. But again, I think the settings-dialog can
provide a much more optimized display and user interface than an
automatically created config-page ever could, so we should keep a
separate dialog that's hand-coded.

There are settings that are added to the system on-the-fly. For
example, extensions should be able to add settings and have them
displayed in the about-page like any other setting.

Implementation

To sum up which information is needed on each configuration option
that is available, it comes down to this:

• Category


• Internal name


• Display name


• Type or Class


• Editor (optional)


• Value-constraints (optional)


• Short, meaningful description


• Default value


• Flags

The Flags can be used to mark a setting as "For Experts", for example.
In the next chapter I'll discuss another usage of a flag that a
setting could have.

A Class is a combination of Type, Editor and Constraints. The
Editor and Constraints can still be overwritten when using a Class,
though.

A category, in turn, needs some more information than it's bare name,
too.

• Internal name


• Display name


• Icon (optional)


• Color


• Meaningful description, may be a bit longer

To make the config-page visually appealing and to easily find
regularly visited options, a category should have a special color. You
can see that this looks good in the mockup I provided.

With these informations, it should be relatively straight-forward
to implement some settings-classes to read and write settings and to
create the config-page.

Reading settings should be as easy as

Settings::Download::Style style = readSetting<Settings::Download::Style>("Download.DownladStyle");

Writing, however, should always occur in a group. Hence there should
be a class SettingsWriter that can be used to write settings. When the
object runs out of scope, it flushes all the changes that have been
made.

SettingsWriter writer;
writer.set("Download.DefaultDirectory","/home/user/downloads");
writer.set("Download.DownloadStyle",Settings::Download::AlwaysUseDefaultDir);

If this proposal is accepted, I will work out some class-prototypes
for further discussion.

Dreams come true

To have an absolutely awesome and really magnificent
settings-system, you could think about automatically storing chosen
settings online. For example, the tab-behaviour usually should not
change no matter from where you are browsing. And now imagine that
certain settings that are marked as shared are stored on your
online-profile and automatically loaded when using Arora from a
different box with the same profile. This online-profile should, of
course, include bookmarks and history, too. Because those are more
sensitive than settings are, they are of course optional.