[Qgis-developer] Composer item's IDs

Tue Feb 26 15:19:01 PST 2013

Hi !

So here's a pull request about that :
https://github.com/qgis/Quantum-GIS/pull/443

This contains only the UUID part, so there's no API change (and no
modification on the QgsComposerItem::id() vs QgsComposerMap::id() problem).

Regards,

Olivier

2013/2/21 Marco Hugentobler <marco.hugentobler at sourcepole.ch>

> 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<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<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<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<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 <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<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 <marco.hugentobler at sourcepole.ch>
> http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130227/7ca40403/attachment.html>