<p dir="ltr">Nyall,</p>
<p dir="ltr">Please, let's not go down the road of two options to do the same thing (ala double symbology & double labelling engine era of qgis 1.x)</p>
<p dir="ltr">Nor can we leave users' previously saved composers broken.</p>
<p dir="ltr">So #2 seems to be the wining option.</p>
<p dir="ltr">A fundamental change like that would go very well with a name change too.</p>
<p dir="ltr">Every move that gets us closer to having non mm units is worth the sweat :)</p>
<div class="gmail_quote">On 7 Nov 2014 18:38, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br type="attribution"><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">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>