[PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Stefan Fuchs]

Hi again,

Am 20.04.2017 um 23:18 schrieb Stefan Fuchs:
>>> void MarbleDebug::setEnabled(bool enabled)
>>> {
>>>     QLoggingCategory::setFilterRules(QString("marble.debug=%1").arg(enabled
>>> ? "true", "false"));
>>> }
>>>
>>> and likely remove isEnabled() as it's not needed?
>> Sounds good, but do we need this setEnabled() in the first place? Is it used 
>> anywhere?
>>
> I did now a new MXE build based on Qt5.7.1 and marble code as it is
> right now in Subsurface-marble branch w/o any new changes like using
> the QLoggingCategory.
> I did some testing and for the moment I can't see the crash/"zombie"
> issue any more. So want to say that currently this update seems to be
> not that important for a possible upcoming release.
>
> Maybe it would be worthwhile to roll out this QLoggingCategory idea to
> the whole project including any logging messages from any component
> finally.
>
> I keep you updated when I again see a crash like before.
Ups, I made a mistake. Marble logging output was hardcoded off. Saw this
when starting Subsurface from a PS and played with commandline option
-v. Then it's clear why it doesn't crash any more. This is what we
already knew before...
So let's continue testing and let's try to implement that
QLoggingCategory thing somehow...

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfuchs at gmx.de <mailto:sfuchs at gmx.de>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170420/2e47e72f/attachment.html>