Re: [Nautilus-list] preferences

[Ramiro Estrugo <ramiro fateware com>]

Havoc,

The complication we discuss below is a result of the user level system. 
There are a lot of details to get right to support the user level system
as currently specified.  Either Darin or Sullivan posted a good
description of the user level system on this list not long ago.

I agree that some of the implementation details are not the most ideal
or effecient.  I also agree that in many cases our use of gconf is
abusive.

Havoc Pennington wrote:
> 
> 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?
> 

Some of the defaults cant be hard coded.  For example, the "home
location uri" preference is dynamically set depending on $HOME.  Also I
spent a bit of time trying to get schemas to work and couldnt figure it
out, probably just me being lame.  I think for the case of default
values (up to 2 different defaults values are possible given the user
level system) and visibilities, it would be possible to use schemes. 
However, youll have to invent a variable system for things like "home
location uri."  Storing $HOME in the preference and decoding that ??  I
dunno.

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

What do you mean "values we already have" ?  Values we already have in
the Nautilus preference table ?  Or values stored by the user ?

> 
>  - 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.

For convenience.  I agree its not effecient.  I timed it once and it was
a small amount of time that didnt make a big difference.  Yes, I know
that attitude is the source of evil.   We could totally do away with
that startup hit by using schemas if someone makes that work.

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

The nautilus preferences can deal with more than just stuff in the
"/apps/nautilus" namespace.  For example, /system/gnome-vfs/proxy*

So, the "user level defaults according to the nautilus user level
system" for *any* gconf path are stored in
/apps/nautilus/defaults/$user_level/   I agree its a little whacky.

> 
>  - 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.

All of this is needed because we dont really use the gconf
notifications.  A gconf preference could change and not affect a
Nautilus preference.  Again, because of the user level system, a simple
user level change could trigger a nautilus preference change because the
defaults are different in the old/new user levels.

> 
> 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?

I never expected that sysadmins would want to change these.  As I say
below, it was a mistake to store this information in gconf.

> 
>    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.
> 

Well, its not just that.  The defaults are not only given for up to 2
user levels, but are read only for levels on which they are not
visible.  So even if we did away with the multiple defaults, we would
have to deal with visibilities.  We would still need to maintain a list
of prefernece visibilities and filter gconf changes through that.  

Also, you say that its not a big deal to just use the beginner default
for all things.  Unfortunately that is not the case.  We had many
instances where someone would hack up an excellent feature for Nautilus
that was deemed innapropiate for the beginner user level, however we
still desired to make it available "by default" at some higher user
level.  Anyway, the point is that its very difficult to get consensus on
what the defaults should be.  The current system of allowing multiple
defaults allows totalitarion control by the usability czar at the
beginner user level, while allowing for experimentation and compromise
at a higher level.

> 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
> 

In these last paragraphs you are basically arguing for dropping the
Nautilus user level system.  The 2 most fundamental parts of the
Nautilus user level system are 

1) A preference has the same changeable value at all the user levels at
which it is visible.
2) A preference has a fixed non changeable value at all the user levels
at which it is not visible.

In order to support that, the default values for up to 2 user levels
need to be stored somewhere along with the preference visibility.  I
used gconf for this because it was convenient.  I know realize that was
a bad decision.  Storing them in a hash table in Nautilus might have
been better.  We had many many iterations of the Nautilus user level
system, and it was a significant amount of work to just make it work.

I believe if we solve the dumb problem of dealing with $HOME (and maybe
others I cant recall - i18n font issues maybe??) we can use schemas to
avoid the inefficient setting of these at startup.

I have no good answer for the issue of ruining sys admins lives.  To be
really honest, that didn't really factor into the picture when we were
working on it.

Finally, the whole user level system was an experiment to see how we
could deal with the contradictory requirements that Nautilus be
something usable by beginners while also being attractive to hackers.

I don't know that there is conclusive evidence that it achieves these
goals.  I completely agree with you that its a complicated system and
the cost of maintaining it is high.

Maybe we should concentrate on removing the current gross innefeciencies
in the system and expect that visibility and per user level defaults
would be available in gconf itself in the future and eventually dropped
from Nautilus.

I dont think that all of the details of the current user level system
need to necceserily be present in gconf.  A lot of these are subtle
things that only surface when you actually try the stuff.  For example,
one thing that we found was that changing user levels was expensive
because of a torrent of notifications that occurred.  Yet, the logical
value of the preference was not changing.  So we had to store the
logical value in a table and compare it with the new logical value. 
When I say logical value, i mean, something that takes into account a)
the current user level, b) the visibility  and c) the users chosen value
- which is applicable only if b) is less than or equal to a)

-re