This is a discussion on Re: Against the system:/, media:/ and home:/ namespaces - KDE ; 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 ...
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 =
> > > 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=
> Not having the definition of the relations between "This Computer", "Desk=
> "My Documents" completely clear (you know, they differ in reaction to you=
> locale/language) it was a PITA to support as a programmer.
> I would like to raise a loud warning about going where relations between =
> 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=
> people like it arranged differently as well. So perhaps the KDE devs woul=
> 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 =
> 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. =
> >From there, it is far more logical that "Up" leads to system:/ or whatev=
> instead of being disabled.
> Please don't get too deep into complex virtualities about the filesystem.
http://www.amautacorp.com/ +593 (4) 220-7010
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=