[Qgis-developer] Composer... current status and the way forward?
Andreas Neumann
a.neumann at carto.net
Fri Nov 7 07:26:34 PST 2014
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>
More information about the Qgis-developer
mailing list