[RFC] One ioslave to rule them all...

[Kévin Ottens]

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 
translatable label...

> 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. =)

Regards.
-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050627/6402505b/attachment.sig>