[Qgis-developer] Composer item's IDs

Andreas Neumann a.neumann at carto.net
Wed Feb 20 08:14:26 PST 2013


 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


More information about the Qgis-developer mailing list