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

List:       kde-devel
Subject:    File manager useability concerns for KDE deployers (was Re: Bug#43093: KFileDialog should not use fl
From:       Manuel Amador <amadorm () zeus ! usm ! edu ! ec>
Date:       2002-05-30 19:18:19
[Download RAW message or body]

Quoting Klas Kalass <klas.kalass@gmx.de>:

> This statement suprises me a lot, because I always thought that the only
> point 
> in having floppy:// was making it easier for former windows users -
> because 
> this way one does not need to do a umount of the floppy device which I
> am 
> sure is the single most error of someone new to Unix. 
> But I agree that having two ways presented to a user to access a floppy
> is not 
> good (proper mounting on the desktop and floppy:// in the file
> dialog).

I see you got my initial point.  Fast forward a couple of lines and you\'ll see 
why. Maybe I wrote the e-mail/bug report in the wrong order =)

> 
> [...]
> >
> This is no KDE issue, bug the distributors. 

The accidental replacement of .desktop files is.  See below.

> But how do you do mounting
> with a 
> symlink on a system with no automounter? Or do you propose doing a
> user-level 
> automounter for KDE?

This is a good question.  The answer to this lies further ahead in the e-mail

> There are a few such tools (I don\'t remember exact
> names 
> except for magic mounter) but they all had some problems last time I
> checked. 
> And I honestly doubt that KDE can do anything about foreign apps like 
> Mozilla.

If it used symlinks to mounted/automounted drives, Mozilla would have no 
problem. I know it\'s the distributor\'s job.  These are ORTHOGONAL issues.  The 
fact that the distributor does/doesn\'t use supermount/autofs/amd does NOT 
preclude the idea that the Floppy.desktop file is of no use to open/save files 
from applications.  Especially from non-KDE ones.

A symlink would do exactly the same thing.  If the device needs to be mounted, 
then what the heck, it would have needed to be mounted with a .Desktop file 
too, right?.  Symlinks for devices instead of .desktop files are a much 
cleaner, better solution.  All we need is some logic to place the proper icon 
on directories that are mount points, to show them on the desktop and to mount 
them whenever you click on them.  Non-KDE apps will have to make do without 
the \"mount as you access it\" thingie, unless the distributor chooses to 
automount them.

> 
> [...]
> >
> > For the network, the work done in the Network Neighborhood by Lycoris
> is
> > good. But there is one thing they left out: the possibility of
> remote
> > mounting of shares.  
> I don\'t know how this is a KDE issue? What do you propose (please keep
> in mind 
> that either root needs to configure fstab correctly or mount the
> device/share 
> himself)?

I know.  I would like that there is a possibility of dragging, say, the File 
share icon to the desktop and presenting the option of mounting it there by 
invoking smbmount (just a \"Mount\" or \"Capture\" label on a simple regular file 
drag operation popup menu).  IF and only IF smbmount is setuid root and 
executable for the user performing the action.

> 
> > Because currently KDE asks you to download files from
> > SMB shares. 
> Does it? I always thought this was transparent (download and upload of
> 
> modified files)!

No.  It asks whether to download or open.  File save is not transparent. Have 
you tried it?

> 
> > There is no functional equivalent to the \\\\\\\\server\\\\share
> > syntax for applications.  The state of non-KDE apps is even worse,
> because
> > they simply won\\\'t save the file. The user opens the file, modifies
> and
> > saves it, and expects the changes to reside on the network server.
> Once again, this is no KDE problem. If you have a *good* solution maybe
> 
> something can be done, but ATM the current scheme works perfectly for
> KDE 
> apps and so does not need to be changed (IMO that is).

It works for KDE.  True.  For non-KDE apps it doesn\'t (just as \\\\server\\share 
didn\'t work for DOS apps).  Maybe this can be solved by putting a watch on 
downloaded files, maybe this can be solved by the \"network volume mount\" 
smbmount by dragging the share to a folder/the desktop.

> 
> >
> > One step in the right direction is changing to the TRUE directory when
> a
> > symlink is opened.  This is the new behavior in Konqueror and I
> applaud it.

Because users get a consistent view of their namespace.

> >
> > on another note, floppy:// is not X terminal-friendly.
> Please, either teach your users UNIX or help making the KDE GUI easy,
> but when 
> a user really needs a shell (s)he needs to know some UNIX anyways.

Which shell are you talking about?  I was talking about GRAPHICAL X terminals.  
All I want is icons for removable drives that work across as many applications 
as possible.  The current KDE way of doing things does not help, but complicate 
the user experience.

> 
> >
> > Moreover, I can\\\'t find a way to configure the sidebar
> (GUI/CLI/config
> > file)
> RMB?

Doesn\'t work.  Have you tried it?

> 
> >
> > (i thought people would understand me, but here I am trying to explain
> it
> > all =)  maybe I needed to write a few good paragraphs.  My end users
> are
> > killing me over this seemingly dumb problem.  Right now I have to tell
> them
> > to save their files to the desktop, then open the Floppy icon and drag
> the
> > files to the window that opens.)
> Or tell them to use kwikdisk and teach them the concept of a root
> directory, 
the computer can do it, why does the user need to?  Why do we have computers?
> followed by the concept of mounting and unmounting. If this is too much,
> they 
> should resort to KDE only apps and use floppy://

wrong.  This is the wrong kind of idea, just what we don\'t need.  If the system 
can do it automatically (or at least have the infrastructure for distributors 
to do the job of setting it up for end-users), then why not?

> 
> You might like the new devices io slave.
> 
> [..]
> > * Automatically mount media on entering a mount point appearing on
> > /etc/fstab as user-mountable.  This could be solved with the aid of
> > supermount or autofs. Not that both are beautiful solutions, but they
> work.
> once again supermount/autofs is a distribution thing, but asking the
> user if 
> he wants to mount the device/share when he enters a directory mentioned
> in 
> fstab is a good idea,

Dumb question.  Evidently the user wants it to be mounted.  Maybe the reminder 
to unmount is fair.

why not try to integrate with the standard UNIX namespace?  What happens when I 
drag an icon from the Floppy opened through devices to an XMMS window in order 
to listen to an MP3?  Why should I as a user need to think twice before doing 
that (as in, \'is it a device or is it in my regular UNIX namespace?\')?  
Especially if as a regular user, I don\'t even know what a namespace is, much 
less how to explain what went wrong when I tried to do so.

Why?  Why do we have to abandon the standard UNIX namespace?  I propose to 
write a user-space app that does the same as Devices://, only mapping it 
automatically to the standard UNIX namespace.  That way all applications work 
transparently.  The issue of mounting/unmounting devices is a thorny one, but 
currently we have to mount/unmount devices after all.  Instead of a 
Floppy.desktop icon, why not a symlink to a /mnt/floppy?  Information about the 
mount point can be gleaned from /etc/fstab, and the user could mount/unmount 
it.  If distributors so choose, they can use autofs/supermount, and KDE should 
also detect drives handled by those and place the correct symlinks.

I\'m frustrated. You\'re forgetting about the real needs of the UNIX user.  Maybe 
we should start thinking about a $HOME:// ioslave.

URNs should only be used when there is really NO way to incorporate a device\'s 
information into the UNIX namespace, whenever possible.  Maybe for a audio-cd 
ioslave it\'s ok, but for a floppy, which can be mounted/unmounted regularly?  
Not the correct solution, in my opinion.  It\'s not bad that we have it.  It\'s 
that we should STANDARDIZE on one solution for the ENTIRE desktop, and the 
solution that limits itself to only KDE-only apps (as opposed to any other UNIX 
app) and PCs (as opposed to terminal servers) is not acceptable by any 
standard.  Remember that the most savings come from terminal server 
installations.


Please, someone who has experience deploying KDE \"in the wild\" chime in.  We 
need your opinions
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]