Re: icon naming spec and gnome-vfs

[Shaun McCance <shaunm gnome org>]

On Sat, 2006-08-05 at 01:45 +0100, Bastien Nocera wrote:
> On Sat, 2006-08-05 at 02:40 +0200, Jakub Steiner wrote:
> > On Wed, 2006-08-02 at 17:26 +0200, Steve Fr�naux wrote:
> > 
> > > Not to forget us. C, python, ruby, perl and bash files having the same
> > > icon is not really kind while working on a project. Same for other files
> > > like Makefiles and in-files...
> > 
> > And don't forget musicians, who really like to know if a file is in a
> > lossy format such as mp3 or lossless such as flac. 
> > 
> > Let's see where this chain ends...
> 
> <Insert comment about video container formats>
> <Insert other comment about video codecs inside the containers>
> 
> Could go pretty far :)

I hate to be the one to say this, because it sounds
all negative.  But isn't it our job to provide what
our users need?  Even if it's "hard" or it "requires
lots of work".  I mean, isn't that what we ought to
be doing?

Now, it's been rather a bitch supporting DocBook and
man and info.  None of them are all that easy, and
there aren't really any suitable pre-built toolchains
for any of them.  So at some point, I removed man and
info (the idea was temporarily, but the fact is they
disappeared), and the reason was mostly that it was
too damn much work.

That was a mistake.  I got lots of shit, deservedly
so, because I removed something that many users were
really relying on.  I screwed their desktops, and I
won't make that mistake again.

If making things work is hard on developers (and by
developers, I mean everybody who makes our software
kick ass, including artists), then by all means we
should look at how to make developers' jobs easier.
After all, removing barriers helps us make better
software.  But doing so by cutting features doesn't
help us make *better* software.  It just helps us
make less-useful software more easily.

Sorry if this came off rantish or unappreciative.

--
Shaun