[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Against the system:/, media:/ and home:/ namespaces
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2005-07-12 20:47:19
Message-ID: 1121201239.2305.38.camel () master ! amauta
[Download RAW message or body]

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ó:
> söndagen den 10 juli 2005 21.13 skrev Szombathelyi György:
> > > 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 years 
> ago.
> Not having the definition of the relations between "This Computer", "Desktop", 
> "My Documents" completely clear (you know, they differ in reaction to your 
> 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 guess 
> people like it arranged differently as well. So perhaps the KDE devs would 
> 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 of 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 whatever 
> instead of being disabled.
> 
> Please don't get too deep into complex virtualities about the filesystem.
> 
> Regards,
-- 
Manuel Amador                   <rudd-o@amautacorp.com>
http://www.amautacorp.com/            +593 (4) 220-7010
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]