New System Settings

[Ben Cooksley]

On 5/23/09, Michael Jansen <kde at michael-jansen.biz> wrote:
> On Saturday 23 May 2009 02:02:01 Ben Cooksley wrote:
>
>> > 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.
>
> It probably was not documented but it was the way the code worked.
>
>
>>
>> >> > 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.
>
> I'm not in the position or mood to tell you what to do. Your are the one
> doing
> the coding. I just want to make sure you and everyone else understands the
> implications. We found out one module doesn't like the change. We only found
> out because it crashed. We have no idea how many subtile bugs are left out
> there. Many/Most of the kcm modules are more or less unmaintained like in
> noone really cares/works on them. They are kind of drive by maintained by
> many.

I am aware that most of the control modules are unmaintained, which is
really unfortunate.
However I briefly checked the KDE 3 KControl code and it appears to do
exactly the same thing that I am doing now I think. It was the
original System Settings that introduced this behaviour.

Unless the modules have been changed there should not be much of a problem.
The only modules this could affect are those that use global instances.
If it does actually cause problems I will revisit the issue and try to
create a safe resolution.

>
> If you say you keep it that way it is currently implemented i would expect
> you
> to take responsibility for bugs resulting of that. Whatever module is
> affected. I said expect not put it on you. It's up to you to decide. I can't
> tell you what to do. Or would want to do that.
>
> I just fear we get bug reports and noone cares.

I fear bug reports also. I didn't want to change the behaviour either
but it was needed to avoid  complication and edge cases.

>
> Mike
>
>

Ben