[Nautilus-list] preferences

[Havoc Pennington <hp redhat com>]

Hi,

I'm doing a lot of "doh" while reading the nautilus prefs code. It's
showing up as taking a _lot_ of time in the startup profile.

Looking at it, apparently on startup, Nautilus takes the default for
each setting, and sets it somewhere else in the gconf database. So for
example, /apps/nautilus/defaults/novice/apps/nautilus/preferences
contains a bunch of defaults for novice userlevel, AFAICT these are
set on every startup. Hrm, actually we do even better and also set a
"visibility" key for each pref.

Before I start in with a massive deletion-fest, I want to understand
all the issues.

Is there any rational reason for the following:

 - why are the defaults hardcoded instead of in schema files?

 - if we are going to hardcode, why do we stick the defaults in the
   database, rather than just using the values we already have?

 - alternatively, if we are going to stick the defaults in the
   database, why do we overwrite them on each startup? The only 
   reason I can see to put them in the database is to let 
   people change the defaults.

 - "/apps/nautilus/defaults/novice/apps/nautilus/foo"
     instead of
   "/apps/nautilus/defaults/novice/foo"
   ?

 - if we are going to set all these defaults, is there a reason we 
   first subscribe to receive notification of changes to each of them?

 - repeat most of the above questions for the visibility keys?

Basically each preference in nautilus-global-preferences.c results in
at least two (sometimes a few more) round trips blocking on gconfd in
a recursive main loop, then we later get several notifications from
gconfd about keys we've changed. So we're talking about some pretty
insane inefficiency.

Let me try to outline how I would rearrange all this for stable
branch. For the hyphothetical key preferences/foo:

 - /apps/nautilus/defaults/novice/apps/nautilus/preferences/foo ->
   destroyed.

 - /apps/nautilus/visibility/apps/nautilus/preferences/foo ->
   removed. 

   I can see that it's maybe useful sometimes, but I just don't see
   many sysadmins changing which user level a setting appears in. It
   doesn't seem worth the complexity to me. Let's just hardcode
   it. How would a sysadmin have more insight than GNOME does? Are
   sysadmins going to do their own user testing?

   Alternatively:

   /apps/nautilus/visibility/apps/nautilus/preferences/foo -> renamed
   /apps/nautilus/visibility/preferences/foo, this is more efficient
   at runtime and less annoying when using a tool like gconftool or
   GUI equivalent.  Default visibilities are stored in schemas, which
   are installed at 'make install' time. We don't hardcode
   visibilities, except for fallback values used if gconf returns NULL
   for one of them.  We don't set all these visibility keys on
   startup.

   But, I prefer the first option, just take it out.

 - /apps/nautilus/preferences/foo 

   Default value stored in schema files. There is one default for all
   user levels. If there's a default in the Nautilus code, it's a
   last-resort fallback if GConf returns NULL.

I expect that the whole /apps/nautilus/defaults mess is motivated by 
the desire to have different defaults per-user-level. So let me argue
this for a moment. 

This feature is used for 6 preferences out of 61 in
nautilus-global-preferences.c:

 a) we don't show directory item counts over ftp for beginners, 
    because it's slow. comment in code says if it were fast 
    we'd show it for everyone

 b) advanced users see more in the file props dialog (setgid, etc.)

 c) beginners can't add images etc. to the property browser

 d) beginners get a simpler search bar

 e) beginners used to get a different default home location, 
    I destroyed ~/Nautilus in our branch though, so if this patch 
    is merged everyone will get just ~/

 f) beginners don't get the tree view sidebar

My view is that it would not be a big deal to just use the beginner
default for all these things. If we want per-user-level defaults,
let's add some feature to GConf for that, so we can use it
consistently across the desktop.

The per-user-level defaults are mildly nice, but I don't think they
outweigh the wheel reinvention and inconsistency introduced by their
implementation. Remember that sysadmins, programmers, and advanced
users are exposed to GConf as an interface; this is not purely
implementation-detail cruft. It should be nice and maintainable and
consistent. The current setup would look like nonsense in a nice GConf
GUI such as the one Sun has prototyped.

There should be no problem adding visibility and per-user-level
defaults to GConf for GNOME 2 or 2.2 or whatever. Then we can fill in
the values for those fields in the schema file.

However in the meantime, I think Keep It Consistent, KISS, and Don't
Fight The System - let's make it efficient, consistent, and easy to
maintain by just blowing away the visibility and defaults stuff.

Thoughts?

Havoc