[Qgis-developer] Composer item's IDs

Wed Feb 20 08:49:30 PST 2013

I'm not familiar at all with QGIS Server...
I looked in the source, found some reference to the composer map id in
qgsconfigparser.cpp:432, but I don't really understand how it's used.
I think this is probably affected by 3). Any help on this would be
welcome !

2013/2/20 Andreas Neumann <a.neumann at carto.net>:
> Hi,
>
> When dealing with these ID changes - can you please make sure that the QGIS
> server GetPrint command still works? These IDs are used in QGIS server to
> identify e.g. text labels that can be replaced by the client. Or to identify
> maps that need rotation or map extents.
>
> It would be nice if this functionality would stay intact.
>
> Other than that, your proposal sounds fine to me (not knowing the technical
> implications).
>
> Andreas
>
>
> On Wed, 20 Feb 2013 17:08:41 +0100, 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
>>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> --
> Andreas Neumann
> Böschacherstrasse 10A
> 8624 Grüt (Gossau ZH)
> Switzerland
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer