Re: [Nautilus-list] preferences

[Maciej Stachowiak <mjs noisehavoc org>]

On 17Aug2001 11:19PM (-0400), 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.


Hi Havoc,

It used to be we stored different values per user level and not just
different defaults per user level. I bet much of what you see is
relics of that era which did not get cleaned up.

 
> 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

It used to be only Expert users got shown dotfiles by default (and
perhaps other things).
 
> 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.

If you'd like to implement a user level concept in GConf, we'd love to
use it in Nautilus instead of our own thing. But I don't think we
necessarily want to remove the features based on user levels while
waiting for it. I guess the final call is up to Darin though.
 
> 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?

Wouldn't blowing away the visibility stuff make all settings visible
at all user levels? That would be tantamount to removing the user
level feature entirely. If there were good usability reasons to do
that sure, but I don't think purity of the gconf database is a good
enough reason.

But I for one would love to see any cleanup of the prefs code that
maintains the current feature set.

 - Maciej