Re: [Nautilus-list] preferences

[Havoc Pennington <hp redhat com>]

Hi,

Ramiro Estrugo <ramiro fateware com> writes: 
> 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.

I think what I'd do for $HOME is store the default as some sort of
magic string which gets filled in with "the default home." 
(Although this particular example is a non-issue in RH branch for now,
I recognize there's a more general problem.)

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

What I meant, is that you stick the defaults in gconf, but on startup
always overwrite whatever is in gconf, so it's just pointless to put
them in persistent storage at all.
 
> 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.

OK, I want to make it work. The current hit is 1 second or so on
Alex's test machine; 1 second is sort of buried in the overall slow
startup, but 1 second is also probably the ideal total startup time
(for everything Nautilus does). And we should be able to reduce
round-trips to gconfd to only 1 instead of 120+, just getting all the
entries in /apps/nautilus/preferences as a block in a single preload
request.

The Galeon guys found a cheesy bug in the schemas stuff that may have
been impacting you when you were fooling with it, and have schemas
working with Galeon now. So I'm pretty confident it is usable.
 
> 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.

I know I'm a fascist at heart, but I think GNOME could use a lot more
ruthless destruction of crackrock UI features. ;-)

I see the point you're making. At the same time, I see only 6 cases
where per-user-level defaults were used, and a couple of those already
obsolete, only a couple of them seem really interesting at all. So I'm
kind of thinking we could limp along without for a bit.

> In these last paragraphs you are basically arguing for dropping the
> Nautilus user level system. 

Well, I'm arguing to keep the visibilities, so beginners wouldn't see 
all the crazy options, and to just use beginner defaults. 

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

You're saying if I change a pref in Advanced, then go back to
Beginner, I get the beginner default for that pref back as my new
setting?

I didn't realize this, but I think it can still be mostly implemented;
we just get the GConf schema default (= beginner default) and use that
default instead of the current gconf value when a pref is not
currently visible. This is equivalent to how it works now, assuming
you have already removed per-user-level defaults. It is mildly wrong
from the sysadmin standpoint (the gconf schema default is the factory
default, not the local site default), but probably no one will notice.

I'm all for keeping the current eel-preferences.h abstraction layer,
to handle the details of this stuff.
  
> 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)

Right, at first I was thinking "why are they caching the gconf value
again, gconf-client already does?" but then I figured out what you
were up to there.

Havoc