ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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.
2 | No.2 Revision |
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.
3 | No.3 Revision |
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.
4 | No.4 Revision |
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 doesn't restrict which logging ROS
' system. system to use.
Don't know if this attitude holds for the entire ROS
system though.
5 | No.5 Revision |
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.