[Qgis-developer] Composer item's IDs

[Marco Hugentobler]

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.hugentobler at 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" <madmanwoo at 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.dalang at 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 <madmanwoo at 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 at 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 at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee