[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-01-31 23:01:05
[Download RAW message or body]

On Thursday 31 January 2002 22:17, Carsten Pfeiffer wrote:
> On Donnerstag, 31. Januar 2002 13:22, Michael Brade wrote:
> > On Thursday 31 January 2002 11:23, Neil Stevens wrote:
> > > If you use a KFileDialog to get a directory, then pass that directory
> > > to a KFileTreeView, the KFileTreeView gets no items.  Can anyone help
> > > me figure out what's wrong?
> >
> > Yes, found it. The problem was that KFileTreeView::addBranch started the
> > listing without the signals from KFileTreeBranch connected. Later on
> > KFileTreeBranch::populate() was called which resulted in an
> > KDirLister::openURL() but since the lister already listed the url it just
> > called updateDirectory() which yielded no new files.
>
> 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 
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 store 
all the items in one list... Suggestions?

> > The attached patch fixes it by not calling setOpen which emits the
> > expanded() signal which in turn results in populate. This also prevents
> > KFileTreeBranch::addBranch to immediately start the listing. However,
> > just calling populate() after addBranch() will not open the item, the
> > user has still to click on it. So is there any method to open the item
> > without emitting expanded? (apart from using blockSignals()?)
>
> 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 (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.

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