KDE/kdevelop/lib

[dukju ahn]

2007/5/18, Andreas Pakulat <apaku at gmx.de>:
> > Yes. Maybe OutputViewItem will be the base class for item.
> > There are 6 signals that is emitted inside QAbstractItemView
> >       void activated ( const QModelIndex & index )
> >       void clicked ( const QModelIndex & index )
> >       void doubleClicked ( const QModelIndex & index )
> >       void entered ( const QModelIndex & index )
> >       void pressed ( const QModelIndex & index )
> >       void viewportEntered ()
> >
> > Except the viewportEntered(), the first 5 signals should have "slot"
> > at OutputviewItem.
> > Of course, I'm not saying that item should be a QObject. What I said is just
> > pure virtuals named activated() etc.
>
> I thought clicked and doubleClicked would be enough, but I guess that
> would give problems for plain keyboard usage so at least activated
> should be there too. Actually I think maybe activate is the only virtual
> we need, I mean do we really need different actions based on click or
> dobule-click? Also for keyboard-only navigation this sucks, because
> there you'll get only the activated signal.

The reason why we have 5 "slots" is for possible extensions. Currently
we can't imagine every various use-cases for outputview. Among the possible
use-cases, someone might want to treat entered() specially.
Then I have conclusion: only make activated() pure virtual, and
clicked() dblClicked()
are forwarded to call activated() by default. pressed() will be dropped.
entered() does nothing by default.
Then subclasses only have to implement activated()

That's it!