Re: [Nautilus-list] preferences

[Ramiro Estrugo <ramiro fateware com>]

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

I would simply rather do completely away with these dynamic defaults.
Im happy to hear this is not an issue in the RH branch.  How is that ?
The ideal of a "dynamic default" is in a way an oxymoron and confusing
anyway.

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

Yes.  As a first step to making things better we can fix this by using
schemas for the default values.

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

Ill give it a crack soon.

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

Good luck!

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

I think a good strategy would be to reduce this set of 6 special
preferences to 0.

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

Exactly.

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

This is probably the most important part of the user level system.  The
idea that the beginner user level has preferences that cannot be altered
and will always remain at a "stable" value is very important.  Thats not
to say the higher levels can be a dumping ground for "unstable" stuff. 
By unstable I dont mean values that cause core dumps, but rather values
that increase the complexity of things.

> 
> I'm all for keeping the current eel-preferences.h abstraction layer,
> to handle the details of this stuff.

Yes.  This is a huge benefit.  Regardless of what happens to the
implementation details in eel-preferences, Nautilus wont have to change
at all.

> Havoc


So I think we are in agreement to proceed as follows:

Immediately:
1) Deal with the gross innefeciences.
   a) Use schemas for defaults values
   b) Dont use gconf for visibilities.  Use the already existing table
in each nautilus process.
   These 2 should cut down the startup hit from whatever it is now to 0.

Short term:
2) Reduce the number of special preferences
   a) Exorcise the ones that have dynamic defaults

Long term:
3) The important part of the user level system moves to gconf directly
   a) Visiblities are stored in the gconf schemas.
      GConf has an api for querying these.

   b) GConf itself does the work of filtering value changes and
notificiations through visibilities.
      All get_value_() operations take into acount the visiblity of a
preference and always return the non changeable default for level less
than or equal to the current user level.

   c) You can specify up to 2 default values in the gconf schema.  One
for the invisible level and one for the next level up.

b) and c) are not necessarily coupled.  I think it wouldnt be tragic if
we didnt have c)  I think b) is the must have feature though.  It would
work just fine if there was only 1 default as well.  Perhaps thats a
good compromise since its fairly simple while keeping the most important
part of the current user level system.

-re




  

Visibilities are stored in the gconf schema directly and gconf has an
api for querying it.