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

List:       kfm-devel
Subject:    Re: konqy listview configurability
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-03-20 14:43:53
[Download RAW message or body]

On Mon, Mar 20, 2000 at 03:51:36PM +0100, Michael Reiher wrote:
> David Faure wrote:
> > 
> > On Mon, Mar 20, 2000 at 03:12:01PM +0100, aleXXX wrote:
> > > On Mon, 20 Mär 2000, David Faure wrote:
> > > > Why not doing it this way (in the submenu listing the columns) :
> > > >
> > > > - disabled menu item -> not supported
> If you want this you´d need to put all ever possible columns/fields for
> all supported protocols into that submenu. Can become a bit long, no?
> And only to show that something is not supported.
Well, it's better than having a full column for such a field ;-))
See below for why I think we can have a disabled menu entry.

> > > > - unchecked menu item -> supported but hidden
> > > > - checked menu item -> supported and shown.
> > >
> > > because I have to open the submenu to see it.
> > ... which makes sense if you're looking whether you can
> > show more or not.
> > Sorry, I thought your question was about this.
> > 
> > > Hmm, we both like to insist on our versions. ;-)
> > Well, I answered your question in a way that I thought
> > version-independent ;-)).
> > The question of per-protocol configuration and auto-saving or not
> > are open, I think. But the solution for the submenu is unique
> > and is the one above, I think. See below for more on this.
> I vote for per-protocol configuration and auto-saving:)
> 
>
> > > I really believe that not hiding the unsupported column but displaying e.g.
> > > "Not supported" is the best way of feedback to the user.
> > And I really believe that this is bad UI design and a waste of space !
> > Why would users want to see, when using SMB, "symlinks not supported" ?
> > Be prepared for the bug reports "please support symlinks!".
> > The submenu reflects what one can and can't do, fine. Displaying
> > something that looks like an error message is really not
> > user-friendly.
> I agree with David here. The submenu should contain only all at the
> moment possible columns.
> And the view should only display those fields that are supported. Don´t
> only look at file, ftp or the like protocols. There are many others with
> sometimes quite different fields and you don´t really want e.g. a
> "Sender" or "Subject" column which contains only "Not Supported" when
> browsing you local FS, do you?

Hmm... You are mistaken about KIO ;-) The example you give is wrong,
because KIO has _flexible_ listing details, not _dynamic_ listing details.
Here is the list of the fields that are currently supported by KIO:
   "Size"
   "Owner"
   "Group"
   "Name"
   "Permissions"
   "Date"
   "Modification time"
   "Access time"
   "Creation time"
   "Type"
   "Link"
   "URL"
   "MimeType"
(and perhaps "Icon" in the future, but that one would be excluded from
 the list of available fields for listing, of course).

So, no Subject or Sender, but definitely some fields that are
supported by some protocols (FTP has only one time, I doubt
SMB has them all, and it has definitely no symlinks, and much more
differences with gopher, pop, imap, and other exotic ;-) protocols)

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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