Re: Gnome-vfs blocks cddb-capplet. Why?

[Seth Nickell <snickell stanford edu>]

On Sun, 2002-04-21 at 17:54, iain wrote:
> 
> > 
> >   - It's not a desktop setting. If I wanted to change 
> >     where information about CDs was obtained, I'd look 
> >     in the properties for the various CD player gadgets,
> >     not in Desktop Preferences.
> 
> See, this is what seth complained about and this I think is the crux of
> the matter. However, I disagree that it is not a desktop setting.

So you as maintainer disagreed with the usability person and decided to
do it your way (within your power as maintainer of course). And I as
maintainer disagreed, and did what was in my power to return the
universe to usability (or perhaps, you are free to argue, my warped
conception thereof). In the end, my module was at a lower level. Whee. I
love this system[1].

I want to apologize for this though, it was cowardly and rude. I should
have at least had the courtesy to tell you what I was doing. I genuinely
hope you did not have to waste time debugging why your capplet wasn't
showing up.

> It is for a CDDBSlave process that has no other GUI[1]. Yes, each player
> program that uses it could implement the changes, but then we'd have the
> possibility of each application implementing it in a different way, one
> program would be "FreeDB properties", one might be "CDDB properties". 

Argh! This is a terribly implementor centered sort of view. Your process
is, in terms of technical implementation, a shared resource by all the
applications on the system that might theoretically used it. Programmers
like, for many good reasons, to think of the world in terms of 0, 1, and
n. More than one program can use your "daemon", so it is an 'n' use
case. So you make it very generic. Great! But only up to that point. 

Now here's the problem... You now take your internal design model and
push it into the interface. "hey, this could theoretically be used an
infinite number of places, so its a global preference, and global
preferences go in the control center". Except that real users think in
terms of "2", "3", "4" and "5" too. And the truth is that I don't think
there will often be more than 2 or 3 applications actively used by any
given user that would, even theoretically, use this module. 

A CD Player, a CD Ripper...maybe a CD applet (probably should share
*all* settings with the player, so not a good example in this case). In
this case it is not an infinite use preference at all, it has a few
distinct places it should show up. And when I want to change these
settings, I'm not going to look in the control center, I'm going to be
using the CD player and think "hm, FreeDB really sucks, I wanna sell out
to the man and use vanilla CDDB", and I'm going to go look in the CD
player preferences. Its kinder to me as the user if I can change this
preference without clicking a "launch CDDB properties" button, and this
effect is actually pretty easy to achieve technically with Bonobo[2]. 

To the user this is a *local* setting, even if it affects a few apps.
They don't think "I'm changing something across my whole desktop".
Contrast this with changing the "theme" or the "mouse" settings where
even to *users* it is sort of an "n" case (n to users is much smaller
than "infinity", it just means "pretty much everything I use"), i.e. its
a global change.

Luis alluded to the need for handling preferences that can be shared by
a few apps. I agree with him 100% that this is important. But the way to
do it is not to put capplets in the control center for each thing like
this, *particularly* not ones that deal with fairly obscure technical
features. It would be one thing to have a capplet for "Email" sorts of
preferences (address, mail server, maybe a few other simple
preferences), this is non-archane sorts of information. But even with
this, I would rather not put it in the control center as-is, I think we
should have a system for handling this sort of overlap. I have ideas,
but I'm not going to balloon an already long message dribbling on about
them.

> I
> look on it like the Default applications stuff, each application could
> implement "What browser is opened when a link is clicked", but instead
> we have one way to do it in the Preferences:/// stuff.

Heh, guess what? I'm looking to transition this capplet out of the
control center and to only provide the "what do I open this with"
preference locally. You're right though, it would be bad news if
everyone who wanted to provide this (evolution, galeon, nautilus,
probably some others) re-implemented the interface. It would be
confusing and inconsistent. So we'd probably use something like bonobo
for this in the future, or maybe just launch a document type editor for
that type (which is actually how the system currently behaves, at least
with nautilus, though it also shows up as a "global" capplet)

Making a good "CD Properties" dialogue that also has some very usable
CDDB settings (the current interface is rather overwhelming) seems like
another ok solution to me. The reason for this is that some CD
properties are desktop-y sorts of settings, and since we already have
the dialogue, there's minimal cost to slipping CDDB settings in there
too, and perhaps even useful.

"testing" the current interface to see people's reactions and adapting
in the future is not an option that sits happily with me. It is clear to
me now that this is a bad interface, and this seems like an excuse for
maintaining the capplet as is. If it turns into a CD Properties dialogue
somewhere within the usability range of the other control center
capplets (not that high a bar, but still a ways to go from the current
capplet) I'm happy to have it in the menus. I want to avoid hard
feelings by clarifying that as the capplet stands I will (try at least)
to hide it in the GNOME 2.0 release using GnomeVFS. I want to point out
that this does not cripple the feature, since I assume you have a button
for launching it directly from the apps in question anyway, and the
binary will still be on the disk, so from a user standpoint I don't even
think any features are lost.

-Seth

[1] This is sarcasm. I hate the maintainer system, I think its terribly
destructive to usability, but I'll use it where I can since I have to
live with all its negative effects.

[2] See! Bonobo can be really really useful.