Hi,
It would be very awesome to have live-linked templates! I would very
much need them. I have a lot of operational projects and it is my fear
that some day some details would change and I need to go into all of the
projects and adopt things like logo, fonts, headers, etc. It would
either require a script to process the .qgs files or a lot of manual work.
So +1 for having live templates. Nyall, maybe you can plan the redesign
in a way to make it possible? I would also participate in financing the
development of these live templates.
Andreas
On 07.11.2014 20:10, Olivier Dalang wrote:
Hi,
I don't get the point in keeping the old classes if we upgrade the
composers to layouts at opening ? Doesn't migration happen at XML level ?
Maybe while thinking about reworking the composer, we could think
about a new feature : real templates (aka "masters" in Indesign).
All elements added to a "master" appear on all the page that apply it.
This is very handy: you can always edit the master (move some
elements, change the fonts/colors, etc.), and the changes are
reflected on all the layouts. The challenging part from an UI point of
view is the required ability to override the content of templates
elements (for instance the extent of a map, the text of a textbox, etc.)
I thought of making a plugin for this, but got discouraged because of
the problem you exposed... So it would be a good test case to see if
the future API for the layouts allows to implement this easily ;)
Thanks !
Olivier
2014-11-07 16:26 GMT+01:00 Andreas Neumann <a.neum...@carto.net
<mailto:a.neum...@carto.net>>:
Hi Nyall,
I also think that option 2 would work best. Option one would be
very confusing (I remember the days when we had two labeling
versions, 2 symbology versions, etc. - awful!).
Thanks,
Andreas
On 07.11.2014 16:16, G. Allegri wrote:
Hi Nyall,
as I already told you privately, I agree with the second
approach: remove the current Composer and guarantee transparent
auto-upgrade of existing layouts in projects.
The improvements to the composer worth the effort, and the
consequent visual impact for users. The important thing is to
guarantee old projects to provide the same results (layouts)
though, without re-designing them from the ground.
Having both the old Composer and the new GUI tools would be
misleading and confusing to the users, and I imagine it would
double the effort to mantain both the tools.
giovanni
2014-11-07 12:37 GMT+01:00 Nyall Dawson <nyall.daw...@gmail.com
<mailto:nyall.daw...@gmail.com>>:
Hi all,
I'm seeking feedback about the best way to move forward with
QGIS' map
composer. I'm currently running up against some large issues
with the
current design and API of composer which are holding back
important
features and fixes. Some of these issues include:
- there's too much composer logic tied up in app and gui.
This makes
it very difficult for plugins to manipulate and export
compositions
without duplicating large blocks of code
- there's too much item-specific logic and handling scattered
through
QgsComposition, QgsComposerView and QgsComposer. This makes it
impossible to have features like plugin generated item types, and
makes maintenance difficult.
- everything is coded to expect measurements and sizes in mm.
I can't
(nicely) add support for other units without breaking api or
resorting
to a lot of hacks
- same for mixed page sizes and orientations within a single
composition, this requires an api break to implement cleanly
- I need to totally break composer api in order to fix the
instability
in undo/redo commands (see http://hub.qgis.org/issues/11371)
- QgsComposition should not require a
QgsMapSettings/QgsMapRenderer.
This should instead be set individually for map items. Doing
so would
pave the way for features such as reprojection support for
individual
map items.
- the composer is full is deprecated methods and legacy api
I've slowly come to the conclusion that the way forward is to
move to
a bunch of new classes, much like what was done with
symbologyV2. If
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9
passes then
these would be named QgsLayout, QgsLayoutDesigner, etc. If
not, well,
I'll have to resort to QgsCompositionV2, etc.
The potential problem with this approach is how to handle the
GUI and
existing projects. As far as I can see, there's a few options:
1. Expose both the existing composer and the new layout
designer to
users. Composers aren't automatically upgraded to layouts. This
approach means that existing PyQgis code and plugins will still
function for existing projects, but at the expense of a confusing
experience for users.
2. Add all the new layout classes and keep the existing composer
classes. Composer would NOT be exposed in the GUI and
compositions are
upgraded to layouts when projects are opened. This approach
means that
standalone python code would still operate, but plugins or
code which
are designed to be run from within QGIS would no longer function.
3. Move totally to the new layout classes and remove all composer
classes (unlikely)
I'm leaning toward option 2, but what are you thoughts?
What's the
best approach to move forward? Obviously I'll submit all this
as a QEP
when the plans are finalised, but for now I'm just after
advice on the
preferred approach.
Nyall
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Giovanni Allegri
http://about.me/giovanniallegri
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto: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
