KDE/kdevplatform

David Nolden david.nolden.kdevelop at art-master.de
Mon Jul 27 14:35:52 UTC 2009


Am Montag 27 Juli 2009 16:19:20 schrieb Andreas Pakulat:
> On 27.07.09 15:46:05, David Nolden wrote:
> > Am Montag 27 Juli 2009 15:02:19 schrieb Andreas Pakulat:
> > > SVN commit 1002980 by apaku:
> > >
> > > Revert "Step towards 'useful' multiple-mainwindow support: Add an
> > > interface for plugins to create per-mainwindow actions, and
> > > manage+merge those actions within the additional mainwindow." and
> > > related commits.
> > >
> > > Its quite apparent that multi-mainwindow support isn't quite that easy
> > > to implement, so this should be done in a branch until its working -
> > > including conversion of all plugins.
> >
> > I don't see a reason why all plugins need to be converted at once. Each
> > added component that supports multiple mainwindows properly is a step
> > forward, and there should be no issues due to conversion, so it's
> > perfectly ok doing that in trunk.
>
> The problem I have with this is that we'll end up with some plugins
> supporting multi-mainwindows and some don't - eventually even in the first
> release if no-one feels like sitting down and converting them. I don't see
> a good reason to delay the conversion of all.
This way we can work out the API without having to change 40 plugins whenever 
changing it.
> > If there's is issues with KDE 4.2 then someone who has it needs to fix
> > that, as I don't have it. Moving it into a branch won't help that.
>
> The code in question is the same in KDE 4.3 and 4.2, I've looked into it
> that far already. So I'm lost within xmlgui as to why, using a separate
> branch at least keeps this stuff out of trunk for a while (and by then we'd
> probably depend on KDE 4.3).
>
> And if you cannot test this on our base requirement, then you cannot
> implement this in trunk. Forcing bugs onto other people and then asking
> them to fix them is not the right way to do development IMHO. Especially if
> "fixing" means spending a couple of hours of debugging.
This would be the moment to consider lifting the requirement to KDE 4.3 then.

> Regarding the actual crash: Loading the outputview plugin seems to be fine,
> but then loading the makebuilder crashes because the xmlgui client that is
> created from createGUIForMainWindow() apparently has non-null factory set
> (no idea where that comes from). And xmlgui then tries to remove the client
> from that factory when we add the client to the mainwindow.
It cannot be, where should that factory come from? This sounds more like it's 
just a bogus piece of memory, because the makebuilder plugin was not properly 
updated BC-wise. I've seen similar issues already. This would mean that some 
other random function in the plugin is called instead of 
createGUIForMainWindow, and that returned object then is interpreted as a 
KXMLGuiClient, of course leading to a crash.





More information about the KDevelop-devel mailing list