Re: [Nautilus-list] preferences

[Darin Adler <darin bentspoon com>]

On Saturday, August 18, 2001, at 04:19  PM, Havoc Pennington wrote:

> Anyhow, I'll give it a rest, and try to come up with a patch in the
> next few weeks. No doubt new solutions will become apparent during the
> hacking process.
First, I should note that this is the classic problem of building systems 
from the bottom up. GConf is built first, then we design the UI, and we 
discover that it doesn't have the features we need to build the UI we want.
 We can debate all we want about whether the user level feature we 
implemented is good or bad, but the fact is we had to build more features 
on top of GConf and that's why we made this mess.
It would be great to make the layer between Nautilus preferences code and 
GConf be thinner. For places where we want the beginner default and the 
expert default to be different, I think there's a simple hack that could 
keep the user experience the same and make things still be pretty nice for 
admins using GConf. Maybe we can use an extra enum value that means 
"appropriate default for user level" and have that be the default, and 
readers of these preferences would just use a cover that takes care of 
mapping this. This might work for all 6 of the spots -- I'm not really 
sure. A little hacking in Nautilus preference code would be needed, and 
there would be no UI way to get back to this "appropriate default for user 
level" setting, but I think it could be a clean solution.
Or you could use Ramiro's proposed defaults for those 6 items. I'm not 
sure I agree with some of his calls on those, but frankly we lost the 
people who were thinking about the fine tuning of such things with Eazel's 
demise so the Nautilus team is now easily convinced about such things.
I personally am not as happy as Ramiro is about having the 
NautilusPreferences level between us and GConf. It does have the nice 
effect of reducing Nautilus dependencies on GConf, leaving us with only 
one place to change, but it has the other effect of introducing yet 
another API. It's a way to make Nautilus safer from changes to underlying 
libraries, but I don't think we need that kind of safety net. But it's a 
little too late for me to complain about this now.
On the other hand, the layer was absolutely required to make the user 
level feature work. I also love how Ramiro made the preferences dialog UI 
work automatically, but somehow I still suspect this could have been done 
without wrapping GConf as much. I'm not sure that the user level feature 
was a total failure, and I have mixed feelings about the (implicit in this 
discussion) possibility of just removing it altogether. It's true that if 
you remove all of the "crackrock UI" then you probably don't need user 
levels as much, but can you ever do that? Andy has more understanding of 
the importance of the user level concept than I do, I think.
I think we have too many of these additional layers in Nautilus code 
though. For example, I'd rather have functions that work on GLists of 
strdup'd strings rather than the EelStringList class. I think this is all 
part of my "when in GNOME, program as the GNOMERs do" philosophy. I'd like 
to remove code that's not pulling its weight.
Continuing to get way off topic, I also really wish we hadn't ended up 
with a Nautilus coding style that is different from the style for other 
projects. I would much rather have a style that exactly matched the style 
of gtk or of bonobo, but instead we have something idiosyncratically 
different from either! (As Michael Meeks is constantly reminding me.)
    -- Darin