[Qgis-developer] Composer... current status and the way forward?

[Andreas Neumann]

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.dawson at gmail.com 
> <mailto:nyall.dawson at 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 at lists.osgeo.org <mailto:Qgis-developer at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141107/8e9195c5/attachment-0001.html>