[Qgis-developer] prints to std::cout in qgis

[Radim Blazek]

On 4/3/06, nhugent at hispeed.ch <nhugent at hispeed.ch> wrote:
> Hi qgissers,
>
> I will have time to do the implementation of the logger class tomorrow. My suggestion is a header as below. QgsLogger would query the environment variables QGIS_DEBUG and (if set) QGIS_DEBUG_FILE and print out messages or not.
> The question is how the output should be controled by QGIS_DEBUG. One possibility would be to have QGIS_DEBUG=1 for fatal, QGIS_DEBUG=2 for fatal and critical, QGIS_DEBUG=3 for fatal, critical, warning, etc. If QGIS_DEBUG_FILE is set, only messages from that file will be printed. Else, messages from all files will be printed. What do you think?
>
> class QgsLogger
> {
> public:
>  static debug(QString msg, const char* file = 0, const char* function = 0);
>  static debug(QString var, int val, const char* file = 0, const char* function = 0);
>  static debug(QString var, double val, const char* file = 0, const char* function = 0); //goes to qDebug
>
>  static warning(QString msg); //goes to qWarning
>
>  static critical(QString msg); //goes to qCritical
>
>  static fatal(QString msg); //goes to qFatal
> }

I thought that  QGIS_DEBUG would only control debug messages
(not warning/critical/fatal) and the level could be optionaly defined in
overloaded methods (default level 1):
   static debug(int level, QString msg)
It is important for example to have a possibility to avoid debug from loops
through data, for example:

   debug("raster draw"); // level 1
   for each row {
        debug (2, "raster row"); //level 2
        for each col {
            debug (3, "pixel value"); //level 3
        }
   }

i.e. normaly on level 1 it will only print "raster draw", if there
are problems with rendering user can set higher level.

Could we also have a macro calling debug automaticaly with
__FILE__, __FUNCTION__, __LINE__
if available?

Radim

> Marco
>
> >On 3/22/06, Tim Sutton <tim at linfiniti.com> wrote:
> >> One other idea I could throw into the pot is to have a logger class. We
> >> could then set it up to write to console, to file or even in the future
> >> to some part of the gui. The latter could help when we have non
> >> technical users and windows users who experience problems - we can just
> >> ask us to send output from the logger window or whathaveyou. Log
> >> requests could be static methods or we could use qt signals and slots
> >> and connect the logger to objects being logged when they are
> >> instantiated. Example invocation mechanisms:
> >>
> >> emit logMessage("foo",QgsLogger::Critical);
> >> emit logMessage("foo",QgsLogger::Informational);
> >>
> >> or
> >>
> >> QgsLogger::logMessage("foo",QgsLogger::Critical);
> >> QgsLogger::logMessage("foo",QgsLogger::Informational);
> >
> >I prefer the second over emit. But it is too long, I would make it shorter:
> >
> >QgsLog::critical("foo");
> >QgsLog::info("foo");
> >QgsLog::debug(1,"foo"); // 1 is level controled by env. var.
> >
> >It is also often useful to print variable name - value pairs and
> >QString::number() is too long, so I would suggest also
> >
> >QgsLog::debug(int l, QString var, int val);
> >QgsLog::debug(int l, QString var, double val);
> >
> >Radim
> >
> >> Just another thought anyway...
> >>
> >> Regards
> >>
> >> Tim
> >_______________________________________________
> >Qgis-developer mailing list
> >Qgis-developer at lists.qgis.org
> >http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> >
> >
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>