Re: [Qgis-developer] Shipping SAGA with QGIS
On Sun, Feb 24, 2013 at 10:19 AM, Phil Hess macp...@fastermac.net wrote: I don't know why this path is different in QGIS than in Python launched from a Terminal command line, If you are talking about OS X, then `.app` bundles don't inherit environment variables from the same places Terminal apps do (i.e they don't pay attention to `~/.profile` and such). There is a good answer on StackOverflow that runs through the possible places to set environment variables: http://stackoverflow.com/a/4567308/135870 -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Shipping SAGA with QGIS
On Sun, Feb 24, 2013 at 11:07 AM, Phil Hess macp...@fastermac.net wrote: If you are talking about OS X, then `.app` bundles don't inherit environment variables from the same places Terminal apps do You are correct, sir, although in testing I see that it's not really a difference between .app GUI apps and console apps, Bad wording on my part. The difference I was pointing out is indeed between stuff that is launched through the desktop, including methods like double click and stuff that is launched through the command line, including methods like running open. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Releasing 1.8
On Fri, Jun 1, 2012 at 11:23 AM, Giovanni Manghi giovanni.man...@faunalia.pt wrote: Hi, It seems to me that the package is in good shape. All blocking issues are fixed, apart from a dubious one: http://hub.qgis.org/issues/5692 Should we go on and releasing 1.8? I agree, in the last days a few regressions have surfaced but thanks to the effort of many people they have been fixed. Today it has been reported #5692 that would need a check by OsX users and packagers as it seem to occur only on Mac. I have also been getting build errors from the master branch on several OS X installations due to misconfigured library loading paths: [ 39%] Building CXX object src/gui/CMakeFiles/qgis_gui.dir/symbology-ng/qgssinglesymbolrendererv2widget.cpp.o dyld: Library not loaded: @executable_path/../Frameworks/qgis_core.framework/Versions/1.8/qgis_core Referenced from: /private/tmp/homebrew-qgis-HEAD-MyK5/build/src/crssync/../../output/bin/crssync Reason: image not found I'll try to dig in this weekend and nail the problem down. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] stupid git
On Wed, Apr 4, 2012 at 10:11 PM, Nathan Woodrow madman...@gmail.com wrote: On Thu, Apr 5, 2012 at 1:13 PM, William Kyngesburye wokl...@kyngchaos.com wrote: No matter how much people rave about git, I still find it more difficult than svn. Of course, it's a completely different beast. Git being distributed vs the central svn makes things a lot more powerful but a little bit harder. So, my local release-1_8 branch refuses to merge and I can't backport my install doc updates from master. I think I successfully did a reset, but trying to push my commit gives a error about a non-fast-forward updates. The following should get your local release tree back into line with upstream (main git repo) release-1_8 git checkout release-1_8 git fetch upstream git reset --hard upstream/release-1_8 git rebase upstream/release-1_8 After a hard reset, the local branch _will be exactly the same_ as the remote branch. After this, a rebase is pointless as there are no commits unique to the local branch that can be replayed on top of the remote. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GRASS provider issue on OS X needs attention
On Mon, Apr 2, 2012 at 9:50 AM, Giuseppe Sucameli brush.ty...@gmail.comwrote: I understand your point of view, but if OSX users agree the plugin is useful they should also consider to sponsor the fix. What broke the plugin in the first place? It appears to be working fine in 1.7.4. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OS X 1.7.4... bomb
On Sat, Feb 25, 2012 at 7:24 AM, William Kyngesburye wokl...@kyngchaos.comwrote: So I finally packaged QGIS 1.7.4 (I was waiting on a GRASS 6.4.2 problem, but that may take a while). And... Just out of curiosity, what is the problem you are experiencing with GRASS? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] user map points
On Sun, Feb 19, 2012 at 12:58 PM, Paolo Cavallini cavall...@faunalia.itwrote: Il 19/02/2012 21:47, Paolo Cavallini ha scritto: Hi all. I need the points of users displayed in: http://planet.qgis.org/**community-map/http://planet.qgis.org/community-map/ Whom can I ask to? Would it be ok to have the data downloadable from the site? Thanks. Maybe also the IP data? http://spatialgalaxy.net/2011/**12/19/qgis-users-around-the-**world/http://spatialgalaxy.net/2011/12/19/qgis-users-around-the-world/ Looks like the data is just sitting in the HTML ~line 104 as an array of WKT points. Copy, paste, run through jsonpretty and rock out. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Mac OS Build Architecture Setting?
On Thu, Feb 16, 2012 at 5:13 PM, Dan Dittmann q...@dandittmann.org wrote: I have been attempting to build theversion 1.9 of QGIS for Mac OS 10.7.3 and have been unable to complete the compile. I suspect the problem likely is an architecture setting which I am overlooking. Based on the errors pasted below, is it an architecture setting or something else? The output from cmake appears to imply everything is ok dependency wise. The log from cmake is at the bottom. I am attempting the build with a mix of William Kyngesburye's libraries and MacPorts Libraries. Below I have included what I am using for cmake and the build. ..snip.. Linking CXX shared module ../../../PlugIns/qgis/libogrprovider.so Undefined symbols for architecture x86_64: _OGR_L_SetIgnoredFields, referenced from: QgsOgrProvider::setRelevantFields(bool, QListint const)in qgsogrprovider.cpp.o _OGR_L_DeleteField, referenced from: QgsOgrProvider::deleteAttributes(QSetint const)in qgsogrprovider.cpp.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [PlugIns/qgis/libogrprovider.so] Error 1 make[1]: *** [src/providers/ogr/CMakeFiles/ogrprovider.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs ..snip.. The _OGR_L_* symbols are part of libgdal. Looks like you have a 32-bit version of GDAL running around that is getting in the way of the build. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Mac OS Build Architecture Setting?
On Thu, Feb 16, 2012 at 8:15 PM, William Kyngesburye wokl...@kyngchaos.comwrote: Maybe. But if so, then qgis_core would have failed also, since that links GDAL also and is compiled first. One thing to try is a simple make. Sometimes the parallel compilation can get ahead of itself (maybe some dependency isn't properly waited for?) and you get errors. Also, to see all the gory details of the compilation (may help figure out if some other GDAL is linking), add this to the cmake configuration: -D CMAKE_VERBOSE_MAKEFILE=true That's the problem with having more than one copy of a library running around---you never know when it will work its way into the build system. It is entirely possible that the linker got fed one set of paths that listed the 64 bit version when compiling qgis_core and another set of paths that listed the 32 bit version when compiling the OGR Provider. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
On Fri, Jan 13, 2012 at 3:41 AM, CzendaZdenda tramt...@seznam.cz wrote: Hi all, have someone experiences with VisTrails (VT)? According the discuss on ML about using it for a workflow builder I have spent some times with VT. And I started think about using external library or write it without dependencies on it. As Paolo mentioned: I think we better avoid external dependencies unless necessary. Furthermore, I do not know VT, but it seems far from production-ready, and its scope seems to considerably overlap that of QGIS. That's right. VT is more than we need and now it's not good for integrated into another program. For me looks better to write workflow builder without dependencies, just with using Qt and its Graphics View Framework. So what do you think about it? Regards, Zdenek Has anyone considered adapting the Orange framework for this task? http://orange.biolab.si/features.html Orange is written in Python and provides dataflow analysis through a connect the boxes interface similar to the ArcGIS model builder. There could be some good ideas there that QGIS can adopt. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS Processing Framework
On Fri, Jan 13, 2012 at 12:26 PM, Tim Sutton li...@linfiniti.com wrote: What Graphical toolkit are they using? VT has the advantage of being Qt based too so from that respect it is probably a better match for integration into QGIS. Czenda, I know some folks who have been using VT with QGIS quite a lot - pop me a note if you would like me to put you in contact with them. Regards Tim As far as I can tell, Orange is based on PyQt as shown by the main GUI class: http://orange.biolab.si/svn/orange/trunk/orange/OrangeCanvas/orngCanvas.pyw -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] editing PostGIS tables
On Tue, Dec 13, 2011 at 11:29 AM, Maxim Dubinin s...@gis-lab.info wrote: Hi all, I've tried editing PostGIS table in QGIS today, to my total frustration. This video should be self-explanatory: http://screencast.com/t/V9APNmkz1 Maxim Ouch. Which version of QGIS and which version of PostGIS were you using? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QIGS GPL - LGPL - Tigers, Lions and Bears Oh My!
On Thu, Nov 17, 2011 at 1:22 AM, Noli Sicad nsi...@gmail.com wrote: OK. I understand now. However, if you sell the plugin or give it to the third party, then this is consider - public release, right? Thanks for the clarification. Noli No, it is a release to that third party only---although they retain the rights to turn around and re-release to whomever they choose. A public release usually involves posting the binaries and source code on a publicly accessible website. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QIGS GPL - LGPL - Tigers, Lions and Bears Oh My!
On Wed, Nov 16, 2011 at 10:58 PM, Tim Sutton li...@linfiniti.com wrote: The question you raise has been raised before and we have always said no. The reason for this is that we want to ensure that the commitment we have made to provide a Free and open source GIS available to everyone does not get diluted by people further down the line who want to essentially leverage our work without contributing anything back. It seems like many developers were in favor of at least allowing for proprietary plugins back in 2006: http://www.osgeo.org/pipermail/qgis-developer/2006-September/000708.html Perhaps licensing the API under LGPL would be feasible? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] More git troubles ...
On Mon, Nov 14, 2011 at 5:41 AM, Andreas Neumann a.neum...@carto.netwrote: Hi git cracks! My git troubles continue ... Now I wanted to do a normal read-only clone to start everything from scratch and I get this error message: Here is my command: git clone https://github.com/qgis/**Quantum-GIS.githttps://github.com/qgis/Quantum-GIS.git here is the error message: Cloning into Quantum-GIS... warning: remote HEAD refers to nonexistent ref, unable to checkout. Does it mean that cannot find a master? Do I have to checkout a specific branch? I just want the current master (1.9.x). Thanks for any help/hints! Andreas If something is wrong with the https URL, drop the GitHub guys a support request: https://github.com/contact Because it should work and if it doesn't there may be a bug on their end. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Announcing an IPython plugin
New (Experimental!) Plugin I just uploaded an alpha version of a plugin that allows an IPython kernel to be integrated into QGIS. This in turn allows external IPython-powered consoles to connect to QGIS and execute commands or inspect data. Version 0.2 of the plugin is now available from PyQGIS and is flagged Experimental: http://spatialserver.net/pyqgis_1.0/contributed/ipython_console.zip I am making the announcement here, because I feel that the current state of the plugin makes it most interesting to developers. I have tested the plugin with QGIS 1.7.0 on OS X 10.6 and Ubuntu 11.4 and it appears to be usable. Bug reports and pull requests are welcomed at GitHub: https://github.com/Sharpie/qgis-ipython What is IPython? = IPython is a __really__ nice shell for performing interactive work in the Python programming language. Some killer features IPython provides compared to the standard Python console are: - Tab completion for object and method names. - Function call tips that provide information about arguments on-the fly. - Easy access to docstrings. - magic commands that allow users to turn complex function calls into simple, customized command lines. Additionally, the v0.11 release completely re-factored the project and brought about many exciting changes: - A distributed two-process system where computational kernels handle the details of executing code and may be controlled by one or more console processes that handle the details of sending user input and formatting kernel output. - A new PyQt-based console with plenty of neat tricks such as Pygments-based highlighting of source code and inline display of Matplotlib graphs. - A high-level framework for performing parallel computing in an interactive fashion. For more information about IPython, see: The IPython website: http://www.ipython.org The manual section on interactive computing: http://ipython.org/ipython-doc/stable/interactive/index.html A talk by Fernando Perez at SciPy 2011 which details many features of v0.11: http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel How Does the Plugin Work? = The IPython plugin requires following dependencies to be installed: - Python 2.6 or 2.7 - IPython v0.11 or v0.12-dev - PyZMQ - Pygments - Matplotlib Unfortunately, Windows users are currently out of luck as QGIS appears to be pinned to the version of Python provided by OSGEO4W which is currently at 2.5.x. The plugin provides one new entry to the Plugins menu called External IPython Console. This launches an external process, based on `ipython-qtconsole`, that communicates with an IPython kernel __running inside of QGIS__. This means that every command entered through the console is actually executed inside of QGIS. The only downside I have noticed to running the console in a process separated from QGIS is that the IPython console window cannot be docked or otherwise integrated into the QGIS GUI. __IMPORTANT NOTE__ One currently has to be careful when closing external Python consoles because they can terminate the IPython kernel running inside of QGIS which has the unfortunate side effect of causing QGIS to quit. The recommended way to shut down an external console is to close the window and select No, just this Console when asked if you would like to quit the Kernel. Choosing Yes, quit everything or running the `exit()` command in the IPython shell will cause QGIS to quit as well. I am working on finding a way around this issue so that it will be more difficult for users to accidentally terminate QGIS when all they wanted to do was close the IPython console. Future Directions = There are plenty of things that need to be cleaned up in order to achieve a smoother user interface such as better error messages and figuring out how to handle situations where the kernel dies and needs to be restarted. There are also many exciting possibilities that could be explored such as using the parallel computing framework to build faster tools for GIS analysis or using the IPython communication protocol make it easier for other programs to communicate with QGIS. If QGIS upgrades to version 2 of the SIP API, another exciting development possibility is to replace the current Python console with an IPython console that does not run in a separate process. I have done some initial work on this front and managed to get a proof-of-concept build that successfully ran the IPython console: https://github.com/Sharpie/Quantum-GIS/tree/ipython-console The biggest challenge in upgrading to version 2 of the SIP API appears to finding areas in the Python code where QString methods are used and replacing them with equivalent Python string methods. The branch above is very much an experiment---many things were simply commented out. -Charlie ___
Re: [Qgis-developer] OS X Lion (and other) status
On Sun, Aug 14, 2011 at 9:17 AM, William Kyngesburye wokl...@kyngchaos.comwrote: Well, I've finally made it to QGIS in my Lion upgrade. QGIS compiled for Snow Leopard seems to work fine on Lion, though it will continue to use Python 2.6. As for Lion compilation and use, some notes... - (not really Lion-only - all OSX versions) cmake 2.8.5 is broken for detecting Qt4 frameworks. Fixed in dev, so until 2.8.6 is released use 2.8.4. If you ever want to use 2.8.5, here is the relevant patch that will fix the Qt Framework issues: http://cmake.org/gitweb?p=cmake.git;a=patch;h=702538eaa3315f3fcad9f1daea01e6a83928967b Apply before building CMake and everything should be good to go. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Breaking API and merge of threading branch
On Wed, Aug 10, 2011 at 3:32 AM, Tim Sutton li...@linfiniti.com wrote:
I think the fact that we are going to break API in 2.0 is well known
and discussed often in releases, blogs, qgis hackfests etc. and is a
general expectation when performing a major version numbering change.
I think your approach is good (tag last api compatibility etc). As far
as I am concerned we can go ahead with API breakage today. There are a
number of other gut wrenching changes I would like to make for 2.0:
- change theme to 'gis' theme by default
- get rid of kids theme
- rename default theme to 'legacy'
- remove all deprecated api calls
Many parts of our api have developed inconsistencies and I would like
to spend some time putting my 'rpl' binary to good use trying to clean
these up before we release. I think we should continue the practice of
marking new api additions / changes with a @note added in 2.0 or
@note replaces getLayerId in 2.0 etc. as far as possible so that
people can adapt to our changes easily.
Anyway +1 for API breakage from me - we will continue maintaining
1.7.x for now anyway for those looking for stability. The number of
things we can reasonable backport will shrink as we mess with the API
but I don't see the impact to be too big.
Regards
Tim
Since backwards-incompatible changes are being discussed, may I also suggest
that we update PyQGIS to use version 2 of the SIP apis for QString and
QVariant?
The version 2 API is much more Pythonic and has better support for Unicode
and Python 3. It is also the only version that is compatible with PySide.
Because of this, many GUI components that use the Enthought scientific
python modules are only compatible with version 2 of the SIP APIs. Notable
projects include Matplotlib and IPython.
More information on why using API v2 is a good idea can be found here:
http://www.pyside.org/docs/pseps/psep-0101.html
Updating to the new SIP API should be a simple matter of adding:
import sip
sip.setapi('QString', 2)
sip.setapi('QVariant', 2)
To the startup routine for the Python kernel before any PyQt libraries are
added. All Python plugins that use QString or QVariant would have to replace
these with plain Python strings and dicts.
Thoughts?
-Charlie
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qwt now required?
On Wed, Jul 13, 2011 at 3:55 PM, Dave Johansen davejohan...@gmail.comwrote: I'm using QGIS 1.5 embedded in a Qt application and I currently don't have Qwt installed on the system. I just download QGIS 1.7 and tried building it on my system, but it complained about QWT not being found. I read through the release announcements from 1.6 and 1.7 and neither of them mentioned that QWT was now required, but was that fact inadvertently left out? Thanks, Dave I believe this may be a bug with the 1.7 Windows build. When I do the following on Windows 7: Start Menu - Quantum GIS Wroclaw - Quantum GIS (1.7.0) QGIS starts up fine. If I then pin QGIS to my taskbar and try to start it by clicking on the icon, I get an error message: The program can't start because qwt5.dll is missing from your computer. So, try starting QGIS through the Start Menu and see if it makes a difference. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qwt now required?
On Wed, Jul 13, 2011 at 4:13 PM, Dave Johansen davejohan...@gmail.comwrote: Sorry I forgot to mention this in the original email, but I'm actually building from source on RHEL 5.5, and I'm running into the issue when trying to configure the build process with ccmake during the initial setup. Dave Ahh... I think QWT has always been required---at least since I started building QGIS from source at version 1.6. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qwt now required?
On Wed, Jul 13, 2011 at 4:33 PM, Dave Johansen davejohan...@gmail.comwrote: I've built 1.0 and 1.5 without QWT, so I'm guessing that it became required in 1.6. In the release announcement of 1.6 ( http://blog.qgis.org/node/146 ), it states Replaced raster histogram implementation with one based on Qwt, so I'm guessing that that might be where the dependence came from. It's kind of unfortunate that it became a required dependence for such a small addition, but apparently that's the case and I'll just have to get it installed on all my machines before upgrading to 1.7. Thanks, Dave I would recommend building and installing PyQwt: http://sourceforge.net/projects/pyqwt/ It bundles its own copy of Qwt 5.2.1 and is required by some QGIS plugins. QGIS 1.7.0 will not compile against QWT 6.0.0. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis mobile configure log
On Sun, Jul 10, 2011 at 6:40 PM, Noli Sicad nsi...@gmail.com wrote: On 7/11/11, Marco Bernasocchi ma...@bernawebdesign.ch wrote: -- SWIG is not found SWIG is not found - for SIP and PyQt? Noli I don't think SIP depends on SWIG---it completely replaces the functionality of SWIG for creating Python bindings. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PySide (instead of PyQt) for QGIS mobile (Android) plugins
On Sat, Jul 9, 2011 at 5:39 PM, Noli Sicad nsi...@gmail.com wrote: Hi, I know that Python plugins is not priority or not part of the SoC QGIS mobile - Android. JYFI, PySide for Android is on its way. http://thp.io/2011/pyside-android/ http://www.mail-archive.com/pyside@lists.pyside.org/msg00473.html Current version of PySide is API compatible with PyQt. PySide is compatible with __Version 2__ of the PyQt API. QGIS uses Version 1 which is incompatible. This could be changed, but would temporarily break all Python bindings and plugins as all instances of `QString` and `QVariant` would have to be removed and replaced with regular Python strings and objects. It may be a good idea in the long run to make the switch---all Enthought backed scientific Python projects are moving to PySide and thus Version 2 of the API along with other modules such as Matplotlib. It would be great if these PySide/PyQt components were available for use in QGIS plugins as it would lead to less time spend re-inventing scientific GUI wheels and more time spent doing awesome stuff with spatial data. -Charlie I doubt PyQt has a plan for embedded / mobile devices (e.g. Android, Meego, etc.). Qgis dev will port PyQt for QGIS mobile python plugins? Any news of PyQt running in Android, Meego, etc? Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ECW for QGIS 1.7 Mac OS X
On Fri, Jul 8, 2011 at 6:27 PM, Noli Sicad nsi...@gmail.com wrote: Hi, I am trying to compile libecwj2-3.3-2006-09-06[1] for Mac OS X, but I got some errors[2]. You can get the source. sudo wget http://de-mirror.org/distro/gentoo/distfiles/libecwj2-3.3-2006-09-06.zip Lee and others managed to compile this ECW library for QGIS 1.7 for Ubuntu. I think it would to have ECW support as well in Mac OS X. William, would it be possible to try to compile this library and package it for Mac OS X users? Reading from Build.txt, it has support for Mac OS X. Thanks in advance. Noli I'd be willing to take a shot at adding this to the Homebrew package manager: http://mxcl.github.com/homebrew Is there a homepage for ECW that I could browse for more info? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ECW for QGIS 1.7 Mac OS X
On Fri, Jul 8, 2011 at 7:12 PM, Noli Sicad nsi...@gmail.com wrote: You can get all the info and documentation (e.g. SDK) of ECW in this site (below) http://201.22.212.223/ecw/ecw/ Yes, it would be nice if you can add this in homebrew. Thanks. Noli Hrm, maybe not. From the license file: You are granted the rights to use the ER Mapper Image Compression SDK for evaluation purposes only. You may not redistribute this software without permission. Not a lawyer, but I'm pretty sure that is telling me not to add it to a package manager. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
On Sat, Jul 2, 2011 at 2:37 PM, Camilo Polymeris cpolyme...@gmail.comwrote: I have now invested a week trying to reconcile traits the processing framework, without satisfying results. It may have to do with me not having any experience with traits.. but I must admit, I am quite confused and not sure how to proceed. Would appreciate if someone else can have a look at the code (traits branch) and comment. Regards, Camilo I don't know if this is relevant to the crashes you have been getting, but TraitsUI and most other Enthought Qt-oriented GUI projects use version 2 of the SIP QString and QVariant APIs: https://github.com/enthought/pyface/blob/master/pyface/qt/__init__.py This is done so they can swap between PyQt4 and PySide without hassle and to get better unicode and Python 3 support. QGIS uses Version 1 of those APIs which is fundamentally incompatible. QGIS could upgrade to version 2 but all Python plugins containing code using QString or QVariant would have to replace these calls with plain Python strings and objects---definitely a 2.0 sort of change. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS for Water
On Thu, Jun 23, 2011 at 12:07 AM, Saber Razmjooei razmjoo...@faunalia.co.uk wrote: Hi there I reckon it will be great to have a set of plugins for hydrology and hydraulic modelling in QGIS. To develop a new hydraulic engine for QGIS is not an ideal and we will be re-inventing the wheel. So, the ideal situation is to take an existing tool and use QGI to pre-process or post-process the inputs/outputs. Most of the hydraulic/hydrology model I have come across are for Windows only, which is not ideal. The only one which is very powerful and really multi-platform is AnuGA http://sourceforge.net/projects/anuga/ AnuGA can be used for modelling: coastal, fluvial, surface water and urban drainage system. We have developed a plugin for QGIS so that you can prepare your model GIS files (boundary files, mesh, etc). It is a bit out of date and requires lots of tweaking. http://sourceforge.net/projects/anuga-gai/ Will be good find a fund from those who are interested and develop this further. We have several ideas to improve the plugin further (mesh editor, result viewer, etc) but extremely busy atm. Cheers Saber What would be really nice to have would be an open source alternative to software like SMS: http://www.aquaveo.com/sms That is, a framework that is not specific to a single modle, but could be used to prepare input for multiple different models and visualize their output. A good mesh editing plugin would be an ideal start, something that could handle: - Structured meshes - Unstructured meshes - Quadtree meshes -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis 1.7, Mac Os X and pyspatialite
On Thu, Jun 23, 2011 at 8:07 AM, Luca Mandolesi mandol...@gmail.com wrote: Hi, why pyspatialite module is not included in Qgis 1.7 under mac os x. Pyhton modules not installed are very boring for a new user that can't understand how to install it. It's possible to consider a poll where the users requires their own favourite modules that could be included by default on qgis: reportlab, sqlalchemy, shapely, ecc. ecc. or a plugin to download the python modules directly inside qgis? Thanks a lot!! Luca Perhaps if QGIS embedded its own Python installation such as is done by the Blender folks. But as long as QGIS is using Python distributions that comes with the system, I think I would get annoyed and confused if there were two different versions of a module running around---one of which I did not install myself. The Pip package manager makes it easy to install, remove and manage Python modules: http://www.pip-installer.org/en/latest/index.html Perhaps you would find it helpful. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Latest GRASS with QGIS
On Wed, Jun 22, 2011 at 8:43 AM, David Burken dbur...@comcast.net wrote: Hi, Just fyi, I just built the latest grass from svn and I'm now seeing two issues. 1) In the FindGRASS.cmake it looks like the library grass_vect is now grass_vector or libgrass_vector.so(on linux). Changing: SET (GRASS_LIB_NAMES gis vect dig2 dbmiclient dbmibase shape dgl rtree datetime linkm form gproj) To: SET (GRASS_LIB_NAMES gis vector dig2 dbmiclient dbmibase shape dgl rtree datetime linkm form gproj) Fixes that. 2) Then it looks like version 7.0 is not supported. CMake Error at src/plugins/grass/CMakeLists.**txt:8 (MESSAGE): Your GRASS version is not supported (/work/osgeo/qgis/Quantum-GIS/**src/plugins/grass/modules-7.0 is not found). Are there plans to support 7.0? I'll pull a 6.4 version in the mean time. Take care, Dave Has 7.0 been released yet? If not, are there any release dates set? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Python console idea: Expanding the Python console to handle DSLs for plugins eg CADTools
On Thu, Jun 16, 2011 at 5:27 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: On Thu, Jun 16, 2011 at 12:33 PM, Nathan Woodrow madman...@gmail.com wrote: I would appreciated any feedback anyone has. I'm not a python expert so the code could be done better if done for real but at the moment it's just rough to get the idea out there. I like the idea of supplying console functionality for plugins. I don't like the idea of piggybacking via PREFIX: foo syntax onto Python. People might think they can mix python variables with variables in other DSLs. Which would be tricky. What might be nice would be if the Python console could exist in a tabbed window, and plugins could have an 'open console' option, which would add a tab to the python console. This would provide standard console functionality and then feed the lines to a handler registered by the plugin. Maybe you could even have seventeen python console tabs open at once next to four SQL command tabs and one interface to the QGIS API written in perl? Barry You may want to look at the IPython console---they have a very nice syntax for adding new domain-specific commands which they call magic commands: http://ipython.org/ipython-doc/dev/interactive/reference.html#magic-command-system For example, say you want to run a Python function as a command: def say_hello(self, arg): print(Hello, world!) # Grab a hook to the currently running IPython instance: import IPython.ipapi ip = IPython.ipapi.get() # Register a new magic function: ip.expose_magic(hello, say_hello) Users can they run magic commands directly at the console level using a %command syntax: In [1]: %hello Hello, world! IPython 0.11 is scheduled to be released at the end of this month and has a slightly different api for registering new magic functions: # Grab a hook to the currently running IPython instance ip = get_ipython() # Register a new magic function ip.define_magic(hello, say_hello) I have always thought IPython would be a good replacement for the current QGIS console as it has a lot of features such as tab-completion, inline help and interactive object inspection that saves users a lot of running back and forth between manual pages and their workspace. The 0.11 version even has a frontend that is built in PyQt which would make it easy to integrate into QGIS as a plugin. IPython 0.11 also provides a parallel and distributed computing framework that could have very interesting applications for GIS algorithms. I was even working on such a plugin a couple of months ago. Unfortunately I had to shelve the project as IPython decided to migrate to Version 2 of the SIP API in order to be compatible with PySide as well as PyQt and to be compatible with the rest of the Enthought tools for scientific computing in Python. QGIS uses Version 1 of the SIP API which is incompatible with Version 2. QGIS could migrate to Version 2, but all plugins that use QString or QVariant in their Python code would need to replace these with plain Python strings and objects as the QString and QVariant classes are no longer needed or defined with the Version 2 API. Migrating QGIS to the latest version of the SIP API might be a good idea in the long run as I think it may have better support for Python 3. Some of the issues were discussed when PySide decided which API to support: http://www.pyside.org/docs/pseps/psep-0101.html -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: Call for packaging: QGIS 1.7.0 'Wroclaw'
On Tue, Jun 7, 2011 at 12:49 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Mon, Jun 6, 2011 at 9:42 PM, David Spencer baildon.resea...@googlemail.com wrote: Source tarballs can be obtained from here: http://qgis.org/downloads/qgis-1.7.0.tar.gz The top level directory in the tarball is qgis-Quantum-GIS-dfd6ece/, not qgis-1.7.0/. Is that intentional? Thats the way gitbub generates the tarball. The hash at the end is the exact revision for the release tag. Does it cause a problem for you packaging wise? I guess its not so user friendly, so I could unpack it rename it and repack it if you think it will be better. Regards Tim No need to repack, just use git-archive to export a snapshot: # Sync with QGIS repo and pull down tags git fetch qgis-upstream git archive --format=tar --prefix=qgis-1.7.0/ final-1_7_0 | gzip qgis-1.7.0.tar.gz -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: Call for packaging: QGIS 1.7.0 'Wroclaw'
On Tue, Jun 7, 2011 at 3:01 AM, David Spencer baildon.resea...@googlemail.com wrote: A prefix directory named qgis-1.7.0 is exactly what that command generates. The `final-1_7_0` part is the git tag Ick. Yes. Of course. Dumb grumpy packager in a hurry... sorry! -D. ps. did I mention that qgis is fab and the new release is very welcome? Because I should have... No problem, nothing I haven't done myself many times :) -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GIT Cleanup Completed
On Mon, Jun 6, 2011 at 6:46 AM, Tim Sutton li...@linfiniti.com wrote: Hi All Ok I have finished the cleanup of tags and branches in the GitHub main repository for QGIS. If you have a clone, you may want to perform a similar cleanup to your local repo. I strongly suggest making a backup before doing this and checking that the script below does not trash any of your valuable work. That said if you want a hint about how to remove the pruned branches and tags from your github or other clone you can use a variation of this bash script: If you shoot yourself in the foot with git (i.e. deleting a branch or resetting a commit), git still has the deleted content. Content that has been committed but then disconnected from a branch isn't destroyed unless an aggressive garbage collection takes place or it is really, really old (like a month or more). You can use tools like `git reflog` and `git fsck` to find the SHAs of lost content and then unshoot yourself in the foot using `git checkout`, `git cherry-pick`, `git branch`, etc. Of course, mounting a scratch monkey by copying the repo is more efficient in terms of time than digging around in the reflog. But in case you ever find yourself with a toe missing... -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qt build for QGIS source
The Homebrew formulae may be of help: For Qt: https://github.com/mxcl/homebrew/blob/master/Library/Formula/qt.rb For Qwt (note that you may need to downgrade Qwt from 6.0.0 to 5.2.1 to compile QGIS): https://github.com/mxcl/homebrew/blob/master/Library/Formula/qwt.rb For QGIS (unreleased and under active development): https://github.com/Sharpie/homebrew/blob/qgis/Library/Formula/qgis.rb The formula files are just Ruby scripts that calculate the required arguments to configure, cmake, etc and then run the commands. -Charlie On Sun, Jun 5, 2011 at 1:22 PM, Mars Sjoden aurorageomat...@gmail.comwrote: Cool! did not know that! Yah, both arch's x86_64 and i386 installed as universal. I'll keep grinding away at it. I better keep notes this time! Thanks On Sun, Jun 5, 2011 at 12:31 PM, William Kyngesburye wokl...@kyngchaos.com wrote: Qt Cocoa should have 64bit for all the Qt frameworks. You can check a framework archs with: file /Library/Frameworks/QtSvg.framework/QtSvg I don't know why it's failing on qwt designer. It's not needed by QGIS really. Try disabling it in the qwtconfig.pri - comment out the line to add it to the config. On Jun 5, 2011, at 1:50 PM, Mars Sjoden wrote: Yes of course William, a very incredibly helpful resource. I likely am unable to follow instructions correctly, as I am finding (and remember in my case) there were (are) special steps that I need to take to build all the pre-req's... Have you ever tried building with two kids hanging off your arms ^_^ ha ha! There maybe something I am doing that is causing all our Intel Core 2 Duo's to cause troubles with QGIS. for instance: ld: file not found: QtSvg.framework/Versions/4/QtSvg for architecture x86_64 collect2: ld returned 1 exit status make[1]: *** [plugins/designer/libqwt_designer_plugin.dylib] Error 1 make: *** [sub-designer-make_default] Error 2 Are these errors normal when making of QWT? QtSvg for 64bit is missing, so this would suggest that I may have downloaded the wrong Qt libraries for SnowLeopard? Perhaps there is no 64bit QtSvg available? I downloaded the: Cocoa: Mac binary package for Mac OS X 10.5 - 10.6 (32-bit and 64-bit) http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x Thanks for the help, these issues so incredibly trivial for you I understand. Mars On Sat, Jun 4, 2011 at 5:00 PM, William Kyngesburye wokl...@kyngchaos.com wrote: It's all in the INSTALL document in the QGIS source. On Jun 4, 2011, at 5:38 PM, Mars Sjoden wrote: Thanks, Tried the SDK download, but throws some errors when building some of the dependancies (pyqt I think). Simply installing the libs seems to work so far, …must install to allow for dynamic libs? I need to remember to write down this process for myself! Sent from the MarsPhone On 2011-06-04, at 11:07 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Don't compile Qt from source, just download the framework installer. They also have debug libs as a separate download (it adds to the frameworks). For most purposes the Qt Libraries downloads are enough, but if you need the dev tools, like Qt Designer and the Qt IDE you need the larger Qt SDK. Looks like they changed their download page layout a bit - the SDK/Library section used to be side by side, now they're sequential and you need to scroll down to find the Library links. On Jun 4, 2011, at 12:43 PM, Mars Sjoden wrote: Hello, I am on my wife's computer (Snow Leopard) and am trying to remember if I need to build Qt libraries as a static or dynamic library? I seem to remember dynamic is preferred for dependancies but also seem to remember that the auto-download/build installer for Qt for Mac builds the libraries as static? What is the smoothest download for Qt (and debugging) that I should be using for Mac? Thanks! a non-developer hack. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ Qgis-developer mailing list
Re: [Qgis-developer] git and gerrit .. Qt development
On Wednesday, May 25, 2011, Werner Macho werner.ma...@gmail.com wrote: hi devs! Just because I read an article about upcoming versions of Qt right now (Qt4.8 leading to Qt5.0) .. The devs at Qt will use gerrit [1] as a tool for code review .. I only wanted to bring that to your attention - probably that is also something for us? [1] http://code.google.com/p/gerrit/ regards Werner What benefits does Gerrit bring that go above and byond the functionality GitHub has in pull requests? It looks like a great tool, but it seems to me there is a point where spreading the development activity over too many websites would be counter-productive. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis-grass poll
On Sat, May 21, 2011 at 9:15 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. I would like to do a poll on qgis-grass usage: which would be the best web tool to use? Probably better not to use qgis or grass pages; does osgeo provides polling facilities? Thanks. -- Paolo Cavallini: http://www.faunalia.it/pc Two that I know of are polldaddy.com and the Forms feature of Google Docs: http://www.youtube.com/watch?v=IzgaUOW6GIs Google Forms are interesting because the results are automagically recorded to a spreadsheet. Hope this helps! -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] update pull request
On Sat, May 7, 2011 at 9:28 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Sat, May 7, 2011 at 6:03 PM, Mayeul Kauffmann mayeul.kauffm...@free.fr wrote: Hi, Thanks all for your hints. Still, I could not find a way to make those changes on existing branch and on the pull request #3, so I forked again and added a new pull request: Ok no need to refork, you can just do (in your local repo): git remote add qgis-upstream git://github.com/qgis/Quantum-GIS.git git fetch qgis-upstream git branch --track release-1_7_0 origin/release-1_7_0 git checkout release-1_7_0 git pull qgis-upstream release-1_7_0 git push origin release-1_7_0 That will pull any changes from qgis repo and push them up to your clone of it. Obviously you need to commit any fixes you made in response to the comments and push those too. Then just issue a new pull request and cancel the old one. I will write up some working practice docs in CODING soon I promise :-) Regards Tim Although it is *strongly* recommended to create a separate branch for each feature. For example, if you only use a release-1_7_0 branch: git branch --track release-1_7_0 origin/release-1_7_0 And work on two features, x and y you will have a problem when opening pull requests from that branch: The pull request for feature x will contain all commits for feature y and vice versa. A better method would be: git checkout -b feature/x --track origin/release-1_7_0 git checkout -b feature/y --track origin/realease-1_7_0 That sets up both branches so that `git pull` will bring in upstream changes, yet changes made by `git commit` are segregated. Pull requests opened from `feature/x` will only contain commits related to x. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] update pull request
On Sat, May 7, 2011 at 10:55 AM, Charlie Sharpsteen ch...@sharpsteen.netwrote: A better method would be: git checkout -b feature/x --track origin/release-1_7_0 git checkout -b feature/y --track origin/realease-1_7_0 Err, sorry---if you were following Tim's instructions, that should be: git checkout -b feature/x --track qgis-upstream/release-1_7_0 git checkout -b feature/x --track qgis-upstream/release-1_7_0 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
On Mon, May 2, 2011 at 9:22 AM, Martin Dobias wonder...@gmail.com wrote: great stuff :-) The repository reads 59 branches and 82 tags. In my opinion we should: - remove all ancient tags not related to releases - like root-before-SDTS-branch - change all release branches to tags - remove all branches that have been merged or not touched for more than 1-2 years - for releases adopt a strategy e.g.: create release branch from master, do release-related commits there, when finished create a release tag and remove the release branch ... we would end up with just few active branches and tags marking releases or other important milestones. Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? Finally I have one major concern I have forgotten to discuss during the hackfest. There will be no commit revision numbers anymore, so developers will barely stay motivated to develop QGIS knowing that we will never reach (and celebrate) revision 16000 or 2 (btw. now we are at r15861). Do you have any solution for that? Git's sha1 hashes for the commits may bring in some fun too, though they seem quite random :-) `git describe` will return the number of commits since the last tag or some other reference point of your choosing if you need a linear commit number to track. Another thing that can help developer motivation is `git shortlog -s -n` which computes the number of commits per author and displays a sorted list. -Charlie Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Help needed with PyQGIS
On Wed, Mar 16, 2011 at 10:20 PM, Learn Qgis learn.q...@gmail.com wrote: Hi, I am new to QGIS. I am trying to build the source code using CMAKE to Visual Studio 2008 environment with python binding. I am using Python 2.7, SIP 4.12.1 and PyQt 4.8.3 I am getting below error *Couldn't load PyQGIS. Python support will be disabled. * * Traceback (most recent call last): File , line 1, in ImportError: dynamic module does not define init function (initcore) * *Python version: 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] QGIS version: 1.6.0-Copiapo 'Copiapo', exported Python path: ['D:/dev/cpp/build/src/app/**Debug/./python', 'C:/Documents and Settings/Administrator/.qgis/**python', 'C:/Documents and Settings/Administrator/.qgis/**python/plugins', 'D:/dev/cpp/build/src/app/ **Debug/./python/plugins', 'E:\\Python27\\Lib\\site-**packages', 'E:\\Python27\\Lib', 'D:\\dev\\cpp\\build\\src\\**app\\Debug', 'C:\\WINDOWS\\system32\\**python27.zip', 'E:\\Python27\\DLLs', 'E:\\Python27\\lib\\plat-win', 'E:\\Python27\\lib\\lib-tk', 'E:\\Python27'] * Please help me in resolving this error thanks in advance... Usually this means that Python could not find the PyQt module or could not load it for some reason. Check your environment variables---specifically PATH and PYTHONPATH. -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Grass plugin error - Missing header - 'libintl.h'
On Fri, Feb 25, 2011 at 11:50 AM, maaza mekuria sail...@yahoo.com wrote: 64 items compiled without error only one (Grass failed). Where does one fine the missing header 'libintl.h'? Below is the error message output. 53-- Build started: Project: gpsimporterplugin, Configuration: RelWithDebInfo Win32 -- 53Linking... 51C:\OSGeo4W\apps\grass\grass-6.4.0\include\grass/glocale.h(9) : fatal error C1083: Cannot open include file: 'libintl.h': No such file or directory 51Build log was saved at file://c:\SW\myQGIS\src\plugins\grass\grassplugin.dir\RelWithDebInfo\BuildLog.htm 51grassplugin - 1 error(s), 0 warning(s) 65Embedding manifest... 65Build log was saved at file://c:\SW\myQGIS\src\plugins\coordinate_capture\coordinatecaptureplugin.dir\RelWithDebInfo\BuildLog.htm 65coordinatecaptureplugin - 0 error(s), 0 warning(s) == Build: 64 succeeded, 1 failed, 28 up-to-date, 0 skipped == Thank you, Maaza ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer `libintl.h` is part of the gettext library: http://www.gnu.org/software/gettext/ -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Poor asynchronous performance of Python threads?
Thanks for the reply Martin! On Fri, Feb 18, 2011 at 2:07 PM, Martin Dobias wonder...@gmail.com wrote: Hi Charlie On Wed, Feb 9, 2011 at 6:27 AM, Charlie Sharpsteen ch...@sharpsteen.net wrote: Hello list, I have been playing around with the development branch of IPython (0.11-dev) as they have built a PyQt-based console that supports all sorts of awesome features like tab-completion, paged browsing of function code and docstrings, and Pygments-powered syntax highlighting in addition to the normal IPython goodness. I slapped together a quick plugin that adds an IPython-based console to QGIS. The code is available at: https://github.com/Sharpie/qgis-ipython To use it, you will need to install ZeroMQ, pyzmq, pygments and the dev version of IPython from: https://github.com/ipython/ipython Generally the best / easiest way how to make your code available for testing for others is to upload the plugin at pyqgis.org to the contributed repository. Requiring development version of ipython would be however a show stopper for most users... I would love to see a finished plugin eventually released to PyQGIS. However, the code is currently little more than a proof-of-concept prototype and is also based on a development version of IPython, so I didn't feel like a public release on PyQGIS was appropriate at this time. The console fires up allright, but unfortunately very, very, very slow. There is about ~1-2 seconds of lag between invoking a command and receiving a response. For comparison, I threw together a minimal PyQGIS application that also uses the IPython console: https://gist.github.com/817914 The PyQGIS version is very snappy and there is no lag. I suspect the difference is due to the PyQt widget is talking to an external IPython process through ZeroMQ. When a command is executed, the console sends a message and then a Python thread waits for the response. With PyQGIS, Python is controlling the execution of the entire application. However, when the console is used as a plugin it is running in an embedded interpreter and it looks like QGIS takes a while to schedule the execution of the Python threads. Does anyone have any suggestions for solving or working around this issue? An interesting issue. Why do you think that IPython uses another process? The interesting thing about IPython is that in addition to being a really nice Python shell it is also a framework for parallel and distributed computing. The 0.11 series splits the interpreter into a separate process using ZMQ so that a single console could dispatch jobs to several independent interpreters and those interpreters could be running on entirely different machines. When this framework matures, it could open up some really interesting possibilities for dispatching computationally intensive operations from QGIS. Running the console in another process would disable the communication between QGIS interface and the console - and that is not really wanted. At the moment, my main interest in getting IPython into QGIS is so that it can help me develop Python plugins. The existing Python console is very nice, but I keep tapping the tab key in vain whenever I forget what attributes an object has. Currently I am working on an IPython kernel that does not run in a separate process so it can access objects like `qgis.utils.iface`. Progress is slow, but promising. However, it would also be nice to leave the option of spawning out-of-process shells for computationally intensive jobs. Maybe you could try to run that code in a profiler to find out where is the bottleneck. Martin I have given this a couple of tries. Unfortunately I don't have much experience using profilers so I wasn't able to learn much. I think the question I need to answer is: Is the delivery of messages being delayed by the QGIS C++ code, the Python interpreter or the ZMQ event loop? At this point it *seems* too have something to do with the C++ code as everything runs fine in a pure PyQGIS app. Some tools I know about that I have access to are gprof, dtrace and valgrind---is there one that you would suggest as being particularly suited to this task? Do I need to recompile QGIS with some special flags? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Poor asynchronous performance of Python threads?
Hello list, I have been playing around with the development branch of IPython (0.11-dev) as they have built a PyQt-based console that supports all sorts of awesome features like tab-completion, paged browsing of function code and docstrings, and Pygments-powered syntax highlighting in addition to the normal IPython goodness. I slapped together a quick plugin that adds an IPython-based console to QGIS. The code is available at: https://github.com/Sharpie/qgis-ipython To use it, you will need to install ZeroMQ, pyzmq, pygments and the dev version of IPython from: https://github.com/ipython/ipython The console fires up allright, but unfortunately very, very, very slow. There is about ~1-2 seconds of lag between invoking a command and receiving a response. For comparison, I threw together a minimal PyQGIS application that also uses the IPython console: https://gist.github.com/817914 The PyQGIS version is very snappy and there is no lag. I suspect the difference is due to the PyQt widget is talking to an external IPython process through ZeroMQ. When a command is executed, the console sends a message and then a Python thread waits for the response. With PyQGIS, Python is controlling the execution of the entire application. However, when the console is used as a plugin it is running in an embedded interpreter and it looks like QGIS takes a while to schedule the execution of the Python threads. Does anyone have any suggestions for solving or working around this issue? -Charlie ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
