I agree with you.

A question that should have been thought over way before we invented
media:/ (which has its uses, but it's a pain in its current form):

"How hard was it, really, to build intelligence on Konqueror to simply
overlay the proper icon on would-be mountpoints, and mount the disks
when entering them?"

In other words, all Konqueror really needed to do is, upon visiting a
directory, show a different icon for each folder that is a mountpoint
listed on /etc/fstab. When entering the folder, mount the disk. When
exiting the folder, do nothing. Couple that with media removal
notification and hald, and you have your "automatic" mount/umount.

Don't tell me it's hard. Windows XP has this. You enter a folder which
is actually mounted from another volume. Its icon is different.

This would have solved the need for media:/. Why? In my case, after
seven years of being a Linux (always) +KDE (sporadically) user, I would
have only needed to go to /mnt (now it's called /media).

Media:/ may sound conceptually clean and cool. The realities of drag-
and-drop, mount/umount handling, and other small things that have been
accumulating as time has gone by, completely break the conceptual clean-
and-coolness of media:/.

El lun, 11-07-2005 a las 09:48 +0200, Jonas Widarsson escribi=F3:
> s=F6ndagen den 10 juli 2005 21.13 skrev Szombathelyi Gy=F6rgy:
> > > The problem here is that users expect that going Up from where they
> > > clicked goes back to where they were. That's one of the big problems =

with
> > > kio_devices that we are trying hard to solve.

> >
> > Yes, that's what I wrote that a 'smart' solution needs here. But I think
> > that inventing a new naming scheme just because the 'up' button does not
> > work a bit of over-engineering.

> =


> Isn't this where the concept of a "back" button should be learned?
> =


> I was into writing something that looks like KDirStat for windows some ye=

ars =

> ago.
> Not having the definition of the relations between "This Computer", "Desk=

top", =

> "My Documents" completely clear (you know, they differ in reaction to you=

r =

> locale/language) it was a PITA to support as a programmer.
> =


> I would like to raise a loud warning about going where relations between =

paths =

> are so virtual that "up" jumps between different locations on different =


> depths within the real unix path. It is a pain to program for, and I gues=

s =

> people like it arranged differently as well. So perhaps the KDE devs woul=

d =

> like to allow for *customized relations* as well (!!!). =


> =


> Now, how fun would it be to discuss bugs in such a system?
> =


> It isn't very broke as it is, right?
> =


> Please, stick to the back button instead of connecting "Up" from root of =

a =

> removable device to something else than just the directory above.
> =


> There is one other view on this matter, namely to already be at the top o=

f a =

> protocol that doesn't have a local unix path representation, e.g. =


> sftp://hostname/
> >From there, it is far more logical that "Up" leads to system:/ or whatev=

er =

> instead of being disabled.
> =


> Please don't get too deep into complex virtualities about the filesystem.
> =


> Regards,

-- =

Manuel Amador
http://www.amautacorp.com/ +593 (4) 220-7010
=

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=

e <<