Re: Proposal: gnome-user-share

[Alan Cox <alan lxorguk ukuu org uk>]

On Sul, 2004-12-05 at 17:39, Havoc Pennington wrote:
> Absolutely not. The same was true for 3.1->95, 95->98, and 98->XP.

Things as drastic as filenaming are consistent except for some of the
magic stuff and that was done in a way most apps just work. The only bad
naming breakage is the DOS box 8.3 mapping, which unlike gnome-terminal
is kind of useless so nobody cares.

> they are generally content. They know on some level that they have
> unique requirements. They did not get upset about .directory files
> either.

Things like ".directory " files don't break badly on people. It's
invisible to apps that don't care. ls doesn't show me different gnome
magic for gnome file types and labels. It could if we had an fdo library
but the failure case is not problematic.

Having two apps disagree where my files are is pretty catastrophic. 

> All that said, I do not believe your point applies to this particular
> design decision because I don't think display names really break shell
> users in any significant way. No more so than .directory files when we
> had those. Or .desktop files which we still have; try browsing
> to /usr/share/applications in nautilus.

Thats because you live in a mono-lingual English language world, or at
least appear too.

> Here's another analogy: the kernel is designed for as broad a set of
> applications as possible, but at some point the tradeoffs become
> fundamental. You can't be both tuned for embedded realtime and for big
> iron mainframe. You do your best to accommodate both of those, but the
> design and the defaults really are not *optimal* for everyone at once.

The same kernel source tree builds an optimal result for both. That's a
slightly easier challenge than the run time gnome configuration. There
are areas below which it doesn't fit well yes but there are other OS's
that do it better just like Xfce can replace most of the gnome desktop
on a smaller box.

> It's exactly the same for the desktop. We broaden the appeal until it
> breaks, then we say "tweak these custom config options," then we say
> "patch the source code," 

You have to interoperate and things like magic renaming leak everywhere
and perform badly. It actually degrades worse than just having a gconf
key and a couple of script helpers or environment variables. Its not
perfect either.

Thats the biggest problem I have with this - you are (IMHO anyway)
digging a large trench that will have to be filled in again if you take
this hack approach. 

Alan