KDE/kdevelop/lib

[Andreas Pakulat]

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:
> > >
> > > 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> );

Whats the purpose of the regexp list here?

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

I guess the string is the string that should be displayed?
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)

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

What is this used for? The item already carries font information.

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

> I doubt whether we really need font(), because we have createItem().

Yeah, I don't think we need that either. We just need a way to create
the items and possibly have something other than a standard item at the
base.

> I am also worry that the class is not a filter, but actually a
> factory.

A factory is fine actually. Filter is not really the right name as a
filter normally removes some items from the whole list.

Andreas

-- 
Domestic happiness and faithful friends.