[Qgis-developer] Composer... current status and the way forward?
Andreas Neumann
a.neumann at carto.net
Tue Nov 11 01:52:38 PST 2014
Hi,
It would be very awesome to have live-linked templates! I would very
much need them. I have a lot of operational projects and it is my fear
that some day some details would change and I need to go into all of the
projects and adopt things like logo, fonts, headers, etc. It would
either require a script to process the .qgs files or a lot of manual work.
So +1 for having live templates. Nyall, maybe you can plan the redesign
in a way to make it possible? I would also participate in financing the
development of these live templates.
Andreas
On 07.11.2014 20:10, Olivier Dalang wrote:
> Hi,
>
> I don't get the point in keeping the old classes if we upgrade the
> composers to layouts at opening ? Doesn't migration happen at XML level ?
>
>
> Maybe while thinking about reworking the composer, we could think
> about a new feature : real templates (aka "masters" in Indesign).
>
> All elements added to a "master" appear on all the page that apply it.
> This is very handy: you can always edit the master (move some
> elements, change the fonts/colors, etc.), and the changes are
> reflected on all the layouts. The challenging part from an UI point of
> view is the required ability to override the content of templates
> elements (for instance the extent of a map, the text of a textbox, etc.)
>
> I thought of making a plugin for this, but got discouraged because of
> the problem you exposed... So it would be a good test case to see if
> the future API for the layouts allows to implement this easily ;)
>
> Thanks !
>
> Olivier
>
>
>
> 2014-11-07 16:26 GMT+01:00 Andreas Neumann <a.neumann at carto.net
> <mailto:a.neumann at carto.net>>:
>
> 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 <mailto:Qgis-developer at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141111/96057893/attachment-0001.html>
More information about the Qgis-developer
mailing list