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

List:       kfm-devel
Subject:    Re: konqueror issues
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       1999-02-11 17:19:15
[Download RAW message or body]

David Faure wrote:
> 
> On Thu, Feb 11, 1999 at 01:25:19PM +0100, Michael Reiher wrote:
> > David Faure wrote:
> > >
> > > Oh, I know : a KfmHTMLProps class :)
> > > There would be only two instances : one for FileManager mode,
> > > and one for HTML mode. KfmView would use the right one depending on
> > > the mode.
> > >
> > > I hope you won't flame me because I suggest too many classes :)
> > >
> > > The 'local' (or per-URL) properties in kfm II was a pain, and I think
> > > the way to handle it correctly is by storing the properties in a class.
> > >
> > > I'll do that if you all agree...
> > I would also vote for dropping the per-URL settings.
> This is not what I said ! I was only speaking about a different
> to handle per-URL settings... Sorry if I wasn't clear.
> 
> One still would like that a given URL is shown with small icons,
> another one with dot files, ...
Right! I also thought that but the mail was already gone.
> 
> Session management only takes care of opened windows, not of
> URLs you often go to and like some settings for.
> 
> > Btw: I think two views are enough. If it is split up in letīs say four
> > views you need a large screen to make them useful. But if you have a
> > large screen anyway you can just open another kfm, ehh
> > sorry...konqueror:), window.

> Come on, let's make it _really_ generic, with as many views as the user
> wants to.
OK! And the views should be OpenParts. Then each view can be a file
view, tree view, HTML view, image-viewer view ... what ever. 
Specially configured view parts could be used in kfile or kfinds result
box. Yeah that will be sooo cooool! I
really like KOM/OpenParts!
> Only issue is about trees : are they just another view in tree mode, or are
> they opened as 'the tree for view X', so that it follows the navigation in
> view X ?
First I would say only one "tree" class, but that _completely_
configurable. You should be able to configure the shown columns and
their order and switch between different sets with a key
combination(like MCs Alt-t), their starting dir. Further it should have
user defineable top level items i.e. root, home, desktop, cdrom, other
hds or ftp servers. Maybe that UDS stuff is useful for that? Does anyone
know where I can get more information about that? Open ftp servers could
be added(and removed) at runtime. Trees could be made connectable to any
view by the user at runtime. It shoulnīt also be so hard to turn the
current tree widget into a long list view. Iīm currently forced to work
with 800x600 and there I would prefer only to have the file names in the
first column and not a tree structure because all the indents are wasted
space. And that is limmited.
That are only some of my ideas:)
Are there already any detailed design plans for that stuff? Torben?

Michael

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

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