[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Localised folders in /home/user (Documents and Desktop)
From:       Sven Burmeister <sven.burmeister () gmx ! net>
Date:       2006-11-23 5:24:54
Message-ID: 200611230624.55075.sven.burmeister () gmx ! net
[Download RAW message or body]

Hi!

Am Mittwoch, 22. November 2006 23:48 schrieb Kevin Krammer:
> Hmm, well, if we start assuming that "normal users" are not
> - looking at paths
> - not accessing the root directory
> - not activating hidding file
>
> why do we need a direct association with directories and folder names
> anyway? Wouldn't it be easier to have Desktop and Document just not be
> directories from the user's point of view, i.e. below a hidden directory
> and thus never visible in paths?

I have "documents" on a different partition, this would not be possible, would 
it? At least the user would have to know the hidden place of the directory to 
assign it during installation.

Why not simply localise them and establish via freedesktop a common variable 
that indicates to all applications which directory is the document-dir. Or, 
even simpler. Do not store common paths, i.e. "Desktop" and "Documents" in a 
KDE-config but establish a ".commonpaths" file with the paths of "Documents" 
and "Desktop" in it. Or a file each, i.e. ".pathtodesktop" 
and ".pathtodocuments". The user deleting that file would not cause any 
data-loss and is as likely as deleting .kde.

> > > If this happens with data files, those of such broken programs will be
> > > "lost". Data loss is considered to be one of the worst possible bugs.
> > > Will be extremely "nice" to debug and great "fun" for us support
> > > people.
> >
> > I do not have any apps installed in home and even if, they should not be
> > installed in Desktop or Documents.
>
> I was talking about data, not applications.
> Location of applications are unimportant, they are started by launchers
> (e.g. K-menu)
>
> Consider Firefox downloading something to the desktop, it won't be there
> for users with KDE and German localisation, because their "desktop" is
> called "Arbeitsfläche", so the file is obviously not there.

With the above approach this would not happen. But even if the file was not 
used, there would not be data-loss, since the user should dimply be asked by 
the app where to save a file, if the standard-dir is non-existent.

> Too bad for the Mozilla people, they'll get nice bugreports for broken
> downloading, which they will be closing as not reproducible until someone
> discovers it applies only to KDE users using non-English locales.
> Fun!

That would simply be a big bug in firefox! Not telling the user that the 
default-dir does not exist is just bad design and not a reason against 
localisation. Nothing to worry about from KDE's point of view.

Did you test this before using it as argument, especially since you write 
about data-loss. If Desktop does not exist, the file is simply downloaded to 
~, so there is really no loss at all.

> > If there was a variable like
> > $USERNAME_DOCUMENTS and all apps would use it, there would not be such a
> > problem. You cannot make it easier for applications.
>
> Variables do not work technically, can't be altered during runtime.

See the .pathtodocuments approach above.

> > What happens currently, if I rename Documents or Desktop, nothing fails,
> > so why should it happen when they are localised straight away.
>
> Right. Move/rename Desktop and tell me you still have all the file visible
> and accessible on KDesktop

If KDE creates those dirs, it does know about their paths. Documents is never 
an issue. Desktop only, if KDE is not aware of the action, which it is, if 
the user is not forced to alter the names manually to have them localised.

Sven
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]