<div dir="ltr">Hi Andreas,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 2, 2013 at 8:33 AM, Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Larry,<br>
<br>
> I would love to know how that is possible. I've not seen a setup that<br>
> doesn't exhibit the issue yet. Maybe it slight enough that you just don't<br>
> 'see' it on manual visual inspection. Can you possibly run the current<br>
> limited labeling server test from the build dir on that machine (or one<br>
> with access to that web server)?<br>
><br>
> It is run individually with: ctest -R PyQgsPalLabelingServer -V<br>
<br>
I was trying to run the tests but am missing the test-projects - where<br>
can I get them or where are they located?<br></blockquote><div><br>Thank you for trying to setup the labeling server test.<br><br></div><div>When the tests for the server are run, the projects are generated on-the-fly and written to somewhere the server can read (see below). Also copied into that directory are the layer source data (small spatialite db) and predefined styles [0].<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I changes $HOME/.qgis2/qgis_local_server.cfg but don't know where I<br>
should point the "projdir" variable to.<br></blockquote><div><br></div><div>Right now it is a bit cumbersome because it relies upon configuring access to an existing, compatible QGIS Server setup.<br><br></div>
<div>This is from the error message for an unconfigured setup [1]:<br>  projdir = path WRITEABLE by this user and READABLE by www server<br></div><div><br></div><div>Once that's set up, you can test compatibility by manually populating the projdir with contents of [0] and editing under __main__ and running the following script directly (see recent commit [2]):<br>
  python qgis_local_server.py<br></div><div><br></div><div>A successful test of connection to configured test server should produce the following PNG [3]. This particular manual connection test is not (will not be) part of the QGIS ctest suite.<br>
<br></div><div>With this setup, you should ideally be testing against the qgis_mapserv.fcgi binary produced as part of building the desktop, though you can of course test against any existing fcgi process over a bound TCP/IP address. While there are good reasons to test against a production server, there are reasons definitely not to: <br>
<br></div><div>* Recent changes to the qgis_mapserv.fgi code will not be reflected.<br></div><div><br>* The test suite may move to spawning/restarting the fcgi binary often (to keep server's cache from affecting test output).<br>
<br>* Some settings (labeling engine debug settings, e.g. candidate rectangles) may persist on a long running fcgi process. Since restarting many servers involves root access and affects up-time, such automated tests should be relegated to a sandboxed, configured test server setup. <br>
<br></div><div>So, you can probably see why an automated, embedded and isolated spawn-fcgi utility, running under the user id of the test runner, greatly facilitates automated tests. (Should be committed in coming weeks.) I'll also look at posting my successful configurations for setting up QGIS Server under Nginx, which makes a nice sandbox setup (even alongside Apache), for testing qgisweb-client and wsgi as well.<br>
<br></div><div>Lastly, your server tests against the control images I made on my Mac will no doubt fail. Currently, multi-platform control images, to account for font handing differences, are not supported. You will probably want to set the env var PAL_CONTROL_IMAGE=1 and run:<br>
  ctest -R PyQgsPalLabelingCanvas -V && unset PAL_CONTROL_IMAGE<br><br>This will overwrite the canvas test output control images, so that you 
have a realistic comparison against the TestServerVsCanvas* classes' 
output, similar to loading your test server as a WMS layer in the 
desktop app. Just please do not commit your control images yet (unless as anomalies).<br><br></div><div>Alternatively, you can set the env var PAL_REPORT=1 and run `ctest -R PyQgsPalLabelingCanvas -V`. This should open any failed tests in your browser where you can choose to save your rendered images to the appropriate canvas control images directories, naming them as anomalies.<br>
</div><div><br></div><div>If you have even read this far  :^)  and are going through this setup, thank you very much. While it will be good to use an automated spawn-fcgi setup, there are definite benefits for testing against real-world web server setups, especially those managed by experienced users.<br>
<br><br></div><div>IMHO, until a test framework and a suite of many tests are finished, complex changes to labeling code should be ill-advised, and probably be postponed.<br><br></div><div>While it would be good to get funding from the community to complete this type of work, I understand how unglamorous this is compared with new features.<br>
</div><div><br>[0] <a href="https://github.com/qgis/Quantum-GIS/tree/master/tests/testdata/labeling">https://github.com/qgis/Quantum-GIS/tree/master/tests/testdata/labeling</a><br>[1] <a href="https://github.com/qgis/Quantum-GIS/blob/master/tests/src/python/qgis_local_server.py#L192">https://github.com/qgis/Quantum-GIS/blob/master/tests/src/python/qgis_local_server.py#L192</a><br>
[2] <a href="https://github.com/qgis/Quantum-GIS/commit/ff05ee06">https://github.com/qgis/Quantum-GIS/commit/ff05ee06</a><br>[3] <a href="http://drive.dakotacarto.com/qgis/test-connection.png">http://drive.dakotacarto.com/qgis/test-connection.png</a><br>
<br> <br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Andreas<br>
</blockquote></div><br></div></div></div>