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.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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@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.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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer