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

List:       kde-core-devel
Subject:    Re: [RFC] One ioslave to rule them all...
From:       Fred Schaettgen <kde.sch () ttgen ! net>
Date:       2005-06-26 18:11:49
Message-ID: 200506262011.50005.kde.sch () ttgen ! net
[Download RAW message or body]

On Sunday, 26. June 2005 00:46, Kévin Ottens wrote:
...
> Currently system:/ points to media:/, trash:/, remote:/, settings:/ and
> home:/ (which was committed yesterday). home:/ being the last part of my
> great evil plan : hiding the real file hierarchy!
>
> I'm now almost able to do it, in fact if I could even do it now. Some of
> you may wonder "why hiding the unixian file hierarchy??? and push use of
> system:/???".
> The answer is simply that for a desktop user this unix file hierarchy is an
> implementation detail.

But aren't you _changing the implementation_ by introducing the home ioslave 
instead of just hiding it from the user? What's the point of replacing /home/ 
with home:/? Both users (and applications) have to digest a new 
implementation detail now - their own files are accessed with some sort 
of ... protocol now, you know, like web pages, but unlike other files on 
their harddisk or files opened with openoffice, firefox, scribus, you name 
it. Are you sure this makes it any easier for them?
And if a file is opened via the a home url you still have the untranslated 
"home:/" in your URL - that's again where the implementation shines through. 
If it's really about hiding the "implementation detail" a.k.a. file system 
hierarchy, I believe that ioslaves are not enough.

What if the shortcuts available on the left hand side of the file open dialogs 
were used to replace prefixes of paths shown whereever a path is displayed?
This would allow us to show a translated name and an appropriate icon for well 
known path prefixes like /home/$USER, /tmp, /etc, system:/ and so on. And we 
don't have to introduce yet another ioslave for each of these paths. 
Internally we would still use regular paths (for local files) everywhere, so 
if a non-KDE-Application is involved, the the paths might look different, but 
at least it's guaranteed to work.
Since this prefix replacement would only be used to _display_ paths, if would 
be no problem to let those who don't like it disable it. I guess that I'd be 
one of those who disable it btw ;)

regards
Fred

-- 
Fred Schaettgen
kde.sch@ttgen.net

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