[Qgis-developer] Improvements to the value relation widget: port to C++?
Hi, to allow for drill-down forms, a few months ago, I've created a modified value relation widget with a companion form function that allow to implement dynamic filtering (or altering) of fields in a form. It can be easily ported in the core (it's basically a clone of the existing value relation widget). The widget is available as a python plugin. http://plugins.qgis.org/plugins/FormAwareValueRelationWidget/ More information here: http://www.itopen.it/a-new-qgis-plugin-allows-dynamic-filtering-of-values-in-forms The main question is if there is any interest in porting this widget into the core, then if this should be 1. a replacement of the existing value relation widget 2. an optional feature of the existing value relation widget 3. a new widget I would like to hear your thoughts about this. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] bugs status
I'm looking at the bug tracker to see what's left before release and found that among 27 issues tagged as "blockers", 9 have a target version of "Future Release - High Proprity" and 9 have no target version. I would say a priority cannot be "blocker" if a target version isn't set, do you agree ? If so, is there a way to batch-update all the tickets with no "target version" or target version = "Future Release" and priority = "blocker" to lower priority to "normal" ? The remaining 9 are "blockers" and have target version 2.14. Of these 9, 5 are still unassigned. Only one is marked as causeing "crash or corruption". It's also interesting to note that there are a total of 7 issues targetted at "2.14" that are "causing crash or corruption" but only 1 of them is marked as "blocker" (others go from normal to high). Shouldn't all crashers _also_ be blocker ? Finally, I'd love to give pointers to all the queries above, but hadn't found a way to obtain an url representing them, is there any way to do that ? --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Improvements to the value relation widget: port to C++?
Hi Alessandro, Yesterday I had a meeting with Matthias regarding widget improvements. We also have a wishlist of widget improvements. I agree that it would make sense to port your dynamic values list filtering Python plugin to C++. In your proposal I would prefer option 1) or try to marry the "Value Relation" widget with the "Relation Reference" widget and introduce your new filtering mechanism. Note that the "relation reference" and the "value relation" widgets both have filter options, but only with in the widget itself, not in relation with other widgets, like your plugin. - Over the years, quite some overlap appeared in the widgets. In my opinion, with QGIS 3.0, we should do an effort to clean up the overlapping widgets. But we'd need an "update strategy" for old obsolete widgets and make sure that the new widget variants really do all that the old widgets could do. As an example: The "Value Relation" and the "Relation Reference" Widgets have a lot of overlaps. Ideally they should be combined into one widget. The newly introduced "External Resource" widget makes the "Photo", "Filename" and potentially also the "Web View" more or less obsolete. I think the QGIS users would prefer a smaller list of widgets with options, and not many overlapping widgets that do very similar things. Andreas On 2016-02-02 09:52, Alessandro Pasotti wrote: > Hi, > > to allow for drill-down forms, a few months ago, I've created a modified > value relation widget with a companion form function that allow to implement > dynamic filtering (or altering) of fields in a form. > > It can be easily ported in the core (it's basically a clone of the existing > value relation widget). > > The widget is available as a python plugin. > http://plugins.qgis.org/plugins/FormAwareValueRelationWidget/ More > information here: > http://www.itopen.it/a-new-qgis-plugin-allows-dynamic-filtering-of-values-in-forms > > The main question is if there is any interest in porting this widget into the > core, then if this should be > 1. a replacement of the existing value relation widget 2. an optional feature > of the existing value relation widget 3. a new widget > > I would like to hear your thoughts about this. > > -- > > Alessandro Pasotti > w3: www.itopen.it [1] Links: -- [1] http://www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Simplify provider side
Il 02/02/2016 00:38, A Huarte ha scritto: > Finally the code was reverted. Thanks a lot to all for your tests! too bad - no hope to have a proper fix? thanks. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Improvements to the value relation widget: port to C++?
Hi all, I also think merging things is the way to go, but we should keep the feature provided by the "value relation" widget : it is not used to add children referring the current object edited, but instead it is used to create a combo box containing labels helping to fill the field data which is a foreign key. For me, the logic is reversed. The data structure is the same, but the with a different point of view ( child or parent). Regards, Michaël 2016-02-02 10:16 GMT+01:00 Neumann, Andreas : > Hi Alessandro, > > Yesterday I had a meeting with Matthias regarding widget improvements. We > also have a wishlist of widget improvements. I agree that it would make > sense to port your dynamic values list filtering Python plugin to C++. > > In your proposal I would prefer option 1) or try to marry the "Value > Relation" widget with the "Relation Reference" widget and introduce your > new filtering mechanism. Note that the "relation reference" and the "value > relation" widgets both have filter options, but only with in the widget > itself, not in relation with other widgets, like your plugin. > > - > > Over the years, quite some overlap appeared in the widgets. In my opinion, > with QGIS 3.0, we should do an effort to clean up the overlapping widgets. > But we'd need an "update strategy" for old obsolete widgets and make sure > that the new widget variants really do all that the old widgets could do. > > As an example: > > The "Value Relation" and the "Relation Reference" Widgets have a lot of > overlaps. Ideally they should be combined into one widget. > > The newly introduced "External Resource" widget makes the "Photo", > "Filename" and potentially also the "Web View" more or less obsolete. > > I think the QGIS users would prefer a smaller list of widgets with > options, and not many overlapping widgets that do very similar things. > > Andreas > > On 2016-02-02 09:52, Alessandro Pasotti wrote: > > Hi, > > to allow for drill-down forms, a few months ago, I've created a modified > value relation widget with a companion form function that allow to > implement dynamic filtering (or altering) of fields in a form. > > It can be easily ported in the core (it's basically a clone of the > existing value relation widget). > > The widget is available as a python plugin. > http://plugins.qgis.org/plugins/FormAwareValueRelationWidget/ > More information here: > > http://www.itopen.it/a-new-qgis-plugin-allows-dynamic-filtering-of-values-in-forms > > The main question is if there is any interest in porting this widget into > the core, then if this should be > 1. a replacement of the existing value relation widget > 2. an optional feature of the existing value relation widget > 3. a new widget > > > I would like to hear your thoughts about this. > > > -- > Alessandro Pasotti > w3: www.itopen.it > > > > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Improvements to the value relation widget: port to C++?
2016-02-02 11:02 GMT+01:00 kimaidou : > Hi all, > > I also think merging things is the way to go, but we should keep the > feature provided by the "value relation" widget : it is not used to add > children referring the current object edited, but instead it is used to > create a combo box containing labels helping to fill the field data which > is a foreign key. For me, the logic is reversed. The data structure is the > same, but the with a different point of view ( child or parent). > > Regards, > Michaël > Hi, I don't see such a difference: the main difference with the current implementation of value relation widget is that the (optional) filtering of the items in the combo is dynamic: every time a value changes in the other fields of the form, the values in the related combo are filtered again against the expression, that in turn has access to the current values of the other fields. This means that the cache for the values in the combo is built against unfiltered values (and can be optionally disabled). If you don't set an expression that uses the new function to access to the other fields in the form, this widget behaves exactly as the current value relation widget. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Simplify provider side
The issue 12298 (https://hub.qgis.org/issues/12298) of Michael Douchin proposes the SDO_UTIL.RECTIFY_GEOMETRY function to simplify (https://hub.qgis.org/attachments/8488/QGIS_oracle_pre_rendering_simplification.diff). I am sorry, but I don't have an Oracle database to test performance. Might someone test it before to create a new pull?Alvaro De: Paolo Cavallini Para: A Huarte ; Médéric Ribreux ; kimaidou CC: "qgis-developer@lists.osgeo.org" Enviado: Martes 2 de febrero de 2016 11:01 Asunto: Re: [Qgis-developer] Simplify provider side Il 02/02/2016 00:38, A Huarte ha scritto: > Finally the code was reverted. Thanks a lot to all for your tests! too bad - no hope to have a proper fix? thanks. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Improvements to the value relation widget: port to C++?
> > I would like to hear your thoughts about this. > I would find this useful it the widget could be enhanced to support dynamically fetching data from the underlying source based on input auto-complete filtering. A particular use case for me is using a large PostgreSQL table of millions of unique text code values. Cheers Jeremy This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Pagure as repo alternative?
While still young, Pagure is a Fedora/Redhat Python host your software project yourself solution, including issue tracker with file upload: https://fedoramagazine.org/pagure-diy-git-project-hosting/ https://pagure.io/docs/pagure/ As said: promissing but I think too young Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Pagure as repo alternative?
On Tue, Feb 02, 2016 at 04:34:26PM +0100, Richard Duivenvoorde wrote: > While still young, Pagure is a Fedora/Redhat Python host your software > project yourself solution, including issue tracker with file upload: > > https://fedoramagazine.org/pagure-diy-git-project-hosting/ > > https://pagure.io/docs/pagure/ > > As said: promissing but I think too young Is there a qgis wiki page describing point-by-point what's limited in the current code hosting setup ? I guess it would help evaluating alternatives. Note that the current OSGeo trac version does support GIT as a repository, see for example https://trac.osgeo.org/geos/browser/php (just saying) --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Question about expression compiling
We are working on the DB2 expression compiler and testing it with a Python driver. For an expression like NAME IS NULL What should be the node type of NULL? It appears to be QgsExpression::ntLiteral but it doesn't seem to have a valid value and fails the call to quotedValue(). For now we are using a hack to check if n->dump() == NULL and treating it as a special case. Also, I assume that ILIKE is a case insensitive LIKE. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Question about expression compiling
Hi David, Have you had a look at the class QgsSqlExpressionCompiler? Other SQL dialects inherit from this class and fine tune it. Most work should already be done in there so you just have to take care of the failing tests. https://github.com/qgis/QGIS/blob/master/src/core/qgssqlexpressioncompiler.cpp Matthias On 02/03/2016 12:01 AM, David Adler wrote: > We are working on the DB2 expression compiler and testing it with a > Python driver. > > For an expression like NAME IS NULL > What should be the node type of NULL? It appears to be > QgsExpression::ntLiteral but it doesn't seem to have a valid value and > fails the call to quotedValue(). > > For now we are using a hack to check if n->dump() == NULL and treating > it as a special case. > > Also, I assume that ILIKE is a case insensitive LIKE. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Matthias Kuhn OPENGIS.ch - https://www.opengis.ch Spatial • (Q)GIS • PostGIS • Open Source signature.asc Description: OpenPGP digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Improvements to the value relation widget: port to C++?
Hi Alessandro, I have no particular opinion about how this is included in the fields and forms stuff best. Just wanted to say thank you for this! It is really a great enhancement! Cheers Stefan > I would like to hear your thoughts about this. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugin [923] Azimuth Measurement approval notification.
Plugin Azimuth Measurement approval by pcav. The plugin version "[923] Azimuth Measurement 0.1 Experimental" is now approved Link: http://plugins.qgis.org/plugins/AzimuthMeasurement/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
