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

List:       kde-core-devel
Subject:    Re: KFileDialog, KFileTreeView, KDirLister, something's broken
From:       Michael Brade <brade () kde ! org>
Date:       2002-02-01 11:19:25
[Download RAW message or body]

On Friday 01 February 2002 02:18, Carsten Pfeiffer wrote:
> On Freitag, 1. Februar 2002 00:01, Michael Brade wrote:
>
> (can you please keep CCing Klaas, I'm not sure he's subscribed here,
> thanks)
Sorry, I didn't look at the headers.

> > > Hmm, but whenever you call openURL(), you expect all directory entries
> > > to be emitted, no? From the cache or read from disk.
> >
> > Yes, but only if _keep == false. I'm not sure what to do if you have a
>
> Hmm, but this treeview always uses keep == false, no? Klaas should know...
> all I know is that this treeview doesn't use one KDirLister for all the
> items, but one for every branch. So keep should always be false, IMHO.
No, from the logs I have it isn't ;) There is one branch for every view, thus 
one branch for every treeview.

> > treeview, holding url already, and you call openURL(url, true) again...
> > we could emit to clear all the items for url and emit them again. Hmm.
> > For this I thought about adding a clear( const KURL & ) signal - this
> > would be faster than calling deleteItem() for every single item. OTOH
> > some treeviews
>
> Yes, that would make sense.
Fine, but this could mean we need to change konqy as well. If nobody objects 
I'll do so.

> > store all the items in one list... Suggestions?
>
> Hmm, do they? Which ones, in particular?
ohh... didn't find one, was just a guess ;) So is it ok to just emit 
clear(url) and not deleteItem? Then I could change 
KDirListerCache::slotRedirection as well :)

> > > I'm not sure what you want to do here. You want to open the branch
> > > without expanded() being emitted?
> >
> > yes. because it starts the listing immediately and thus calling addBranch
> > will already start the listing immediately as well - which is not its
> > intention, I guess. Furthermore the KFileTreeView is quite broken
>
> Not sure it is... Klaas?
You mean the intention? ;-P 
Well, from the addBranch docu it is intended but this contradicts the docu of 
populateBranch...

BTW, I can define that "broken" better now: in 
KFileTreeBranch::slotListerStarted a m_currParent is determined which will 
break if KDirLister is listing more directories at the same time. Klaas, can 
you fix that, please?

> > (sorry...) because calling setOpen() in the CTOR after connecting the
> > signals correctly it stores the files under the wrong directories. Even
> > more, every click to open a closed folder calls KDirLister::openURL()
> > (and thus updateDirectory currently) again, regardless if we already have
> > the items or not - this defeats the purpose of the cache, obviously.
>
> Sorry I didn't have any time to dig into the KDirLister (or KFileTreeView),
> but I thought openURL() would always use the cache if possible, making it
> transparent to the user. If this isn't the case (openURL() reloads?), how
> would you use it correctly?
Well, ATM this _is_ the case except for using openURL( url, true, false ); 
which I'll change now.

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3.0: Konquering the Desktops


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