| 05:40:13 | epzt: | hi all |
| 05:45:39 | arkygeek: | epzt: hi :- ) |
| 05:46:14 | epzt: | I'm still with a problem with threads |
| 05:46:18 | arkygeek: | so, wondering if anyone knows a way that I might save the graphics from the r.mapcalc formula creation screen. ( it is too big for a screen cap... ) |
| 06:35:45 | CIA-65: | jef * r10875 /trunk/qgis/src/app/attributetable/ ( qgsattributetablememorymodel.cpp qgsattributetablemodel.cpp ): fix attribute table edit problem when geometry is not last column in postgis tables |
| 06:35:51 | CIA-65: | mhugent * r10876 /trunk/qgis/src/app/qgsprojectproperties.cpp: Added increment for unit iterator and added a security check if snapping unit is not there ( e.g. 1.0 project file ) |
| 06:39:35 | epzt: | does anybody know wich executable loop is used to execute a plugin in QGIS |
| 06:48:21 | spacedman: | epzt: not sure I understand what you are asking... |
| 06:49:52 | epzt: | I developing a plugin of qgis. In that plugin a created a thread in charge of reading serial port. Each time characters are read, the thread emit a signal |
| 06:50:09 | epzt: | the problem is that the signal is never catch by the plugin |
| 06:50:39 | spacedman: | Qt signals and Python? |
| 06:51:27 | epzt: | qt : ) |
| 06:51:33 | epzt: | Qthread exactly |
| 06:51:59 | epzt: | and python also |
| 06:52:35 | spacedman: | ah okay, beyond my skills then! sorry :( I know that python signal connections have to be specified exactly otherwise they don't get caught... |
| 06:53:05 | epzt: | QObject.connect( self.s, SIGNAL( "LinesRead( PyQt_PyObject )" ), self.ManageGNSSInformation, Qt.QueuedConnection ) |
| 06:53:24 | epzt: | that is the code of the connection I made in the plugin |
| 06:53:48 | epzt: | "LinesRead" is the signal emitted by the thread |
| 06:54:00 | epzt: | the thread is here "s" |
| 06:54:15 | spacedman: | whts the Qt.QueuedConnection parameter do? My connect( ) calls only have three parameters... |
| 06:54:54 | epzt: | this parameters is needed whenyou deal with signals between threads |
| 06:55:30 | spacedman: | Ah okay. Is everything in Python? Because I read here that "Short-circuit signals may only be connected to slots that have been implemented in Python" |
| 06:56:09 | epzt: | yes everything is in python in my plugin |
| 06:56:21 | spacedman: | and the thing that emits the LinesRead is a python object too? |
| 06:56:45 | epzt: | no that's the only exception, it's a QT object |
| 06:57:04 | epzt: | that why I use the syntax LinesRead( PyQt_PyObject ) |
| 06:57:28 | spacedman: | Isn't that a "short-circuit" signal? |
| 06:57:29 | epzt: | to force python object conversion |
| 06:57:50 | epzt: | what do you mean with "short-circuit" ? |
| 06:58:01 | spacedman: | http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/pyqt4ref.html#short-circuit-signals |
| 06:58:02 | sigq: | Title: PyQt v4 - Python Bindings for Qt v4 ( at www.riverbankcomputing.co.uk ) |
| 06:58:07 | spacedman: | but maybe i dont know what i'm on about... |
| 06:59:29 | spacedman: | yeah i dont know what i'm on about.... your emitter is in C++, and uses python libs to create a python object yep? |
| 07:00:21 | epzt: | yep |
| 07:00:57 | spacedman: | right, so as long as your signal is defined in the header file exactly like that then I would have thought it would work... hmmm |
| 07:13:31 | epzt: | I made a test by deriving the thread from threading.Thread and not from QThread |
| 07:14:36 | epzt: | at run time it complain about argument type incorrect for the connection |
| 07:15:47 | epzt: | "s" is now of type threading.Thread, so how can I do ? |
| 07:20:54 | spacedman: | you can only connect Qt signals to things that inherit from QObject... |
| 07:25:46 | epzt: | ok, I try to follow information given in the ref you gave me |
| 07:26:08 | epzt: | QtCore.QObject.connect( self.s, SIGNAL( "LinesRead( PyQt_PyObject )" ), self.ManageGNSSInformation, Qt.QueuedConnection ) |
| 07:26:17 | epzt: | this is my connection code now |
| 07:40:21 | epzt: | to make the plugin receive the signal from the thread, I have to move the canvas of qgis ( with pan ) |
| 07:40:53 | epzt: | then the function self.ManageGNSSInformation is called. |
| 07:41:08 | epzt: | what does it means ? |
| 07:57:14 | epzt: | bye |
| 11:02:18 | CIA-65: | jef * r10877 /trunk/qgis/src/ ( 44 files in 11 dirs ): automatic indentation update ( r10594-r10876 ) |
| 11:03:48 | sigq: | tracfeed: Changeset [10877]: automatic indentation update ( r10594-r10876 ) <https://trac.osgeo.org/qgis/changeset/10877> |
| 12:55:43 | CGI439: | I've got a fresh Windows install of QGIS 1.1.0 'Pan'. When I try to create a new grass mapset and try to set its projection, the app locks up and dies. This is also the behavior I get in QGIS 1.0.2 'stable'. Is this a known problem? |
| 12:56:52 | wildintellect: | did you use the OSGEO4W or standalone installer |
| 12:57:09 | CGI439: | I used the standalone installer, in both cases. |
| 12:58:57 | jef: | apropos, there's a fresh trunk build in osgeo4w. |
| 13:00:45 | CGI439: | The reason I'm using the standalone installer is because I've had no luck getting the osgeo4w installation of grass & qgis to work for me. Things like 'cannot find application' etc. |
| 13:00:53 | wildintellect: | jef, do you think it's related to http://trac.osgeo.org/qgis/ticket/1582 |
| 13:00:55 | sigq: | Title: #1582 ( osgeo4w qgis-grass plugin crashes on Windows Vista ) - Quantum GIS - Trac ( at trac.osgeo.org ) |
| 13:01:11 | wildintellect: | CGI439, there appear to be several possibly related bug reports |
| 13:01:53 | CGI439: | BTW, I'm using XP, not the dreaded Vista |
| 13:03:27 | CGI439: | #1582 refers to qgis crashing in Vista under osgeo4w, but in my case, I could never even get qgis to launch! |
| 13:05:30 | wildintellect: | regardless they may be related |
| 13:05:48 | wildintellect: | have a look at http://trac.osgeo.org/qgis/query?status=new&status=assigned&status=reopened&component=GRASS&order=priority |
| 13:05:50 | sigq: | Title: Custom Query - Quantum GIS - Trac ( at trac.osgeo.org ) |
| 13:06:07 | wildintellect: | and see if you see anything else that appears similar to your issue |
| 13:07:23 | CGI439: | I'll look through those items and get back to you. Thanks for the tip. |
| 13:08:44 | jef: | wildintellect: yes, probably yet another cross dll malloc( )/free( ) mismatch. |
| 13:09:18 | jef: | wildintellect: although the standalone installer should be based on the same binaries. |
| 13:09:55 | wildintellect: | well, the error might be in both, we don't have enough data to know |
| 13:13:22 | wildintellect: | I might start poking at msys/mingw building next month - hoping I can find a way to cross compile from linux |
| 13:18:30 | CGI439: | BTW, one other tidbit: I've got FWTools2.3.0 in my execute path. Might that have anything to do with my problem? |
| 13:23:03 | jef: | CGI439: possibly. yes. |
| 13:23:04 | CGI439: | Excuse me, I was being silly with that last remark. Fact is, I do NOT have FWTools in my path. When I use fwtools, it sets its own environment variables etc. So surely FWTools has nothing at all to do with my qgis->grass/mapset problem. |
| 13:25:12 | CGI439: | On the otherhand, I do have MinGW, and other things, to wit: C:\Dev\MinGW\bin;C:\Programs\ggobi;%GTK_BASEPATH%\bin;C:\Dev\Python26\Lib\site-packages\PyQt4;C:\bin;C:\Oracle\product\10.2.0\client_1;C:\Program Files\ISRU\bin;C:\Programs\R\R-2.9.0\bin |
| 13:41:15 | CGI439: | OK, I've discovered a real path problem. I opened up a grass shell ( after opening up an existing mapset ) and captured the path. Here is the relevant part: C:\Programs\QUANTU~1\grass//bin;C:\Programs\QUANTU~1\grass//scripts;C:/Programs/QUANTU~2/bin; ( ?gd¡º?C:/Programs/QUANTU~20; |
| 13:42:27 | CGI439: | Notice the " ( ?gd¡º?" bit and the fact that there seems to be stray "0" at the end. What do you make of this? |
| 13:42:53 | wildintellect: | fascinating - I've never seen a path like that |
| 15:27:35 | springmeyer: | via python, anyone know how to get the 'layer' name of an ogr datasource? |
| 17:04:10 | springmeyer: | self.layer.dataProvider( ).subLayers( )[0] |
| 17:04:26 | springmeyer: | pattern = r'\d+:( .+ ):\d+:' |
| 17:04:40 | springmeyer: | ogr_layername = re.findall( pattern, sub_string )[0] |
| 17:04:48 | springmeyer: | ugh |
| 17:09:52 | wildintellect: | almost sounds like a question for the gdal/ogr folks |
| 17:10:42 | springmeyer: | no, getting at layer names in ogr natively is dead easy |
| 17:11:00 | wildintellect: | so the problem here is that it's abstracted |
| 17:11:15 | springmeyer: | clunkified |
| 17:12:52 | wildintellect: | I admit I haven't gone down that path since my plugin just needs the filename.xml |
| 17:13:16 | springmeyer: | sure, its a super edge case |
| 22:14:40 | pcav: | osgeo server down? |
| 22:16:51 | cgs_bob: | pcav: I just tried grass.osgeo.org. it comes up fine |
| 22:18:02 | pcav: | yes, now it works |
| 22:19:35 | pcav: | svn up qgis_unstable/ |
| 22:19:35 | pcav: | svn: OPTIONS di 'https://svn.osgeo.org/qgis/trunk/qgis': non ho potuto connettermi al server ( https://svn.osgeo.org ) |
| 22:19:39 | pcav: | :( |
| 22:34:15 | wildintellect: | sorry I forgot to talk with Arnulf about the servers when I saw him |
| 22:34:40 | wildintellect: | I'll bring it up with tyler on the marketing list |
| 22:37:26 | pcav: | # ping svn.osgeo.org |
| 22:37:26 | pcav: | PING svn.osgeo.org ( 66.223.95.245 ) 56( 84 ) bytes of data. |
| 22:37:26 | pcav: | ... |
| 22:37:47 | pcav: | cgs_bob: wildintellect: anyone can contact the server? |
| 22:38:21 | wildintellect: | nope |
| 22:38:33 | wildintellect: | this seems to be about the same time as the last time we talked about it |
| 22:38:46 | wildintellect: | we should go update the ticket |
| 22:38:59 | wildintellect: | I have the suspicion it's a backup process hogging the cpu |
| 22:40:41 | wildintellect: | well, update the ticket when it's back online |
| 22:47:08 | pcav: | anyway |
| 22:47:14 | pcav: | the server is misconfigured |
| 22:47:19 | pcav: | not a good thing |
| 23:02:06 | CIA-65: | mhugent * r10878 /trunk/qgis/src/core/qgsprojectfiletransform.cpp: Added null transformations from 1.0.0 and 1.0.2 to 1.1.1 |
| 23:03:58 | sigq: | tracfeed: Changeset [10878]: Added null transformations from 1.0.0 and 1.0.2 to 1.1.1 <https://trac.osgeo.org/qgis/changeset/10878> |