Re: [Nautilus-list] preferences

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]