<div dir="ltr"><div class="gmail_extra">try:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">if myDialog.findChild(QLineEdit,"cod_direzione").text() == "":<br>        myDialog.findChild(QLineEdit,"cod_direzione").setText("A")</div><div class="gmail_extra">else:</div><div class="gmail_extra">         myDialog.findChild(QLineEdit,"cod_direzione").setText("NOT NULL")</div><div class="gmail_extra"><br></div><div class="gmail_extra">use len(str) instead of str.length()</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the text is not empty string intially because it work for me. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Also where are you defining this statement ? -some callback function or  __init__  </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Can you post the complete function ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 2:12 PM,  <span dir="ltr"><<a href="mailto:qgis-developer-request@lists.osgeo.org" target="_blank">qgis-developer-request@lists.osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send Qgis-developer mailing list submissions to<br>
        <a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:qgis-developer-request@lists.osgeo.org">qgis-developer-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:qgis-developer-owner@lists.osgeo.org">qgis-developer-owner@lists.osgeo.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Qgis-developer digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Difference of "import" inside qgis python console and inside<br>
      a python plugin (Luca Mandolesi)<br>
   2. Re: A plea for plugin authors (Stefan Keller)<br>
   3. Null Value in QLineEdit (Enrico Fiore)<br>
   4. Re: Thoughts about multi-type tables in QGIS (Matthias Kuhn)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 3 Apr 2015 00:36:44 +0200<br>
From: Luca Mandolesi <<a href="mailto:mandoluca@gmail.com">mandoluca@gmail.com</a>><br>
To: qgis-developer List <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>><br>
Subject: [Qgis-developer] Difference of "import" inside qgis python<br>
        console and inside a python plugin<br>
Message-ID:<br>
        <<a href="mailto:CAHmdnV6dCn19KbaXNUktpSFCM0SxoOArh7tgEX1OwJGFO6a6EA@mail.gmail.com">CAHmdnV6dCn19KbaXNUktpSFCM0SxoOArh7tgEX1OwJGFO6a6EA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi to all,<br>
<br>
I'm trying to use vispy module inside my python plugin, but a strange thing<br>
happens:<br>
<br>
If I call import vispy inside the Qgis python console the script runs<br>
properly, but, if I put the "import vispy", at the beginning of my plugin,<br>
I receive this error [0]<br>
<br>
Why inside the Qgis python console a module can be imported, but not inside<br>
a plugin?<br>
<br>
Really, really, strange.<br>
<br>
Ideas?<br>
<br>
Thanks a lot,<br>
Luca<br>
<br>
<br>
<br>
[0]<br>
Traceback (most recent call last):<br>
  File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 219, in<br>
startPlugin<br>
    plugins[packageName] = package.classFactory(iface)<br>
  File<br>
"C:\Users\Windows\Github\pyarchinit_beta_test_dev\pyarchinit\__init__.py",<br>
line 49, in classFactory<br>
    from pyarchinit_plugin import PyArchInitPlugin<br>
  File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 478, in _import<br>
    mod = _builtin_import(name, globals, locals, fromlist, level)<br>
  File<br>
"C:\Users\Windows\Github\pyarchinit_beta_test_dev\pyarchinit\pyarchinit_plugin.py",<br>
line 23, in<br>
    import vispy as visp<br>
  File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 478, in _import<br>
    mod = _builtin_import(name, globals, locals, fromlist, level)<br>
  File<br>
"C:\OSGeo4W\apps\Python27\lib\site-packages\vispy-0.3.0-py2.7.egg\vispy\__init__.py",<br>
line 34, in<br>
    _parse_command_line_arguments()<br>
  File<br>
"C:\OSGeo4W\apps\Python27\lib\site-packages\vispy-0.3.0-py2.7.egg\vispy\util\config.py",<br>
line 275, in _parse_command_line_arguments<br>
    opts, args = getopt.getopt(sys.argv[1:], '', argnames)<br>
<br>
AttributeError: 'module' object has no attribute 'argv'<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/ebf0c666/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/ebf0c666/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 3 Apr 2015 17:11:19 +0200<br>
From: Stefan Keller <<a href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>><br>
To: "<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>" <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>><br>
Subject: Re: [Qgis-developer] A plea for plugin authors<br>
Message-ID:<br>
        <CAFcOn2-BHjOH0f2w1Vym=sgNh8s_fD3rdQa=<a href="mailto:riW3gsukNuCmFg@mail.gmail.com">riW3gsukNuCmFg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Paolo, hi all<br>
<br>
Paolo mentioned icons in his plea, section Metadata:<br>
> * add a proper icon, do not leave the default one; see QGIS interface<br>
> for a suggestion of the style to be used<br>
<br>
There are several places where icons are shown:<br>
AFAIK there's at least<br>
1. QGIS Toolbar: 64x64 pixels?<br>
2. Plugins home: <a href="http://plugins.qgis.org/plugins/" target="_blank">http://plugins.qgis.org/plugins/</a> => 32x32 pixels<br>
3. In the QGIS Extensions Dialog: 16x16 pixels<br>
<br>
In the QGIS Extensions Dialog actually very few individual icons show<br>
up like TileLayer, QGIS Cloud or QSpatialite.<br>
<br>
My questions:<br>
A. Are there more places where icons show up?<br>
B. Are thre recommendations which is the recommended size? 32x32? several sizes?<br>
C. Does anybody know how to make the icon show up in the "QGIS<br>
Extensions Dialog"?<br>
<br>
Yours, Stefan<br>
<br>
<br>
2015-03-26 14:56 GMT+01:00 Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>>:<br>
> Il 26/03/2015 14:53, Charles Shapiro ha scritto:<br>
><br>
>> Has anyone else had this difficulty?<br>
><br>
> I remember others had the same problem, but cannot recall how they<br>
> solved it: anyone?<br>
> All the best, and thanks for your reply.<br>
><br>
> --<br>
> Paolo Cavallini - <a href="http://www.faunalia.eu" target="_blank">www.faunalia.eu</a><br>
> QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" target="_blank">http://www.faunalia.eu/training.html</a><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 3 Apr 2015 18:03:05 +0200 (CEST)<br>
From: Enrico Fiore <<a href="mailto:enricofiore@libero.it">enricofiore@libero.it</a>><br>
To: <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>><br>
Subject: [Qgis-developer] Null Value in QLineEdit<br>
Message-ID:<br>
        <<a href="tel:2062915558" value="+12062915558">2062915558</a>.1665451428076985353.JavaMail.httpd@webmail-16.iol.local><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
I am newbie in python e pyqgis.<br>
I tried to perform some validation related to a open form action. The validation affects when the user click on ok.<br>
I have to check if a value in a edit text slot is null and in that case edit a default value in the form slot. I made different test:<br>
<br>
EX1.<br>
<br>
if myDialog.findChild(QLineEdit,"cod_direzione").text() == "":<br>
        myDialog.findChild(QLineEdit,"cod_direzione").setText("A")<br>
<br>
Results: QGIS doesn't return any error but doesn't set the value "A"<br>
<br>
EX2.<br>
<br>
if not myDialog.findChild(QLineEdit,"cod_direzione").text().length() > 0:<br>
        myDialog.findChild(QLineEdit,"cod_direzione").setText("A")<br>
<br>
Results: return this error<br>
AttributeError: 'unicode' object has no attribute 'length'<br>
How i can test if the value in the text edit field i null? and then put the default value in the attribute field?<br>
<br>
<br>
Thanks for your attention<br>
<br>
Enrico Fiore<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/94adf3e4/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/94adf3e4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 03 Apr 2015 20:12:15 +0200<br>
From: Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>><br>
To: <a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a><br>
Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS<br>
Message-ID: <<a href="mailto:551ED7FF.50301@opengis.ch">551ED7FF.50301@opengis.ch</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
I think there's a lot of hidden caveats - in QGIS itself as well as in<br>
plugins - and it would be very hard to find them all and treat them<br>
appropriately.<br>
<br>
Therefore I would prefer not to go for a change in layer semantics in<br>
terms of that a layer iterator suddenly may return different geometry types.<br>
I'd prefer to re-raise the idea of having a special layer-group type<br>
that allows to define certain settings on all sub-layers. Adding a<br>
multi-geometry layer can by default add such a layer.<br>
<br>
The difference is an opt-in vs. an opt-out approach.<br>
Changing the layer geometry type semantic would require to update<br>
everything that does not want to use multi-geometry behavior (hence<br>
opt-out). A possibly painful story with lots of side-effects that we<br>
possibly can't even think of right now.<br>
The group approach would allow any component capable of handling<br>
multi-geometry types to add possibilities on group-level. With a good<br>
API it can be easy to determine if a layer is part of a multitype group.<br>
And from the group an iterator can be requested and a hierarchical<br>
setting can be introduced (define defaults at group level, override at<br>
layer level).<br>
<br>
I would strongly prefer the second approach. It should allow to do all<br>
the cool things and introduce them incrementally without having to deal<br>
with all the unintended side-effects of a sudden break in semantics.<br>
<br>
Do you think there are downsides of this approach?<br>
<br>
Best regards,<br>
Matthias<br>
<br>
On 04/02/2015 05:07 PM, Olivier Dalang wrote:<br>
> Hi,<br>
><br>
> Would it really be more complicated ?<br>
><br>
> I mean, for now, an algorithm that works only with line layers already<br>
> has to check whether the layer is of type line. That's done before<br>
> iterating the features.<br>
><br>
> Exactly in the same way, there would be functions to determine whether<br>
> a layer supports a geometry type or not.<br>
><br>
> Then, there would be functions to iterate a particular geometry type<br>
> for a layer.<br>
> This could be done by adding a geometry type argument to getFeatures,<br>
> and/or by adding specific<br>
> getLineFeatures/getPointFeatures/getPolygonFeatures functions,<br>
> probably throwing exceptions if the layer does not support this<br>
> particular type (shapefile or specific geometry column in postgis).<br>
><br>
> To me it seems not much different from how it works currently, at<br>
> least from a programmer's point of view. Of course it's quite a change<br>
> in the API, that's why it's only thoughts for a future QGIS 3 or 4...<br>
><br>
><br>
> I don't know Mapinfo at all, but it's good to know there's already<br>
> some experience somewhere (even if bad). But do you really think the<br>
> problem is in the principle itself, and not in Mapinfo's implementation ?<br>
><br>
><br>
> The things at stake are maybe worth the thought still...<br>
> The heavy distinction between geometry types is very artificial.<br>
> There's a lot of very valid representation of real world phenomenons<br>
> of a certain kind that require different geometry types. Having to<br>
> distribute those across different layers because of a 25 years old<br>
> file format is somewhat sad...<br>
><br>
><br>
> Olivier<br>
><br>
><br>
> 2015-04-02 16:41 GMT+02:00 Bo Victor Thomsen<br>
> <<a href="mailto:bo.victor.thomsen@gmail.com">bo.victor.thomsen@gmail.com</a> <mailto:<a href="mailto:bo.victor.thomsen@gmail.com">bo.victor.thomsen@gmail.com</a>>>:<br>
><br>
>     As an old MapInfo user/developer my opion is: Don't do it. It has<br>
>     always been a problem in MapInfo and it will be a problem in QGIS<br>
>     - if implemented.<br>
><br>
>     A better approach is to have the possibility to let different QGIS<br>
>     layers share some common characteristics (for example labelling).<br>
>     And - of course - clean up the current errors in QGIS when<br>
>     splitting contents of data sources by object types.<br>
><br>
>     Regards<br>
>     Bo Victor Thomsen<br>
>     AestasGIS<br>
>     Denmark<br>
><br>
>     Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:<br>
>>     Hi,<br>
>><br>
>>     In some projects of mine, I work with multiple geometry types in<br>
>>     one postgis table, using a column of type geometry(Geometry,4326).<br>
>>     This is very well supported by postgis.<br>
>><br>
>>     It is possible to load such a table in QGIS by manually selecting<br>
>>     the geometry type you want to load. This means that to display<br>
>>     all the features, you need to add the table three times, one for<br>
>>     each feature type.<br>
>><br>
>>     This works more or less. There are a few bugs though :<br>
>>     - <a href="http://hub.qgis.org/issues/12499" target="_blank">http://hub.qgis.org/issues/12499</a> (you can edit other type's<br>
>>     node with the node tool)<br>
>>     - <a href="http://hub.qgis.org/issues/12500" target="_blank">http://hub.qgis.org/issues/12500</a> (other type's records are<br>
>>     shown in the attribute table)<br>
>><br>
>>     This also has some limitations. When having such a setup, it's<br>
>>     pretty sure you'll want to have the same edit forms for all the<br>
>>     layers. You'll also probably want the same filter, the same<br>
>>     labels, the same actions, etc...<br>
>>     The only thing you'd want to be able to define on a geometry type<br>
>>     basis are the symbol (well, even the classification/colors/etc<br>
>>     could be shared) and the label placement.<br>
>>     For now, you must do all settings three times, because of this<br>
>>     bug/feature request :<br>
>>     - <a href="http://hub.qgis.org/issues/12303" target="_blank">http://hub.qgis.org/issues/12303</a> (copy/paste style from one<br>
>>     geometry type to another)<br>
>><br>
>><br>
>>     As you see, support multiple geometry types in QGIS is not perfect.<br>
>><br>
>>     Of course it's possible to fix the bugs/pr, and there are some<br>
>>     workarounds (postgis view instead of tables) but maybe it's also<br>
>>     worth thinking a bit more in depth about this.<br>
>><br>
>>     We could consider point/line/polygons as subcategories/sublayers<br>
>>     of a layer. A shapefile or a mono-typed table would have only one<br>
>>     of those sublayer, but a postgis table could perfectly have the<br>
>>     three. Most of the settings would be defined at the layer level,<br>
>>     while only some settings would be defined at the subcategory level.<br>
>><br>
>>     This is probably especially relevant when thinking long term (the<br>
>>     day we support 3D, curves, etc...).<br>
>><br>
>><br>
>>     What do you think ?<br>
>>     Do you think the relation 1 layer = 1 geometry type will hold ?<br>
>><br>
>>     I think we inherited this from the old shapefile format, but most<br>
>>     data sources QGIS handles don't have this limitation. I also<br>
>>     think it does not hold with quite a lot of modern GIS uses<br>
>>     (especially web related, think of openstreetmaps for instance).<br>
>><br>
>>     There's this feature request (6th oldest open issue on the<br>
>>     tracker) about postgis geometry collections  :<br>
>>     <a href="http://hub.qgis.org/issues/167" target="_blank">http://hub.qgis.org/issues/167</a><br>
>><br>
>><br>
>>     Best,<br>
>><br>
>>     Olivier<br>
>><br>
>><br>
>><br>
>>     _______________________________________________<br>
>>     Qgis-developer mailing list<br>
>>     <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>><br>
>>     <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
>     _______________________________________________<br>
>     Qgis-developer mailing list<br>
>     <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>><br>
>     <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/8d4122a6/attachment.html" target="_blank">http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/8d4122a6/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
End of Qgis-developer Digest, Vol 114, Issue 9<br>
**********************************************<br>
</blockquote></div><br></div></div>