Hi Olivier
3) But then, as Marco Hugentobler said, there's QgsComposerMap which
implements it's own ID which are unique integer inside one
composition.
I removed that implementation, so the normal QgsComposerItem's ID
implementation is used. The QgsComposerMap only overrides the setId()
method to ensure the ID is unique inside one composition.
One problem might be if the user changes composer map ids and other items
depend on it. Therefore it would be good to use the uuid for the references to
the maps (from image item or overview map) but present the name in the
selection dialog.
Regards,
Marco
On 20.02.2013 17:08, Olivier Dalang wrote:
Hi !
So I've been working on this ID stuff and got a proposition (which
I'll post as pull request after testing a little more) :
https://github.com/olivierdalang/Quantum-GIS/tree/ComposerItemsUniqueIds
The idea is to following (this concerns QgsComposerItems) :
1) ID : this property is unaltered. It is still a user-defined QString
which is not necessarily unique. Only thing changed : all
QgsComposerItems now show the ID as a ToolTip. (same behaviour as
current QgsComposerMap)
2) UUID: this is a new property, which is not modifiable. It consists
of a QUuid geneated QString (looking like
{00000000-0000-0000-0000-000000000000} ). The Uuid is generated on
creation. It is kept when cut/paste, but regenerated on copy/paste and
on template loading. This way, the Uuid should always be unique.
So this induces no API changes.
3) But then, as Marco Hugentobler said, there's QgsComposerMap which
implements it's own ID which are unique integer inside one
composition.
I removed that implementation, so the normal QgsComposerItem's ID
implementation is used. The QgsComposerMap only overrides the setId()
method to ensure the ID is unique inside one composition.
This induces an API change, since the ComposerMap's ID now is a
QString instead of an int.
If this is a major problem, 3) could be let as it is now.
Regards,
Olivier
2013/2/19 Marco Hugentobler <marco.hugentob...@sourcepole.ch>:
Thinking about this. There really isn't a reason to force item names/id to
be unqiue . if I want to have three items named the same then that is really
my choice. If I have say three map windows that I >want to set all to the
same extents then I could just call them all "maps" and just loop over all
the items with that name.
There is use for both unique names (or auto-incrementing numbers) and
user-defined names. And both cases are already used:
- auto-incrementing number in QgsComposerMap::mId. Needs to be unique within
the composition because other elements may refer to it (north-arrow items or
overview maps)
- user-defined names: QgsComposerItem::mId (unfortunately with the same
attribute name as the composer map int id).
Regards,
Marco
On 19.02.2013 01:04, Nathan Woodrow wrote:
Thinking about this. There really isn't a reason to force item names/id to
be unqiue . if I want to have three items named the same then that is really
my choice. If I have say three map windows that I want to set all to the
same extents then I could just call them all "maps" and just loop over all
the items with that name.
- sent from a tablet device that isn't an iPad
On 19 Feb 2013 10:54, "Nathan Woodrow" <madman...@gmail.com> wrote:
Personally I'm not a fan of using a uuid unless the user doesn't need to
enter them.
For me a composer item only needs a id or name not both. You can just
store a counter on the composer the item belongs to as only has to be unique
for that composer. I would just auto name them "composeritem_n" and have the
composer assign the name/id when the item is added to the composer. If the
user wants to change it later he can.
- sent from a tablet device that isn't an iPad
On 19 Feb 2013 10:38, "Olivier Dalang" <olivier.dal...@gmail.com> wrote:
OK I've got something which seems to work well using QUuid.
It's easier with QUuid than an incremental id since there's no need to
store the last key.
It already works more or less, I'll make a pull request soon.
What do you think about the other attribute ? (which would be called
smthg like "Internal name", and would replace current id's behavior)
I'm not sure this is useful though. Maybe it will only be confusing to
the user...
Should I add this attribute or not ?
2013/2/18 Nathan Woodrow <madman...@gmail.com>:
Olivier,
I added the item id for that reason. Feel free to rework then so they
are auto generated and unique. That was my intention just never got
around to it.
- Nathan
Sent from some fancy phone looking thingo
From: Olivier Dalang
Sent: 19/02/2013 3:27 AM
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Composer item's IDs
Hi !
I'm developing a plugin which needs to attach some custom data to some
Composer Item's instances.
Thus, I need a way to identify the instances.
I saw that there's an ID attribute in the ComposerItems, but don't
really know how it's supposed to work. It seems for now it's only an
user defined value, which remains empty when the user doesn't provide
it and which also can be duplicated.
So it seems I can't use this as an unique ID.
What's the best way to do that ?
More globally, what is this ID good for ? Is it's behavior not fully
implemented yet ?
I think it would be useful to auto-assign unique which the user
couldn't change. If needed, another attribute ("name" or "tag") could
be added to replace the current "ID" behaviour, allowing the user to
define custom data.
What do you think ?
Thanks !!
Olivier
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
