Re: Translations of folder names - two proposals

On Mon, 13 Dec 2004 12:05:55 +0000, Jamie McCracken
<jamiemcc blueyonder co uk> wrote:
> On Mon, 2004-12-13 at 10:31 +0200, Kalle Vahlman wrote:
> > - Define standard and fixed locations for stuff, in plain english. Not
> > because it's the most beautiful language, but because it's the default
> > in all computing and most programming languages due to historical
> > reasons (bad argument, but makes the most sense). This would be cool
> > to be from FDO, but a GNOME standard would suffice (there's no reason
> > to be extra friendly to other environments, if standards do not
> > exist).
> Really? Well all modern distros are shipping non-native apps like
> Firefox as their default browser - you sure we want to ignore them?

I believe Firefox downloads to ~/Desktop by default, which would sit
well if the current situation would be the base of the standard.

Besides that, Firefox is designed for a number of platforms and
environments so surely it's Firefox who should blend itself to the
current environment, not the environment accounting for x number of
applications with arbitary requirements? It shouldn't be too hard to
see if gnome-session is running (or something) and adjust accordingly
at startup.

> One thing I would like to make clear is that we do not have the luxury
> of one desktop, one toolkit etc that OS/X effectively has and thats why
> we have FDO.

Well that was the idea, but I just think it is worth a standard even
if FDO doesn't have one.

> Yes it sometimes means we have to be more flexible and go
> the extra mile workwise in order to create a better integrated desktop
> but its worth it.

By "being more flexible" you are entering the windows hell of
backwards compatibility and per program hacks. And to me that sounds
like it would be extra around the globe and mile, not extra mile. Open
Source has the benefit of easy fixing through patches to the original
source, why not use that and not work _around_ incompatibilities?

You really are suggesting that the Desktop should integrate with
applications and not the other way around?

If the answer is "yes", I shall stare blankly at you in disbelief.

> The issue here in not purely translations - we need to have configurable
> paths to Music as some will want them in home or desktop or hidden. Not
> making them configurable is simply being short sighted and I pity the
> poor shmuck who has to go in and change this yet again in the near
> future cause we didn't take the big picture into account.

Of course the folders need not to be actually folders, but can be a
symlink to where the _advanced_ user wishes them to reside (I would
use this, as I have "global" folders for music etc). The point is that
every program could know where to look at. If all agree, a dot-dir
would be fine, though I personally would do 'ln -s .foo/* $HOME' then.

I just wonder why it's such a big deal to have something visible in
$HOME, IF the folders are not created without users consent (so you
can delete them if you don't use them) AND it can be a link to
somewhere. If the folders do not exist, programs should ignore them or
possibly suggest creating them ONCE.

If the GUI would not show such place as Home, normal users would never
need to see its contents at all.

I really don't see how the "big picture" will suffer form a fixed
location for certain things, accessible by anything when compared to
some hacky systems that work either in one environment (gconf) or are
screwed if an aspect of the system changes (locale).

> > I personally think that the GUI should abstract the filesystem
> > completely from the users view ($HOME is also crap when exposed in the
> > GUI)
> Not even OS/X does that!

Really? Well that's out of the question then, huh?

> We should aim to hide away the filesystem more
> subtly as we are currently doing.

Sorry, don't agree. Kick the bloody thing out of my desktop and I'll
be happy as a very happy thing with smile on its face.

God I wish the metadata systems would rush in to the scene...

Kalle Vahlman, zuh iki fi

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