Merge lp://qastaging/~mrqtros/ubuntu-docviewer-app/ubuntu-docviewer-app-adv-logging into lp://qastaging/ubuntu-docviewer-app

PASSED: Continuous integration, rev:261
https://core-apps-jenkins.ubuntu.com/job/run-ap-tests-ci/129/
Executed test runs:
    None: https://core-apps-jenkins.ubuntu.com/job/generic-update-mp/404/console

Click here to trigger a rebuild:
https://core-apps-jenkins.ubuntu.com/job/run-ap-tests-ci/129/rebuild

Hey Roman!
In order to go on with the review, I need to ask you some question.

1) I see you've kept the #ifdef's. Shouldn't they be removed?

   Having a look at the KDE wiki at:
       https://techbase.kde.org/Development/Tutorials/Debugging/Using_Error_Messages#Improving_Logging_Output

   It looks like we'd need two steps in order to enable debugging output:
       1) Uncomment a #define entry in config.h
       2) Enable logging for a specific category (by default they're all disabled)

    I'd suggest to remove all the #define's and #ifdef's, and eventually add e.g.:
        QLoggingCategory::setFilterRules(QStringLiteral("RenderEngine.debug = true"));

    somewhere inside the plugin.

2) How do we like to filter the debug log? By class as you propose (e.g. "RenderEngine", "LODocument", etc.) or by scope (e.g. "TileBenchmark", "TileManagement", "Zoom", etc.)

3) Some of the debug in LODocument
       e.g. qCDebug(LoDoc) << "Loading document...";

   is information output rather than debug (I badly used qDebug() instead of qInfo()).

   Do we still want to make it optional? Could we use qInfo() or qCInfo()?

   I'm thinking at a scenario where something unexpected happens, and a user opens a bug report on Launchpad and upload the application log.
   Those basic informations wouldn't be available, and we would have to ask her to enable logging[1] for being able to say which area could generate the issue, and then (eventually) asking to enable some further category again.

   I consider this output useful for orienting my focus at first. I might as well be wrong!

[1] How can that be easily done on Ubuntu Touch, since everything is so confined?

Let's discuss it then :)

1) I should explore possibilities... To be honest, I was satisfied with text in output during debug, I thought that it was enough for us...
2) Seems that we should filter our output with groups. RenderEngine itself is a good category, LoDocument and LoView can be rethinked... The using of class name can be very handy since we have not so much classes and all of them are "core".
3) There is a thin difference between info and debug, I think, so every case is discussable, but not critical

1) Yes! If we could remove those #ifdef's from the code, it would look more linear/less bulky(TM) and it would be a great "double win".
However, I'd like to have something similar to the current config.h, so that we can toggle a more verbose output by uncommenting a single line. Which could be a suitable place for that?

2) Agree! "RenderEngine" is a good category. Others could be:
   - "TileBenchmark" in LODocument paint functions
   - "TileManagement" in LOView, for providing output about creation/removal/changes about the tile map and the visible/buffer areas
   - "ZoomEvents" for the automatic zoom management and events triggered by a change in the zoom value[1]
   - "VerboseOutput" for general information (e.g. error warnings) and something else we could add in future

3) "Loading document ..." and "Document loaded successfully !" may stay always visible.
   LODocument::loadDocument() is the place where the magical things happen (all the LibreOffice stuff are loaded there, and many 'events' in the plugin depend on a successful/failure of its execution).
   Having those two lines at the beginning/end of the function is more confortable for me. :)

[1] See for example "Zoom value of tiles is different than the current zoom value. Erasing cache..."
    This string could also be filtered by a "TileManagement" category, but it's not possible to assign a string to multiple categories, for what I see.