Re: Translations of folder names - two proposals

[Kalle Vahlman <kalle vahlman gmail com>]

On Mon, 13 Dec 2004 13:09:36 +0000, Jamie McCracken
<jamiemcc blueyonder co uk> wrote:
> On Mon, 2004-12-13 at 14:55 +0200, Kalle Vahlman wrote:
> > 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.
> >
> No the desktop should use FDO so that apps merely have to integrate with
> that rather than X different desktops.

FDO is the preferred channel, yes. But what if this conversation is
played again on their list and no standard is agreed upon? Forget the
whole thing?
 
> [snip]
> 
> > 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).
> >
> FDO wise we would want to have an FDO lib that hides the actual
> implementation. Having a gnome lib instead is counter productive. We can
> create a provisional FDO lib today and have it ratified by FDO later
> where the actual implementation can be changed (but not the API).

So the FDO lib will work how with scripts etc? I never talked about
libs, I say make a specification that defines the dirs. No translation
of the folder names, just a specification what to use as a default
location for things. Tell the user you are accessing "the music
folder" when you search through ~/Music. If it's not there, first time
ask the user if she wants a common folder, if not, ignore it in the
future.

This disables nothing, breaks nothing, requires nothing but conforming
to the standard and gives a reasonable defaults.

> Having a ubiquitous FDO lib makes it easier for non-gnome apps to
> integrate and the easier we make it the more likely they will.

As opposed to fixed locations? How hard can that be?

> Also how
> its implemented then becomes irrelevant to us (do we really wanna know
> or care?).

Do we really need to implement?

> > > > 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?
> No but it reinforces the view that its unfeasible currently.

Well we're stuck then, since Windows showed us that translated
directories are just as bad (actually, developers are).

> > > 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.
> Well the filechooser achieves it well enough in my opinion - the file
> system is still accessible by those who need it but its not in yer face
> so ordinary users dont have to.

Remove (at least) the Home and filesystem from it and I'll say that
too. There's ctrl-L for wicked paths.
 
> > God I wish the metadata systems would rush in to the scene...
> vFolders would be very nice. It all depends on whether Medusa is gonna
> get some development...

Anyone care to pay me for developing it? I really need some coding
work for my education... ;)

Just to further clarify my thoughts on this, the spec would look something like

-- 

The SPEC

The following folders or symbolic links should be used as a primary
target to locate and place the specified file types/categories:

~/Desktop
  Holds objects visible on the implemented desktop or equivalent.
...
~/Music
  Holds files that can be considered to contain musical attributes
~/Documents
  Holds documents

All directories listed here should not be created without the users
permission, for which should only be asked once.

The absent of any of these folders should in effect mean "fall back to
whatever was done before".

Blaa blaa and something I can't remember now.

--

Now, everyone is welcome to use these and declare they conform to the
spec or to ignore the spec and use whatever the user wishes. This
isn't lying to the user, since the user is not forced to see any path
for those unless the programmers intentionally show them instead of
using generic, translatable description for them.

Oh, and by the way. Browser Nautilus is out of the scope since it
depends on the filesystem and this all is about hiding it (translating
hides the real location too).

And I don't think these should be forced on anyone, they should just
be ignoreable defaults.
-- 
Kalle Vahlman, zuh iki fi