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

List:       kde-devel
Subject:    Re: File manager useability concerns for KDE deployers (was Re: Bug#43093: KFileDialog should not us
From:       Klas Kalass <klas.kalass () gmx ! de>
Date:       2002-05-30 20:17:29
[Download RAW message or body]

Am Donnerstag, 30. Mai 2002 21:18 schrieb Manuel Amador:
> Quoting Klas Kalass <klas.kalass@gmx.de>:
> >
> > 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.
Maybe something like this would be nice, I agree. I'd prefer a right mouse 
button menu entry "mount" that pops up a dialog and asks for root password if 
needed. But how does this work in the X-Terminal case? ask for the server 
password???

>
> > > 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?
Not with smb because I do not need this protocol, but it does work with fish 
and ftp - but maybe we are not talking about the same thing? I was talking 
about opening from the file dialog. When it does not work with a specific KDE 
app this is a bug and should be reported.
Anyways for opening a file from konqueror I see no problem in it asking wether 
the file shall be saved (locally) or opened and then asking if it shall be 
uploaded when the app finished.

> > > 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.
Sorry, I misunderstood (I thought you were talking about xterm). But I fail to 
see how your approach is better for this - KDE is run on the server, right? 
How can it do some magic on the clients filesystem like creating links or 
mounting devices?

> > > Moreover, I can\\\'t find a way to configure the sidebar
> >
> > (GUI/CLI/config file)
> >
> > RMB?
>
> Doesn\'t work.  Have you tried it?
Yes, what version do you use? It worked when I tried it some time ago and it 
does work with a cvs version from about a week ago. Or do you mean turning 
the thing completely of?

>
> > 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?
How can the computer automatically unmount a floppy? Mine has no way of 
knowing when I want to eject the floppy because it is mechanical. So either I 
risk losing data if I do not know about umount or I really should use 
floppy:// And umounting after a set timeout is very bad IMO because I have no 
control any more, whatsoever.

>
> > 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?
HOW? We are working on UNIX and we do have the concept of mounting/unmounting 
and we do not have specialized hardware (floppy drives that do not eject 
mechanically).

>
> > 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.
No, that is not evident. How about a directory where some nfs filesystem is 
mounted to and I do not want to mount that, because I am just browsing the 
filesystem?

>
> 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
You do know what devices:/ does, do you? 

> I\'m frustrated. You\'re forgetting about the real needs of the UNIX user. 
> Maybe we should start thinking about a $HOME:// ioslave.
Maybe we both do not understand each other directly, but how can hiding from 
the user the need for a unmount be a good thing? And unless floppy:// is 
used, a unmount is needed. The user needs to be aware of this. And so the 
user needs to know the basic UNIX concepts.
And I do not see how it is better to put symlinks on the desktop than having a 
special place where to mount/umount devices (the devices ioslave) and tell 
users where the mountpoint is, so they can access it from other applications 
as well.

>
> 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 tell me how your solution works on a terminal server. I do not know 
much about those, but I always assumed that once you login to the server via 
kdm/xdm you work on the server and have no local access anymore, whatsoever. 
Am I wrong?

Klas

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]