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 <[email protected]>: > 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 <[email protected]>: >>>> >>>> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]>: >>>>> > 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: [email protected] >>>>> > 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 >>>>> > [email protected] >>>>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >>> >>> >>> _______________________________________________ >>> Qgis-developer mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >>> >>> -- >>> Dr. Marco Hugentobler >>> Sourcepole - Linux & Open Source Solutions >>> Weberstrasse 5, CH-8004 Zürich, Switzerland >>> [email protected] http://www.sourcepole.ch >>> Technical Advisor QGIS Project Steering Committee >>> >>> >>> _______________________________________________ >>> Qgis-developer mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > -- > -- > Andreas Neumann > Böschacherstrasse 10A > 8624 Grüt (Gossau ZH) > Switzerland > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
