Nyall, 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)
Nor can we leave users' previously saved composers broken. So #2 seems to be the wining option. A fundamental change like that would go very well with a name change too. Every move that gets us closer to having non mm units is worth the sweat :) On 7 Nov 2014 18:38, "Nyall Dawson" <nyall.daw...@gmail.com> wrote: > 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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
