KDE/kdevelop/lib

[Andreas Pakulat]

On 18.05.07 03:06:51, dukju ahn wrote:
> 2007/5/18, Andreas Pakulat <apaku at gmx.de>:
> > >  // return StdItem that will be appended at outputview.
> > >   QStandardItem* createItem( QString ) = 0;
> >
> > I guess the string is the string that should be displayed?
> 
> Not exactly. It is the RAW string that was grepped by KProcess. After
> some internal
> calculations and filtering, the displaying string will be determined
> by createitem().
> 
> > Also a standard item doesn't work here if we want to provide links to
> > source files or other things. We'd need something like clicked() and
> > doubleClicked() on the items so the view can let the item know they've
> > been clicked on and the item can then decide what to do (open editor
> > with a file at a specific position or whatever)
> 
> 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.

Other than that your idea sounds good to me.

Andreas

-- 
Are you ever going to do the dishes?  Or will you change your major to biology?