New System Settings

Ben Cooksley sourtooth at gmail.com
Sat May 23 01:02:01 BST 2009


On 5/23/09, Michael Jansen <kde at michael-jansen.biz> wrote:
>
>> It was likely this that prevented the crash before.
>>
>> > Jansen on #kde-devel agreed with me that calling the
>> > constructor again is bad. And since it does not unload the plugin.
>>
>> All I do is create and destroy the KCModuleProxy, which ensures the
>> modules destructor is called ( It should anyway... )
>> Please see ModuleView::closeModules in systemsettings/core/ModuleView.cpp
>> I'm not sure how I can "unload" the plugin.
>
> You changed the behavious how modules are called. All Modules were developed
> with the assurance they are never unloaded. All modules were developed with
> the assurance load is called to reset them. The destructor would only be
> called if systemsettings was closed.

Sorry, but I can't find the assurance.... not in the KCModule or
KCModuleProxy documentation.
When I developed the Device Actions control module I was never made
aware of this, so it must have been before the KDE 4 era if it
happened at all.

>
>> > So is this a valid issue against the new system settings
>> > or i still should try to catch this bug in the kcm module?
>>
>> None of the other modules are affected, so the bug is likely in the KCM.
>
>
> I think you should keep that behaviour. We don't know how many bugs are
> still
> out there unnoticed because they don't lead to a crash.

It is impossible to keep the old behaviour, since it will cause
problems when a user opens a previously opened module after switching
views. That will lead to two instances of the module being
instantiated which is even worse, or the module failing to open saying
"Module already opened in System Settings" except they are in System
Settings.

If I made it a singleton, then I would have to reparent it as views
needed it, which would lead to a really nasty crash upon closing
because the module view would try to destroy the modules ( since they
would have to be held in a internal list of some description ) except
the reparented one had already been destroyed by Qt automatically.
Basically a really nasty can of worms, which will cause unneeded code
complication.

>
>
>
> Mike
>

Ben




More information about the kde-core-devel mailing list