<div dir="ltr">Hi,<br><div><br></div><div>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 ?</div><div><br></div><div><br></div><div>Maybe while thinking about reworking the composer, we could think about a new feature : real templates (aka "masters" in Indesign).</div><div><br></div><div>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.)</div><div><br></div><div>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 ;)</div><div><br></div><div>Thanks !</div><div><br></div><div>Olivier</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-07 16:26 GMT+01:00 Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Nyall,<br>
<br>
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!).<br>
<br>
Thanks,<br>
Andreas<div><div class="h5"><br>
<br>
<div>On 07.11.2014 16:16, G. Allegri wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Nyall,
<div>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.</div>
<div>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. </div>
<div>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.</div>
<div><br>
</div>
<div>giovanni</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-11-07 12:37 GMT+01:00 Nyall Dawson
<span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'm seeking feedback about the best way to move forward with
QGIS' map<br>
composer. I'm currently running up against some large issues
with the<br>
current design and API of composer which are holding back
important<br>
features and fixes. Some of these issues include:<br>
<br>
- there's too much composer logic tied up in app and gui.
This makes<br>
it very difficult for plugins to manipulate and export
compositions<br>
without duplicating large blocks of code<br>
- there's too much item-specific logic and handling
scattered through<br>
QgsComposition, QgsComposerView and QgsComposer. This makes
it<br>
impossible to have features like plugin generated item
types, and<br>
makes maintenance difficult.<br>
- everything is coded to expect measurements and sizes in
mm. I can't<br>
(nicely) add support for other units without breaking api or
resorting<br>
to a lot of hacks<br>
- same for mixed page sizes and orientations within a single<br>
composition, this requires an api break to implement cleanly<br>
- I need to totally break composer api in order to fix the
instability<br>
in undo/redo commands (see <a href="http://hub.qgis.org/issues/11371" target="_blank">http://hub.qgis.org/issues/11371</a>)<br>
- QgsComposition should not require a
QgsMapSettings/QgsMapRenderer.<br>
This should instead be set individually for map items. Doing
so would<br>
pave the way for features such as reprojection support for
individual<br>
map items.<br>
- the composer is full is deprecated methods and legacy api<br>
<br>
I've slowly come to the conclusion that the way forward is
to move to<br>
a bunch of new classes, much like what was done with
symbologyV2. If<br>
<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9</a>
passes then<br>
these would be named QgsLayout, QgsLayoutDesigner, etc. If
not, well,<br>
I'll have to resort to QgsCompositionV2, etc.<br>
<br>
The potential problem with this approach is how to handle
the GUI and<br>
existing projects. As far as I can see, there's a few
options:<br>
1. Expose both the existing composer and the new layout
designer to<br>
users. Composers aren't automatically upgraded to layouts.
This<br>
approach means that existing PyQgis code and plugins will
still<br>
function for existing projects, but at the expense of a
confusing<br>
experience for users.<br>
2. Add all the new layout classes and keep the existing
composer<br>
classes. Composer would NOT be exposed in the GUI and
compositions are<br>
upgraded to layouts when projects are opened. This approach
means that<br>
standalone python code would still operate, but plugins or
code which<br>
are designed to be run from within QGIS would no longer
function.<br>
3. Move totally to the new layout classes and remove all
composer<br>
classes (unlikely)<br>
<br>
I'm leaning toward option 2, but what are you thoughts?
What's the<br>
best approach to move forward? Obviously I'll submit all
this as a QEP<br>
when the plans are finalised, but for now I'm just after
advice on the<br>
preferred approach.<br>
<br>
Nyall<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">Giovanni Allegri<br>
<a href="http://about.me/giovanniallegri" target="_blank">http://about.me/giovanniallegri</a>
<div>Twitter: <a href="https://twitter.com/_giohappy_" target="_blank">https://twitter.com/_giohappy_</a></div>
<div>blog: <a href="http://blog.spaziogis.it" target="_blank">http://blog.spaziogis.it</a><br>
GEO+ geomatica in Italia <a href="http://bit.ly/GEOplus" target="_blank">http://bit.ly/GEOplus</a></div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Qgis-developer mailing list
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br></div>