konqy and the model-view-concept in the dirviews

[David Faure]

On Sunday 30 April 2006 22:38, Alexander Neundorf wrote:
> Hi,
> 
> in KDE 2 and 3 konqy each dir views in konqy does the directory listing 
> itself.
Well, they get KDirLister to do it for them ;)

> Konqy knows only about the current url (i.e. the directory) of each  
> view.
> Would it make sense to refactor this with Qt4 so that konqy does the directory 
> listing and the views really only display the result ?
> E.g. when viewing a directory and then viewing a file in this directory, as it 
> is now a new kpart is loaded and the status of the dir view is lost. When 
> going back from the file view to the dir view the directory has to be read in 
> again. 
Yes but it is read from the kdirlistercache, so that's pretty fast.
The rest (scroll information, selected files, etc.) is stored in the history.

> But the information which files was just viewed is gone. I think  
> having a "current directory" and a "current url" (which will be equal if the 
> current url is a dir) and a list of the contents of the "current dir" might 
> make some things easier.
KDirLister has that information (contents of a directory) already.
And the current url and directory are obviously known by the parts.

> It is currently also not possible to do a "go to next file" while viewing a 
> file, because at this time the next file is not know (it was known when the 
> dir view was still active).
Ah - OK. That much is indeed missing. But parts should be reusable outside of konq,
so it's not konq which should store the information about the directory listing; instead
it should be given to the part via BrowserExtension. But for memory saving we don't
really want to pass a whole set of fileitems there; so maybe all we need is sorting information
and a kdirlister method "give me the next url after <this file> using <this sorting>".
Since the directory listing is in cache, it should be pretty fast; well, except that the sorting
needs to be applied first.

Then parts could call that (with their own url and the sorting coming from BrowserExtension)
when the user presses the "next file" button.

Or did you mean that button should be provided by konq, not by the part itself? That would
be doable too, in a very similar way.

For konqueror4 the idea was to have an embedded preview pane though, but I'm not 
sure if that removes the need for the above or not.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).