KDE/kdevelop/lib

[dukju ahn]

2007/5/18, Andreas Pakulat <apaku at gmx.de>:
> On 17.05.07 23:07:12, dukju ahn wrote:
> > 2007/5/13, Andreas Pakulat <apaku at gmx.de>:
> > > On 13.05.07 08:01:07, Matt Rogers wrote:
> > > >
> > > > hmm, I wonder if it wouldn't be better to have an interface for
> > > > filtering various process output so that the plugins can do their own
> > > > filtering. That's where it belongs, IMHO. What do others think?
> > >
> > > a plugin has a custom filtering class that implements IProcessFilter
> > > OutputView has then executeProcess(command-stuff, IProcessFilter*)
> > >
> > > I'm just not sure about the interface of IProcessFilter, but it
> > > certainly doesn't have to be an extension interface, IMHO.
> >
> > I also agree. I have rough thoughts about  interfaces.
> > And as andreas said, it shouldn't be an extension interface because it's just
> > a small helper class, not a plugin
> >
> > class OutputViewFilter
> > {
> >  // constructor
> >   OutputViewFilter( QList<QRegExp> );
>
> Whats the purpose of the regexp list here?

Oh, I was silly on this point. It will not reside on constructor argument.
QRegExp will be used internally by each implementation
of Filter( now factory). To determine " what type is this output from
KProcess?" and
" Am I interested on this output ", each implementation will maintain
a list of expressions.
But yes, we don't need to expose this in constructor.

> >  // 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.

> > Then each plugin will create their own QStdItem. For ex, makebuilder's filter
> > implementation may create some sort of MakeErrorItem*.
>
> That won't help much unless the view knows what to do with these special
> items (all the items can do themselves is saying how they want
> themselves displayed).

My comment above addresses this issue.