[apaku at gmx.de: Re: KDE/kdevelop/lib/plugins/outputviews]

[Andreas Pakulat]

On 14.05.07 02:22:55, dukju ahn wrote:
> 2007/5/13, Andreas Pakulat <apaku at gmx.de>:
> > > 3. When excuting command, Model is now created inside addNewTab() along with QListView.
> >
> > Why did you do that?
> 
> The reason is related with momory free(delete).
> In previous version, OutputViewCommand didn't get deleted when it finishes
> its excution. So its memory leak. I added deleteLater() call inside
> the finished() slot.
> But the problem was that if the command owns model, the model is deleted inside
> OutputViewCommand's destructor, causing the outputview widget empty
> ( i.e. , If the model is deleted, the QListView becomes empty)

Ok, no problem, make the model a child of the plugin class and not of
the command.

> Also in model-view approach, I tought model and view should be created
> and delted
> in same location, because model is associated with view.

No, thats not true. Often after creating a model you also create a
view (to display the model), but wether this happens one line after
another or a few function-jumps away doesn't matter.

> > This breaks having multiple outputviews, now each
> > of the outputviews has its own models for the command-stuff. The models
> > need to stay at the plugin.
> 
> I didn't think about multiple outputviews. But there is solution.
> OutputViewcommand can have QList<Model*>. That way, every view can be
> updated simultaneously

How would a QList help here? I'd end up with multiple toolviews all
showing different things. And how should the outputview plugin decide
which model should be used to ouput. The MVC pattern is about having 1
model and multiple views on top of it. So the model needs to stay in the
plugin, so it can live longer than the Command. And then I can create
multiple toolviews all looking at the same outputs.

> > >  void OutputWidget::addNewTab(const QString& title, QStandardItemModel* model )
> > >  {
> > > -    if( !model || title.isEmpty() || m_listviews.contains( title ) )
> > > +    if( !model || title.isEmpty() )
> > >          return;
> > > -    QListView* listview = new QListView(this);
> > > -    listview->setModel( model );
> > > -    m_listviews[title] = listview;
> > > -    addTab( listview, title );
> > > +
> > > +    if( !m_listviews.contains( title ) )
> > > +    {
> > > +        QListView* listview = new QListView(this);
> > > +        listview->setModel( model );
> > > +        m_listviews[title] = listview;
> > > +        addTab( listview, title );
> > > +    }
> > > +    else
> > > +    {
> > > +        QListView* listview = m_listviews[title];
> > > +        listview->setModel( model );
> > > +    }
> > >  }
> >
> > Whats the reasoning for this? I don't see why we should replace the
> > model if somebody requests to add a tab with the same name as already
> > exists.
> 
> Because in this way, if sombody requests adding a tab with the previous name,
> it can start with a new model, discarding old model.

Why? Why not clearing out the model and re-using it? Also I think this
should rather be triggered by another flag to the queueCommand then
defaulting to clearing.

> > On 13.05.07 07:31:06, Dukju Ahn wrote:
> > > Porting ProcessLineMaker into KDev4. This wraps signal line-by-line, rather than emitting text whenever there is incomplete stdout/stderror.
> >
> > What does that class do? Can it process output of various types of
> > processes or just make? Does it make sense to produce an interface for
> > this so a buildmanager can hook up its own thing here.
> 
> It processes every kind of K3Process outputs.
> Regarding the filter thing, the concept of LineMaker is not filter. It
> just emit signal
> whenever a "completed" line was read.
> If K3Process reads some output but that's an incomplete line,
> normal K3Process would emit signal. But lineMaker
> waits until a completed one-line is captured. Only after one complete
> line is formed
> it emits signal.

Aaah, so this is not about filtering... 

> > Uhm, and now that we're reading line-by-line the outputview will be even
> > slower. Before we had the opportunity to use our own model to insert
> > multiple lines at once.
> 
> If we don't use LineMaker the following hypotetic situation may happen.
> 
> exec make
> gcc -c        // KProcess emits "gcc -c"
> somefile.c  // KProcess emits "somefile.c"
> 
> Then there would be 2 line in outputview.

Yes thats possible, but I think LineProcessMaker should still emit a
QStringList instead of one line after the other and just buffer the last
line if its not complete yet. Or we can do all of this in our own model,
when we replace QStandardItemModel.

> > >  install(FILES kdevexport.h DESTINATION ${INCLUDE_INSTALL_DIR}/kdevelop/)
> > > --- trunk/KDE/kdevelop/lib/kdevexport.h #664120:664121
> > > @@ -99,6 +99,7 @@
> > >  #define KDEVPLATFORMEDITOR_EXPORT KDE_EXPORT
> > >  #define KDEVPLATFORMLANGUAGE_EXPORT KDE_EXPORT
> > >  #define KDEVPLATFORMPROJECT_EXPORT KDE_EXPORT
> > > +#define KDEVUTIL_EXPORT KDE_EXPORT
> >
> > You just broke the windows build. Please add a proper line in the
> > win-part of kdevexport.h
> 
> OK I'll try

Shouldn't be hard, just copy/paste one of the existing ones and replace
with KDEVUTIL

Also please rename to kdevplatformutil everywhere (i.e. the library name
and the export macro) if you didn't use that already.

Andreas

-- 
Do not sleep in a eucalyptus tree tonight.