--nextPart10588525.3vJc8j6boI
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Dimanche 26 Juin 2005 20:11, Fred Schaettgen a =E9crit=A0:
> 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=20
subdirs and users home dir are in those subdirs (in my lab they use it so=20
much that's completely mad), moreover most of the entries in /home/ are not=
=20
relevant for a user, so by default it's restricted to the home directories =
of=20
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?

=46or users it changes almost nothing IMHO, they'll keep clicking on the "H=
ome"=20
link which will open home:/$USER.

If applications use KIO, it doesn't make a difference for them. Moreover it=
=20
was already the case with media:/, and only applications not supporting KIO=
=20
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=20
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 appropria=
te
> 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=20
have a _unified_ virtual hierarchy, not something making you jump around in=
=20
the unix filesystem or the virtual filesystem. It's exactly what we had wit=
h=20
devices:/ for example, and I'm exactly trying to avoid it.

> Internally we would still use regular paths (for local files)=20
> 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=
=20
multi-hierarchy to browse the relevant place (namely system:/ and file:///)=
=2E=20
Which is counter-intuitive IMHO.

> I guess that=20
> I'd be one of those who disable it btw ;)

I could guess this. =3D)

Regards.
=2D-=20
K=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
Ne font reculer l'ignorance."

--nextPart10588525.3vJc8j6boI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCv8U4B0u7y43syeIRAp1EAKCHPib4xe8ZeNs2rpGow+Yv08z59wCfTuN5
bbeNm7kfDZj2mfE/QoDC7C0=
=MzJf
-----END PGP SIGNATURE-----

--nextPart10588525.3vJc8j6boI--