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

List:       kfm-devel
Subject:    Re: konqy listview configurability
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       2000-03-20 14:51:36
[Download RAW message or body]

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.

> > > - 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?

> > > Using KProtocolManager::listing() will easily tell what is supported
> > > for a given protocol, if we fix the .desktop files this way.
> >
> > Yes, should this checking be done in ::slotStarted() or in ::openURL() or
> > somewhere else ?
> 
> When filling that menu, i.e. in openURL if this is a new protocol - that
> check already exists. Basically on a new protocol we (well, I) want to:
> - get hold of the supported fields using KProtocolManager
> - get hold of the fields the user wants to see (readProtocolConfig())
> - display all fields in the menu, disabling the ones that are not
> supported and checking the ones the user wants to see.
Me too:)

Greets

Michael

-- 
Michael Reiher
     Student at Dresden University of Technology
          Department of Computer Science
               email: michael.reiher@gmx.de

"Beware the woods at night, beware the lunar light!"

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