[RFC] One ioslave to rule them all...
ervin at ipsquad.net
Mon Jun 27 10:21:57 BST 2005
Le Dimanche 26 Juin 2005 20:11, Fred Schaettgen a écrit :
> 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:/?
It's not simply replacing /home/ with home:/, on some boxes, /home/ has
subdirs and users home dir are in those subdirs (in my lab they use it so
much that's completely mad), moreover most of the entries in /home/ are not
relevant for a user, so by default it's restricted to the home directories of
users in the same group than you.
> 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?
For users it changes almost nothing IMHO, they'll keep clicking on the "Home"
link which will open home:/$USER.
If applications use KIO, it doesn't make a difference for them. Moreover it
was already the case with media:/, and only applications not supporting KIO
where proven to have difficulties, but now it's fixed.
> 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.
Well, with Thiago's proposals we could hide the "home:/" part behind a
> 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.
Yes, and how does it behave when you go up? On of the point of all this is to
have a _unified_ virtual hierarchy, not something making you jump around in
the unix filesystem or the virtual filesystem. It's exactly what we had with
devices:/ for example, and I'm exactly trying to avoid it.
> 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.
Yes, but it doesn't solve the whole problem, since you're still tied to the
multi-hierarchy to browse the relevant place (namely system:/ and file:///).
Which is counter-intuitive IMHO.
> I guess that
> I'd be one of those who disable it btw ;)
I could guess this. =)
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel