- From: Havoc Pennington <hp redhat com>
- To: nautilus-list eazel com
- Subject: [Nautilus-list] preferences
- Date: 17 Aug 2001 23:19:49 -0400
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
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?
- 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.
- 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
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 ->
- /apps/nautilus/visibility/apps/nautilus/preferences/foo ->
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?
/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
But, I prefer the first option, just take it out.
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
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.
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.
] [Thread Prev