Re: Coding standard for qdebug in libs

[Boudewijn Rempt]

On Tue, 8 Sep 2015, Jaroslaw Staniek wrote:


On 8 September 2015 at 21:31, Friedrich W. H. Kossebau  wrote:

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:

With increasing modularity it's quite important
for our debugging needs to have logging categories.


Agreed.


A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()


+1 for that scheme. Simply because that namespace-prefixing seems to match the
usual namespace-prefixing as done with classes/files, don't see another reason
for/against.


I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).


That's sort of fine, I don't have a real preference there. I still think that
having one debug category per library is a limitation, and we'll need categories
for debugging functional areas, not libraries, and funcational areas over-arch
libaries (whether that's good architecture, I don't know...)



When I looked into debug porting for libs/ last week (still need to complete
end of next week, so anyone wants to take over meanwhile? no code yet written
here), I wondered if installed headers better should not include any debug-
only headers at all.


*debug.h should not be installed. I see that KF5 does not install own headers.


But with publix/exported templates which need/better have debug statements
that might be unavoidable. Still not really sure though, it somehow seems
dirty to me :)


Is there at least such a case in calligra.git? We can add a template
specialization and keep the implementation in .cpp.


KoResourceLoader, I think.

I'm now porting libs to qCDebug. After thinking about it a bit,
I really, really, really don't like

vectorImageDebug(),

I think that

debugVectorImage()

is clearer and more grammatical as well. That may just be because we've 
had dbgCategory in Krita for ten years now, but this is the form I would

prefer to use.


Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Boudewijn Rempt]

Oh, and about the file names, looks like there's no real standard yet:

boud@linux:~/kf5/src/frameworks> find . -name \*Debug\*h
./kactivities/src/service/Debug.h
boud@linux:~/kf5/src/frameworks> find . -name \*debug\*h
./krunner/src/declarative/krunner_debug.h
./krunner/src/krunner_debug.h
./networkmanager-qt/src/nmdebug.h
./threadweaver/src/debuggingaids.h
./kio/src/core/kiocoredebug.h
./kauth/src/kauthdebug.h
./kactivities/src/lib/core/debug_p.h
./kservice/src/sycoca/sycocadebug.h
./kwindowsystem/src/debug_p.h
./kjobwidgets/src/debug.h
./kdelibs4support/autotests/kdebug_unittest.h
./kdelibs4support/src/kdecore/kdebugdbusiface_p.h
./kiconthemes/src/debug.h
./sonnet/src/plugins/hunspell/hunspelldebug.h
./sonnet/src/plugins/voikko/voikkodebug.h
./khtml/src/ecma/debugger/debugdocument.h
./khtml/src/ecma/debugger/debugwindow.h
./khtml/src/ecma/kjs_debugwin.h
./baloo/src/file/baloodebug.h
./modemmanager-qt/src/mmdebug_p.h
./kconfig/autotests/kconfig_compiler/test_qdebugcategory_debug.h
./ktexteditor/src/utils/katepartdebug.h
./bluez-qt/src/debug.h

But most of it seems lower-case.


On Mon, 14 Sep 2015, Boudewijn Rempt wrote:


On Tue, 8 Sep 2015, Jaroslaw Staniek wrote:

On 8 September 2015 at 21:31, Friedrich W. H. Kossebau  

wrote:

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:

With increasing modularity it's quite important
for our debugging needs to have logging categories.


Agreed.


A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()


+1 for that scheme. Simply because that namespace-prefixing seems to match 

the
usual namespace-prefixing as done with classes/files, don't see another 

reason

for/against.


I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).


That's sort of fine, I don't have a real preference there. I still think that
having one debug category per library is a limitation, and we'll need 
categories
for debugging functional areas, not libraries, and funcational areas 
over-arch

libaries (whether that's good architecture, I don't know...)



When I looked into debug porting for libs/ last week (still need to 

complete
end of next week, so anyone wants to take over meanwhile? no code yet 

written
here), I wondered if installed headers better should not include any 

debug-

only headers at all.


*debug.h should not be installed. I see that KF5 does not install own 

headers.



But with publix/exported templates which need/better have debug statements
that might be unavoidable. Still not really sure though, it somehow seems
dirty to me :)


Is there at least such a case in calligra.git? We can add a template
specialization and keep the implementation in .cpp.


KoResourceLoader, I think.

I'm now porting libs to qCDebug. After thinking about it a bit,
I really, really, really don't like

vectorImageDebug(),

I think that

debugVectorImage()

is clearer and more grammatical as well. That may just be because we've 
had dbgCategory in Krita for ten years now, but this is the form I would

prefer to use.


Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Jaroslaw Staniek]

On 14 September 2015 at 10:46, Boudewijn Rempt  wrote:
> Oh, and about the file names, looks like there's no real standard yet:
>

Yes, no standards in kf5.

> boud@linux:~/kf5/src/frameworks> find . -name \*Debug\*h
> ./kactivities/src/service/Debug.h
> boud@linux:~/kf5/src/frameworks> find . -name \*debug\*h
> ./krunner/src/declarative/krunner_debug.h
> ./krunner/src/krunner_debug.h
> ./networkmanager-qt/src/nmdebug.h
> ./threadweaver/src/debuggingaids.h
> ./kio/src/core/kiocoredebug.h
> ./kauth/src/kauthdebug.h
> ./kactivities/src/lib/core/debug_p.h
> ./kservice/src/sycoca/sycocadebug.h
> ./kwindowsystem/src/debug_p.h
> ./kjobwidgets/src/debug.h
> ./kdelibs4support/autotests/kdebug_unittest.h
> ./kdelibs4support/src/kdecore/kdebugdbusiface_p.h
> ./kiconthemes/src/debug.h
> ./sonnet/src/plugins/hunspell/hunspelldebug.h
> ./sonnet/src/plugins/voikko/voikkodebug.h
> ./khtml/src/ecma/debugger/debugdocument.h
> ./khtml/src/ecma/debugger/debugwindow.h
> ./khtml/src/ecma/kjs_debugwin.h
> ./baloo/src/file/baloodebug.h
> ./modemmanager-qt/src/mmdebug_p.h
> ./kconfig/autotests/kconfig_compiler/test_qdebugcategory_debug.h
> ./ktexteditor/src/utils/katepartdebug.h
> ./bluez-qt/src/debug.h
>
> But most of it seems lower-case.
>
>
>
> On Mon, 14 Sep 2015, Boudewijn Rempt wrote:
>
>> On Tue, 8 Sep 2015, Jaroslaw Staniek wrote:
>>
>>> On 8 September 2015 at 21:31, Friedrich W. H. Kossebau 
>>
>> wrote:

 Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:
>
> With increasing modularity it's quite important
> for our debugging needs to have logging categories.


 Agreed.

> A scheme could be like
> {libnamelowercase}{Debug|Warning|Critical}()


 +1 for that scheme. Simply because that namespace-prefixing seems to
 match
>>
>> the

 usual namespace-prefixing as done with classes/files, don't see another
>>
>> reason

 for/against.

> I also propose to use a libname prefix for the header name. This is
> what many bits in KF5 do. So we won't have to deal with dozens files
> prefixed with "Debug" soon (so libpigment's DebugPigment.h could
> become PigmentDebug.h or pigment_debug.h).
>>
>>
>> That's sort of fine, I don't have a real preference there. I still think
>> that
>> having one debug category per library is a limitation, and we'll need
>> categories
>> for debugging functional areas, not libraries, and funcational areas
>> over-arch
>> libaries (whether that's good architecture, I don't know...)
>>

 When I looked into debug porting for libs/ last week (still need to
>>
>> complete

 end of next week, so anyone wants to take over meanwhile? no code yet
>>
>> written

 here), I wondered if installed headers better should not include any
>>
>> debug-

 only headers at all.
>>>
>>>
>>> *debug.h should not be installed. I see that KF5 does not install own
>>
>> headers.
>>>
>>>
 But with publix/exported templates which need/better have debug
 statements
 that might be unavoidable. Still not really sure though, it somehow
 seems
 dirty to me :)
>>>
>>>
>>> Is there at least such a case in calligra.git? We can add a template
>>> specialization and keep the implementation in .cpp.
>>
>>
>> KoResourceLoader, I think.
>>
>> I'm now porting libs to qCDebug. After thinking about it a bit,
>> I really, really, really don't like
>>
>> vectorImageDebug(),
>>
>> I think that
>>
>> debugVectorImage()
>>
>> is clearer and more grammatical as well. That may just be because we've
>> had dbgCategory in Krita for ten years now, but this is the form I would
>> prefer to use.
>>
>>
>> Boudewijn
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Friedrich W. H. Kossebau]

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:
> With increasing modularity it's quite important
> for our debugging needs to have logging categories.

Agreed.

> A scheme could be like
> {libnamelowercase}{Debug|Warning|Critical}()

+1 for that scheme. Simply because that namespace-prefixing seems to match the 
usual namespace-prefixing as done with classes/files, don't see another reason 
for/against.

> I also propose to use a libname prefix for the header name. This is
> what many bits in KF5 do. So we won't have to deal with dozens files
> prefixed with "Debug" soon (so libpigment's DebugPigment.h could
> become PigmentDebug.h or pigment_debug.h).

When I looked into debug porting for libs/ last week (still need to complete 
end of next week, so anyone wants to take over meanwhile? no code yet written 
here), I wondered if installed headers better should not include any debug-
only headers at all.
But with publix/exported templates which need/better have debug statements 
that might be unavoidable. Still not really sure though, it somehow seems 
dirty to me :)

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Jaroslaw Staniek]

On 8 September 2015 at 21:31, Friedrich W. H. Kossebau  wrote:
> Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:
>> With increasing modularity it's quite important
>> for our debugging needs to have logging categories.
>
> Agreed.
>
>> A scheme could be like
>> {libnamelowercase}{Debug|Warning|Critical}()
>
> +1 for that scheme. Simply because that namespace-prefixing seems to match the
> usual namespace-prefixing as done with classes/files, don't see another reason
> for/against.
>
>> I also propose to use a libname prefix for the header name. This is
>> what many bits in KF5 do. So we won't have to deal with dozens files
>> prefixed with "Debug" soon (so libpigment's DebugPigment.h could
>> become PigmentDebug.h or pigment_debug.h).
>
> When I looked into debug porting for libs/ last week (still need to complete
> end of next week, so anyone wants to take over meanwhile? no code yet written
> here), I wondered if installed headers better should not include any debug-
> only headers at all.

*debug.h should not be installed. I see that KF5 does not install own headers.

> But with publix/exported templates which need/better have debug statements
> that might be unavoidable. Still not really sure though, it somehow seems
> dirty to me :)

Is there at least such a case in calligra.git? We can add a template
specialization and keep the implementation in .cpp.

Thanks for the review.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Jaroslaw Staniek]

On 5 September 2015 at 13:41, Boudewijn Rempt  wrote:
> There is one more thing about logging using qCDebug and friends:
> the logging categories are supposed to be defined _per library_.
>
> Which is actually pretty useless and not really how we've been
> using categories in Calligra. Logging categories for file
> handling, resource management or plugin handling that can be used
> across libraries and applications make it possible to focus on
> debugging a path through the application's execution.
>
> I don't debug pigment, I debug color management, for instance, which
> is present in pigment, the colorspace plugin and parts of Krita.
>
> That's why for Krita, I made a generic debug interface in a little
> global library that knows about all the categories and that can
> be used from everywhere.

Yeah that's OK too, case by case. Names for these cross-libs
categories can be invented too.

Similarly, for database-reladed stuff we even have a GUI logger:
http://i.imgur.com/9bfljqF.png


> Oe Sat, 5 Sep 2015, Jaroslaw Staniek wrote:
>
>> Hi,
>> This is a proposal for some consistency for naming of debug functions,
>> debug headers and logging categories.
>> I'll be trying to achieve in code I maintain. I can put some
>> guidelines on the dev wiki.
>>
>> Details:
>> After looking at recent commits such as Friedrich's 1dddbcdbceab0
>> "kWarning -> warnPigment" I was wondering if we want to have standards
>> for debug handling.
>> I don't use one in Kexi, not yet, but use one in
>> kdb/kreport/kproperty. With increasing modularity it's quite important
>> for our debugging needs to have logging categories.
>>
>> A scheme could be like
>> {libnamelowercase}{Debug|Warning|Critical}()
>>
>> e.g. I use kdbDebug() << ... ;
>>
>> Note, for clarity () is used here too like in qDebug().
>> See kdb_debug.h
>> https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.h
>>
>> Furthermore, in kde_debug.cpp
>> [https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.cpp] I
>> have:
>> Q_LOGGING_CATEGORY(KDB_LOG, "org.kde.kdb.core")
>>
>> Note that you can pick your scheme for string, e.g.
>> org.kde.calligra.{someapp} or org.calligra.{someapp}
>> and for libs org.kde.{somelib}. It's important to have it unique and
>> relatively short. Planning for future expansion is a good way too.
>>
>> For tests and example apps it may be enough to use default debug or
>> for big code decide to add special category too.
>>
>> I also propose to use a libname prefix for the header name. This is
>> what many bits in KF5 do. So we won't have to deal with dozens files
>> prefixed with "Debug" soon (so libpigment's DebugPigment.h could
>> become PigmentDebug.h or pigment_debug.h).
>>
>> PS: I am aware e.g. KF5 has various approaches there, use qDebug()
>> with no categories, use qCDebug without defines.
>> We have not fully migrated to logging categories in apps and internal
>> libs so I thought it may be cool to think about consistency early
>> enough.
>>
>> --
>> regards, Jaroslaw Staniek
>>
>> KDE:
>> : A world-wide network of software engineers, artists, writers,
>> translators
>> : and facilitators committed to Free Software development - http://kde.org
>> Calligra Suite:
>> : A graphic art and office suite - http://calligra.org
>> Kexi:
>> : A visual database apps builder - http://calligra.org/kexi
>> Qt Certified Specialist:
>> : http://www.linkedin.com/in/jstaniek
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Coding standard for qdebug in libs

[Boudewijn Rempt]

There is one more thing about logging using qCDebug and friends:
the logging categories are supposed to be defined _per library_.

Which is actually pretty useless and not really how we've been
using categories in Calligra. Logging categories for file
handling, resource management or plugin handling that can be used
across libraries and applications make it possible to focus on
debugging a path through the application's execution.

I don't debug pigment, I debug color management, for instance, which
is present in pigment, the colorspace plugin and parts of Krita.

That's why for Krita, I made a generic debug interface in a little
global library that knows about all the categories and that can
be used from everywhere.


Boudewijn


Oe Sat, 5 Sep 2015, Jaroslaw Staniek wrote:


Hi,
This is a proposal for some consistency for naming of debug functions,
debug headers and logging categories.
I'll be trying to achieve in code I maintain. I can put some
guidelines on the dev wiki.

Details:
After looking at recent commits such as Friedrich's 1dddbcdbceab0
"kWarning -> warnPigment" I was wondering if we want to have standards
for debug handling.
I don't use one in Kexi, not yet, but use one in
kdb/kreport/kproperty. With increasing modularity it's quite important
for our debugging needs to have logging categories.

A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()

e.g. I use kdbDebug() << ... ;

Note, for clarity () is used here too like in qDebug().
See kdb_debug.h https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.h

Furthermore, in kde_debug.cpp
[https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.cpp] I
have:
Q_LOGGING_CATEGORY(KDB_LOG, "org.kde.kdb.core")

Note that you can pick your scheme for string, e.g.
org.kde.calligra.{someapp} or org.calligra.{someapp}
and for libs org.kde.{somelib}. It's important to have it unique and
relatively short. Planning for future expansion is a good way too.

For tests and example apps it may be enough to use default debug or
for big code decide to add special category too.

I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).

PS: I am aware e.g. KF5 has various approaches there, use qDebug()
with no categories, use qCDebug without defines.
We have not fully migrated to logging categories in apps and internal
libs so I thought it may be cool to think about consistency early
enough.

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel