Hi Tim,<br><br><div class="gmail_quote">On Mon, Apr 9, 2012 at 1:00 PM, Tim Sutton <span dir="ltr"><<a href="mailto:lists@linfiniti.com">lists@linfiniti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Larry<br>
<br>
On Mon, Apr 9, 2012 at 5:20 AM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com">larrys@dakotacarto.com</a>> wrote:<br>
> On Sun, Apr 8, 2012 at 7:48 PM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com">larrys@dakotacarto.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I've successfully generated QScintilla2 API files for the QGIS Python<br>
>> bindings and utility modules [0]. If you use the Eric4/5 Python editor (or<br>
>> another based on QScintilla2), you may be interested in installing and<br>
>> compiling these APIs.<br>
><br>
><br>
> Seems a better approach, instead of changing SIPMacros.cmake, would be in<br>
> python/CMakeLists.txt [0]:<br>
><br>> ...<br>
><br>
> This worked fine on compile, creating the same output as the SIPMacros.cmake<br>
> edit. Each SIP_EXTRA_OPTIONS could be wrapped with a conditional based on a<br>
> compile option for generating the APIs.<br>
><br>
<br>
Two quick comments:<br>
<br>
1) Could you submit your patch via github? If it is a cmake<br>
conditional compilation I see no reason to exclude it from master -<br>
others may have a different opinion.<br></blockquote><div><br>Sure. I'll sync my local master branch and test the edits (since I only tested builds of 1.7.4, which didn't have qgis.networkanalysis). I don't see any issue with leaving the changes as is, if the .api files are not going to be packaged with the target. Generation of the .api files does not seem to slow down the compilation, as far as I can tell.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) What I would really *love* is to have QGIS api completion (and<br>
other standard python modules if it is easy to achieve) in the built<br>
in python console that is activeated from the QGIS plugins menu. I<br>
often like to demo stuff to people using the python console and always<br>
flap around trying to remember syntax. Obviously this would add a<br>
qsctintilla dependency to QGIS core - how do others feel about this?<br>
Given the other work you are busy with that dependency is probably<br>
coming anyway....<br></blockquote><div><br> :^) Porting the QTextEdit of PyQGIS console.py to QScintilla was what I was going to look into next. I have already bootlegged it into Plugin Editor and done some customizations.<br>
<br>The Eric editor has a nice Python console based on QScintilla (syntax coloring, code completion and call tips), but I had difficulty trying to port it to Plugin Editor, because it leverages Eric's entrenched debugger classes. The ported base debugger I tried consistently crashed QGIS. Maybe it can be included in a later version.<br>
<br>Currently I have code completion and call tips working well in Plugin Editor [0]. The compiled API files I am testing with are:<br><br> PyQt4-Qt4.8.api, Python-2.7.api, QScintilla2.api<br> qgis.analysis.api, qgis.console.api, qgis.core.api, qgis.gui.api, qgis.utils.api<br>
<br>The compiled API 'python.pap' file for a given QScintilla editor widget is ~37,500 api items total, and 900 KB in size (yet is still quite responsive).<br><br>The IPython console is very powerful, but required compilation of ZeroMQ on my Mac. I think it would be great to add to Plugin Editor, but a QScintilla-based PyQGIS console, I think, would be a good first step.<br>
<br>Regards,<br><br></div></div>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota<br><br>[0] <a href="http://dl.dropbox.com/u/4058089/qgis/plugin-editor_qsci-autocompl-calltips.png">http://dl.dropbox.com/u/4058089/qgis/plugin-editor_qsci-autocompl-calltips.png</a><br>
<br>