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

> -Original Message- > From: Thiago Macieira [mailto:thi...@kde.org] > [...] > Sounds good, but do we need this setEnabled() in the first place? Is it used > anywhere? It's meant to be used by a filter installed by QLoggingCategory::installFilter (see the example

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

On quarta-feira, 19 de abril de 2017 03:45:46 PDT Lubomir I. Ivanov wrote: > 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,

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

rg>; Kai Koehne <kai.koe...@qt.io> > Subject: Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as > a null device > > Em terça-feira, 18 de abril de 2017, às 09:23:12 PDT, Stefan Fuchs escreveu: > > /home/stefan/Entwicklung/Subsurface/marble- > source/src/li

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

Em terça-feira, 18 de abril de 2017 00:08:57 PDT você escreveu: > I will try it this morning. > Two remaining questions: > - What is the default state now if we don't set it explicitly? Enabled true > or false? Depends on the argument passed in the macro. With QtDebugMsg, it defaults to

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

Em terça-feira, 18 de abril de 2017, às 09:23:12 PDT, Stefan Fuchs escreveu: > /home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/MarbleDebug > .cpp:27:53: error: passing 'const QLoggingCategory' as 'this' argument of > 'void QLoggingCategory::setEnabled(QtMsgType, bool)' discards

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

Hello Lubomir, Am 18.04.2017 um 16:00 schrieb Lubomir I. Ivanov: > i must admit i followed Thiago's suggestions blindly. > Thiago, do you have an idea why this happens? > > the macro: > #define mDebug qCDebug(Marble::loggingCategory) > > expands calls like this one: > mDebug() << "innerRing:

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

On 18 April 2017 at 16:47, Stefan Fuchs wrote: > Hello Lubomir, > > Am 18.04.2017 um 13:22 schrieb Lubomir I. Ivanov: > > here are the updated Marble files and a patch diff for review. > i can't build Marble to test these changes ATM though. > > Looks good, so long as

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

On Tue, Apr 18, 2017 at 02:22:52PM +0300, Lubomir I. Ivanov wrote: > On 18 April 2017 at 10:08, Stefan Fuchs wrote: > > Hello Lubomir, > > > > > > Am 17.04.2017 um 23:53 schrieb Lubomir I. Ivanov: > > > > here are the updated Marble files and a patch diff for review. > > i can't

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

Hello Lubomir, Am 17.04.2017 um 23:53 schrieb Lubomir I. Ivanov: >>> here are the updated Marble files and a patch diff for review. >>> i can't build Marble to test these changes ATM though. >> Looks good, so long as "Marble::category" isn't too generic a name. >> > ok, i've renamed it to

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

On segunda-feira, 17 de abril de 2017 14:53:12 PDT Lubomir I. Ivanov wrote: > Stefan, could you please try building and running the attached patch? > you can toggle the debugging with MarbleDebug::setEnabled(true/false) > e.g. from the Subsurface source code. Or by setting in your environment:

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

On segunda-feira, 17 de abril de 2017 14:41:13 PDT Lubomir I. Ivanov wrote: > On 18 April 2017 at 00:18, Thiago Macieira wrote: > > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote: > >> i guess we could just do a: > >> void

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

On 18 April 2017 at 00:18, Thiago Macieira wrote: > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote: >> i guess we could just do a: >> void MarbleDebug::setEnabled(bool enabled) >> { >> Marble::loggingCategory.setEnabled(enabled); >>

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

On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote: > i guess we could just do a: > void MarbleDebug::setEnabled(bool enabled) > { > Marble::loggingCategory.setEnabled(enabled); > MarbleDebug::m_enabled = enabled; > } I'd go a little further and drop the m_enabled

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

On 18 April 2017 at 00:02, Lubomir I. Ivanov wrote: > On 17 April 2017 at 23:46, Thiago Macieira wrote: >> This disables the debug output for the default category, that is, every user >> of qDebug(). >> > > yep, i later figured that might happen. > >> I

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

On segunda-feira, 17 de abril de 2017 13:24:26 PDT Lubomir I. Ivanov wrote: > On 17 April 2017 at 22:29, Thiago Macieira wrote: > > On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov wrote: > >> QDebug mDebug() > >> > >> { > >> > >> return QDebug(

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

On 17 April 2017 at 22:29, Thiago Macieira wrote: > On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov wrote: >> QDebug mDebug() >> { >> return QDebug( QtDebugMsg ); // or "return qDebug();" >> } >> >> which will essentially enable debug output for

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

Hello Lubomir, Am 17.04.2017 um 21:01 schrieb Lubomir I. Ivanov: > your best bet is to change the function to this: > > QDebug mDebug() > { > return QDebug( QtDebugMsg ); // or "return qDebug();" > } > > which will essentially enable debug output for everything in Marble, > until we write a