Hi Larry
>So, is anyone working on this? I can devote some time this coming
weekend. Pretty important to fix this, then make it compatible with <
2.0 projects.
Thanks for looking into this .+1
>Similarly, data defined properties are only a 1-to-1 relationship
(currently property-to-field index), with no defined relationship
between themselves, the QgsPalLayerSettings (if any) to override, the
>associated QgsField, any defined QgsExpression, or any assigned
'buddy' gui elements. Nathan suggested a data binding class that could
possibly be inherited by gui classes to make utilizing data >defined
overrides (not just for labeling) within the app easier and more
abstracted. I think it is worth pursuing.
Sounds interesting to use expressions for data defined properties and to
have a generic class for it (e.g. also for data defined symbology, etc.).
Regards,
Marco
On 31.01.2013 02:42, Larry Shaffer wrote:
Hi,
On Mon, Jan 28, 2013 at 6:17 AM, Régis Haubourg
<[email protected]
<mailto:[email protected]>> wrote:
martin Dobias wrote
> I have briefly looked into the code and it seems that new labeling
>> stores data-defined attributes by index instead of name. If so,
>> that's
>> the source of the problem and it should be changed to read/write
>> names
Hi all,
+1 for switching storage of data defined fields with names and not
indexes.
It was a limit I previously pointed and this is really weak if
data field
order change. But we need retrocompatibility with old projects.
Does that
sounds possible?
régis
So, is anyone working on this? I can devote some time this coming
weekend. Pretty important to fix this, then make it compatible with <
2.0 projects.
Similarly, data defined properties are only a 1-to-1 relationship
(currently property-to-field index), with no defined relationship
between themselves, the QgsPalLayerSettings (if any) to override, the
associated QgsField, any defined QgsExpression, or any assigned
'buddy' gui elements. Nathan suggested a data binding class that could
possibly be inherited by gui classes to make utilizing data defined
overrides (not just for labeling) within the app easier and more
abstracted. I think it is worth pursuing.
On another note (and yet a bunch more refactoring), most of the
QgsPalLayerSettings are directly accessed public properties. These
should probably be switched over to some form of container object
(QMap?) no?
Regards,
Larry
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Labeling-data-defined-fields-shifted-after-new-vector-API-tp5030238p5030276.html
Sent from the Quantum GIS - Developer mailing list archive at
Nabble.com.
_______________________________________________
Qgis-developer mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
