[Qgis-developer] Composer Management
Bernhard Ströbl
bernhard.stroebl at jena.de
Thu Feb 28 23:15:07 PST 2013
Hi Larry,
Am 01.03.2013 03:28, schrieb Larry Shaffer:
> Hi,
>
> On Thu, Feb 28, 2013 at 11:10 AM, Larry Shaffer <larrys at dakotacarto.com
> <mailto:larrys at dakotacarto.com>> wrote:
>
> Hi,
>
> On Thu, Feb 28, 2013 at 10:11 AM, Bernhard Ströbl
> <bernhard.stroebl at jena.de <mailto:bernhard.stroebl at jena.de>> wrote:
>
> Hi Larry,
>
> Am 28.02.2013 17:38, schrieb Larry Shaffer:
>
> Hi,
>
> On Thu, Feb 28, 2013 at 12:01 AM, Bernhard Ströbl
> <bernhard.stroebl at jena.de <mailto:bernhard.stroebl at jena.de>
> <mailto:bernhard.stroebl at jena.__de
> <mailto:bernhard.stroebl at jena.de>>> wrote:
>
> Hi Kelly,
>
> I am doing something similar for my company but I am
> developing it
> for the next release, because master has
> QgsComposition::____loadFromTemplate method, which 1.8
> has not.
>
> However to get a new printComposer you can use
> self.iface.____actionPrintComposer().trigger(____)
> which adds a new composer to the project's list of
> composers.
>
>
> In master branch, and in the last week, the
> actionPrintComposer() (i.e.
> QgisApp::createNewComposer) action will now present the user
> with a
> dialog to help choose a unique composer title, before the
> composer is
> created. Since iface.actionPrintComposer().__trigger() still
> appears to be
> the best means of programmatically creating a new composer, this
> presents an issue.
>
>
> hmm, my master dates from Febr. 21, have to update...
> Is this a needed feature? I mean any text processing software
> creates "document1" or "unknown1" if you hit the new document button
>
>
> IMO, yes. With the text processing software you note, it creates the
> "document 1" with the understanding that the user will eventually
> have to save the file, thereby prompting the user to change the
> default name.
>
> With composers there is no prompted saving; they are automatically
> saved into the project with the default name. This causes the user
> to have to find a means of changing the name later, e.g. in the
> Composer Manager, and in the meantime they have no hint at what
> content "Composer #n" contains. With a prompt, the user can define
> the name up front, using existing names to build on (from editable
> combobox) and use the Manager later, only if needed.
>
> Again, we can add a preference in Options for turning it on/off
> (with a default of on), but that would have to be checked and turned
> off programmatically in scripts if there is no other means of
> generating a blank composer.
OK, agreed, it is better than the current behaviour.
>
>
> There are a couple of possible solutions:
>
> * Expose Qgis::createNewComposer in iface (which returns
> pointer to new
> composer). Maybe adding duplicateComposer, deleteComposer and
> deletePrintComposers, as well. Makes the most sense to me.
> New PyQGIS
> code would be different from 1.8.
>
>
> +1
> the actionPrintComposer().trigger(__) thing is not so
> straightforward
>
>
> Ok, I've added these (excepting deletePrintComposers) to iface [0]. So
> you can now do the following:
>
> cv = iface.createNewComposer('test')
> cv2 = iface.duplicateComposer(cv, 'test2')
>
> for c in iface.activeComposers():
> iface.deleteComposer(c)
>
> Like the existing iface.activeComposers() they work via QgsComposerView,
> not QgsComposer directly. Not sure why, but QgsComposer is unavailable
> in the API/bindings (I figure for a good reason, e.g. like QgisApp).
> Please test, if you have the time.
>
> [0]
> https://github.com/qgis/Quantum-GIS/commit/4941a0e5dc78103f895bcf6f313e2d0c76ad64b9
works great!
>
> * Add a preference in Options for turning it on/off (e.g.
> [x] Prompt for
> composer name), and maybe simple get/set methods to QgisApp
> and iface.
> New PyQGIS code would require a couple of lines of
> additional code if
> the prompt was not to be shown.
>
> * Use a different action in the GUI than
> actionPrintComposer(). Might
> lead to some confusion, having semi-redundant actions. New
> PyQGIS code
> remains identical to 1.8.
>
>
> But AFAIK you can not load a template into it with 1.8
>
>
> I think this is possible. QgsComposition has readXML and
> addItemsFromXML
> exposed in 1.8 [0]. If you look at loadFromTemplate[1], the
> initial
> routines are for clearing a composition's existing items
> (btw: I think
> that is bad. IMO loading from a template should always be in
> a fresh
> composer).
>
>
> Not neccessarily, I sometimes happen to work on a composer
> (created from template) but I somehow screw things up and then
> it is nice to restart again without leaving the composer. This
> is the behavior of QGIS, so IMHO it is ok if loadFromTemplate
> behaves in the same manner.
>
>
> Maybe a parameter option to the function, or a new function, and a
> new action in the menu, e.g. New from Template, to accompany Load
> Template? I think 'load' should always mean 'replace existing'. I
> envision a user accidentally clearing all their work in the current
> composer, when they thought they were getting a fresh composer based
> upon the template.
>
>
> I've added New from Template to the Composer menu [1]. I think the
> distinction between the actions is very clear now. Btw, Composer Manager
> also only adds templates to new composers, but with no clear indication
> on where those templates are located. They are in
> QgsApplication::pkgDataPath()/composer_templates/ (inside bundled app on
> Mac) instead of under say ~/.qgis/composer_templates/. I think that
> needs adjusted.
>
> [1]
> https://github.com/qgis/Quantum-GIS/commit/7f83b12afddeb7f9efc005a943e45b64b2deb1a7
good, this makes it clear for users
>
> Regards,
>
> Larry
>
> I don't think "template load replaces existing" is the behavior of
> QGIS at the QMainWindow level, maybe with styles, etc. For example,
> when loading a project template, the menu action is New Project from
> Template (there is no load option). I think we need the distinction,
> and option, between new and load with templates, especially when
> they are auto-saved, or users may lose work.
I was not meaning it is the general behaviour of QGIS but its behaviour
in the composer window. So my point was that the api function should
behave as the button with the same name.
Bernhard
>
> Regards,
>
> Larry
>
> Not a concern if you are starting with a fresh composer
> anyway. After that, there is substitution replacement (not
> sure if
> relevant to 1.8), reading of the XML doc, then adding the
> items, all of
> which should be doable in Python, unless I am mistaken.
>
>
> I did not fiddle with those 1.8 methods, but thinking about it
> it should even be possible to do substitution using PyQt
> methods, i.e.
> 1) read file
> 2) do substitutions
> 3) create the XMLDoc
> 4) load into composer
>
> I will check and report back
>
> Bernhard
>
>
> [0] http://qgis.org/api/1.8/__classQgsComposition.html
> <http://qgis.org/api/1.8/classQgsComposition.html>
> [1]
> https://github.com/qgis/__Quantum-GIS/blob/master/src/__core/composer/qgscomposition.__cpp#L382
> <https://github.com/qgis/Quantum-GIS/blob/master/src/core/composer/qgscomposition.cpp#L382>
>
>
> Regards,
>
> Larry
>
> Bernhard
>
> Am 28.02.2013 03:38, schrieb Kelly Thomas:
>
> Hello,
>
>
> I am building a python plugin for QGIS 1.8 and am
> trying to
> manipulate the map composers.
>
> The goal is to load a template, customise a few
> elements, and
> then leave the composer window up for the user to
> modify / print
> / etc.
>
> I know that current composers can be listed by calling
> qgis.utils.iface.____activeComposers().
>
> However I have been unable to create or destroy
> composer windows
> without resorting to spoofing user input to the
> composer manager
> dialog!
>
> Is there a technique by which I can add/remove
> composers
> programmatically?
>
> Thanks,
> Kelly Thomas
> ___________________________________________________
__________ Information from ESET Mail Security, version of virus signature database 8064 (20130301) __________
The message was checked by ESET Mail Security.
http://www.eset.com
More information about the Qgis-developer
mailing list