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.hugentob...@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@sourcepole.**ch<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<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<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@sourcepole.**ch <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<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@sourcepole.**ch <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