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

List:       kfm-devel
Subject:    Re: draft+thoughts
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-27 16:59:22
[Download RAW message or body]

On Sat, Feb 27, 1999 at 11:42:23AM +0100, Simon Hausmann wrote:
> >> >Something else : you didn't make a common parent for IconView and TreeView
> >> >(both relate to file management and have a lot in common) 
> >> 
> >> Yes, that's a good idea.
> >> What common stuff did you think of for example?
> >I had another look. ok, there is currently a lot of duplicated code between 
> >kfmfinder.* (i.e. the TreeView) and kiconcontainer.* + kfmicons.*
> >(including the list of functions that I pasted in a previous post, in fact
> >the View Properties stuff) but ... (see below)
> 
> BTW, question in regard to the naming: Should we stay with kfmfinder or should
> we go for TreeView (or KfmTreeView) ?
Let's rename.

> (my vote: I like TreeView (withouth the leading "Kfm") , because
>  a) "TreeView" is imho more self-explaining than "Finder" (wdh is a
> "Finder"? ;)
"Finder" is the Apple naming for it.

>  b) (in regard to the "Kfm") the TreeView might perhaps become more than a
> plain view-directories-and-files thing but, in regard to Michael Reiher's
> ideas, a completely configurable thing :-) (*really_looking_forward_to_this*)
So ? For me, "kfm" means file management, i.e. anything including file and
directory icons.
A Tree view always involve directory icons, even on a ftp site or seeing
files like mailboxes. I would keep the kfm, but that's just me and not very 
important.

> *wild-daydream-begins*
> For example I would like to see this:
> (assuming the treeview would be extremly configurable and accessible via a
> CORBA interface)
> KMail extends the tree view by another root item in the tree representing email.
And a ftp site can show its hierarchy too...

> >> And in fact I did this for all views: All Konqueror Views (on c++ level)
> >> inherit from a class called KonqBaseView (not visible as IDL interface)
> >> which contains some common code. 
> >.. if a KonqBaseView exists, it could store the View Properties stuff, so
> >iit's fine. No need for the common parent I talked about.
> >Well, I think so.
> 
> Ah, that's a great idea!
> 
> >Hum, for instance, showDotFiles means nothing for a HTML view ...
> >So either we had a common parent for icon and tree views, which will have
> >this showDotFiles stuff, _or_ we just have all the functions for any view,
> >but changing showdotfiles for a HTML view will do nothing, of course.
> 
> I like the common-parent-for-icon-and-tree-view idea.


-- 
 ____________________________________________________________________
|                                                                    |
|  David FAURE                                                       |
|  E-mail : David.Faure@insa-lyon.fr, faure@kde.org                  |
|  http://www.insa-lyon.fr/People/AEDI/dfaure/index.html             |
|____________________________________________________________________|

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