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

[G. Allegri]

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>:

> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141107/1fa7b58e/attachment.html>