KDE/kdevelop/lib

[Andreas Pakulat]

On 18.05.07 03:46:20, dukju ahn wrote:
> 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.

But entered, clicked and doubleClicked only work for mouse use. What
about keyboard-only developers (like me)? For that we'd need to have an
event filter on the view and decide for some keys that should trigger
things like clicked/doubleClicked/entered.

IMHO we should first find a usecase for additional actions that should
be done here.

For example displaying a tooltip can be done by the view directly. One
thing we may want to have is something like contextMenuActions() on the
items, that way extension is still possible by providing a context menu.

Andreas

-- 
You will experience a strong urge to do good; but it will pass.