ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Self response. Not a ROS general guideline/rule/best practice or anything but I found this could be a good example:

rqt's API review says,

2. Question / concerns / comments
:
2
(Dirk) I would propose to not integrate logging functionality into ROS GUI. All ROS plugins can use the ROS-specific logging functionality provided by the client libraries. A plugin similar to rxconsole can then be used to show/filter all these messages. Non-ROS plugins can decide if they want to use logging library or stick with the Qt functions qDebug, qWarning, qCritical.

So at least with rqt, we use ROS' logging system.

Don't know if this attitude is applicable to the entire ROS system globally though.

Self response. Not a ROS general guideline/rule/best practice or anything but I found this could be a good example:

rqt's API review says,

2. Question / concerns / comments
:
2
(Dirk) I would propose to not integrate logging functionality into ROS GUI. All ROS plugins can use the ROS-specific logging functionality provided by the client libraries. A plugin similar to rxconsole can then be used to show/filter all these messages. Non-ROS plugins can decide if they want to use logging library or stick with the Qt functions qDebug, qWarning, qCritical.

So at least with rqt, we use ROS' logging system.

Don't know if this attitude is applicable to holds for the entire ROS system globally though.

Self response. Not a ROS general guideline/rule/best practice or anything but I found this could be a good example:

rqt's API review says,

2. Question / concerns / comments
:
2
(Dirk) I would propose to not integrate logging functionality into ROS GUI. All ROS plugins can use the ROS-specific logging functionality provided by the client libraries. A plugin similar to rxconsole can then be used to show/filter all these messages. Non-ROS plugins can decide if they want to use logging library or stick with the Qt functions qDebug, qWarning, qCritical.

So at least with rqt, we use ROS' logging system.

Don't know if this attitude holds for the entire ROS system globally though.

Self response. Not a ROS general guideline/rule/best practice or anything but I found this could be a good example:

rqt's API review says,

2. Question / concerns / comments
:
2
(Dirk) I would propose to not integrate logging functionality into ROS GUI. All ROS plugins can use the ROS-specific logging functionality provided by the client libraries. A plugin similar to rxconsole can then be used to show/filter all these messages. Non-ROS plugins can decide if they want to use logging library or stick with the Qt functions qDebug, qWarning, qCritical.
qCritical. 
:
3. Conclusion
:
ROS GUI does not provide logging funtionality but relies on either the Qt or the ROS logging functions (following the KISS principle)

So at least with rqt, we use ROS' doesn't restrict which logging system. system to use.

Don't know if this attitude holds for the entire ROS system though.

Self response. Not a ROS general guideline/rule/best practice or anything but I found this could be a good example:

rqt's API review says,

2. Question / concerns / comments
:
2
(Dirk) I would propose to not integrate logging functionality into ROS GUI. All ROS plugins can use the ROS-specific logging functionality provided by the client libraries. A plugin similar to rxconsole can then be used to show/filter all these messages. Non-ROS plugins can decide if they want to use logging library or stick with the Qt functions qDebug, qWarning, qCritical. 
:
3. Conclusion
:
ROS GUI does not provide logging funtionality but relies on either the Qt or the ROS logging functions (following the KISS principle)

So at least rqt doesn't restrict which logging system to use.

Meanwhile in qt_gui_core, Qt's command qDebug is in use http://goo.gl/Oz5uU.

Don't know if this attitude holds for the entire ROS system though.