KDE/kdevelop/lib

[dukju ahn]

2007/5/13, Andreas Pakulat <apaku at gmx.de>:
> On 13.05.07 08:01:07, Matt Rogers wrote:
> >
> > On May 13, 2007, at 2:31 AM, Dukju Ahn wrote:
> >
> > > SVN commit 664121 by dukjuahn:
> > >
> > > Porting ProcessLineMaker into KDev4. This wraps signal line-by-
> > > line, rather than emitting text whenever there is incomplete stdout/
> > > stderror.
> > > To enable this, added KDEVUTIL_EXPORT macro.
> > > OutputView now uses ProcessLineMaker.
> >
> > 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> );

 // return StdItem that will be appended at outputview.
  QStandardItem* createItem( QString ) = 0;

 // return font that will be used by QStdItem
  QFont font( QString ) = 0;
};

Then each plugin will create their own QStdItem. For ex, makebuilder's filter
implementation may create some sort of MakeErrorItem*.

I doubt whether we really need font(), because we have createItem(). I
am also worry
that the class is not a filter, but actually a factory.

Any coments?