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

List:       kde-devel
Subject:    Re: KonqDirPart
From:       Michael Brade <Michael.Brade () informatik ! uni-muenchen ! de>
Date:       2001-09-10 19:09:20
[Download RAW message or body]

On Monday 10 September 2001 20:48, Julian Rockey wrote:
> > > I tried connecting some signals as an experiement:
> > >
> > >   connect(m_leftView->extension(), SIGNAL(popupMenu(const QPoint &,
> > > const KFileItemList &)), this, SLOT(slotDirPartPopupMenu(const QPoint
> > > &, const KFileItemList &)) );
> > >   connect(m_leftView->extension(), SIGNAL(popupMenu(const QPoint &,
> > > const KURL &, const QString &, mode_t)), this,
> > > SLOT(slotDirPartPopupMenu(const QPoint &, const KURL &, const QString
> > > &, mode_t)) );
> > >   connect(m_leftView->extension(), SIGNAL(selectionInfo( const
> > > KURL::List &)), this, SLOT(slotDirPartSelectionInfo(const KURL::List
> > > &)) );
> > >
> > >
> > > I get the popupMenu signals fine when I click with the right hand
> > > button on a file in the tree. But the selectionInfo signal, which I was
> > > hoping would be emitted whenever I selected a file, does not seem to
> > > be.
> >
> > Ok, that's a bug then ;-) I attached a patch. Does it help? If so, I'll
> > commit.
>
> I discovered the patch was not necessary. As you can see in the code above,
> I was connecting to the selectionInfo(const KURL::List&) signal not the
> selectionInfo(const KFileItemList &) signal. You patch made it clear this
> was wrong. So it works as long as you use the KFileItemList version of the
> signal. Can't see where it does it in the code though.
Hmm, strange, I overlooked that. Dunno why it works, though... I'll have a 
look.

> > Yes, but the things the part is doing can't be changed in any way I
> > guess... It just offers you a (hopefully) nice interface. Hmm, if you
> > miss something that could be useful for others as well I think it would
> > be no problem to add it to the KonqDirPart or friends. This was requested
> > some time ago anyways, IIRC.
>
> I'll take that as a free rein to re-write KonqDirPart in assembler :-)
Hehe...

> No seriously if this is the way to go then I'll look at modifying 
> KonqDirPart if I need something and submitting it.
Great.

> > > In addition, the lower level interface of the Konqueror tree
> > > view is not made public which doesn't help either.
> >
> > Hmm? What does this mean?
>
> Oh I just meant that you can only include konq_dirpart.h but not the
> konq_listview.h header that actual does the work.
Yes, that is what I meant.

> > > I haven't explored it in enough depth yet I admit, so maybe I'll
> > > discover more as I keep looking. But it's tempting just to go and write
> > > my own widget so I have control. I think what would be useful in KDE is
> > > a file tree view WIDGET that can be easily incorporated into
> > > applications, and subclassed to customise.
> >
> > Hmm, this could be the KonqTreeViewWidget.... As I said, it's just not
> > exported yet. Dunno why.
>
> Yes, I think something like this would be useful. And it would be useful in
> kdelibs - perhaps kdeui or kfile.
Nope, it can't be in kdelibs... it depends on libkonq and thus has to stay in 
kdebase, at least as long as libkonq is in kdebase. But that's not the real 
problem, the problem is that you can't include the header to use those 
classes.

> BTW is there any documentation on this? Would it be useful to write some?
> (Yes, I am volunteering...)
Hmm... don't know... IMHO there's already much docu ;-)) But if you find 
something undocumented you're always welcome to add some docu!

Ciao,
  Michael

-- 

       Some operating systems are called `user friendly',
             Linux however is `expert friendly'.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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