<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Andreas<br>
<br>
<br>
<div class="moz-cite-prefix">On 07.11.2014 20:10, Olivier Dalang
wrote:<br>
</div>
<blockquote
cite="mid:CAExk7p1MFxA6vxp5qnWUmPf_-yFDRJxUyhqzjWg71YNsO7V2Jw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi,<br>
<div><br>
</div>
<div>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 ?</div>
<div><br>
</div>
<div><br>
</div>
<div>Maybe while thinking about reworking the composer, we could
think about a new feature : real templates (aka "masters" in
Indesign).</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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 ;)</div>
<div><br>
</div>
<div>Thanks !</div>
<div><br>
</div>
<div>Olivier</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-11-07 16:26 GMT+01:00 Andreas
Neumann <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi Nyall,<br>
<br>
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!).<br>
<br>
Thanks,<br>
Andreas
<div>
<div class="h5"><br>
<br>
<div>On 07.11.2014 16:16, G. Allegri wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Nyall,
<div>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.</div>
<div>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. </div>
<div>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.</div>
<div><br>
</div>
<div>giovanni</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-11-07 12:37
GMT+01:00 Nyall Dawson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:nyall.dawson@gmail.com"
target="_blank">nyall.dawson@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi all,<br>
<br>
I'm seeking feedback about the best way to
move forward with QGIS' map<br>
composer. I'm currently running up against
some large issues with the<br>
current design and API of composer which are
holding back important<br>
features and fixes. Some of these issues
include:<br>
<br>
- there's too much composer logic tied up in
app and gui. This makes<br>
it very difficult for plugins to manipulate
and export compositions<br>
without duplicating large blocks of code<br>
- there's too much item-specific logic and
handling scattered through<br>
QgsComposition, QgsComposerView and
QgsComposer. This makes it<br>
impossible to have features like plugin
generated item types, and<br>
makes maintenance difficult.<br>
- everything is coded to expect measurements
and sizes in mm. I can't<br>
(nicely) add support for other units without
breaking api or resorting<br>
to a lot of hacks<br>
- same for mixed page sizes and orientations
within a single<br>
composition, this requires an api break to
implement cleanly<br>
- I need to totally break composer api in
order to fix the instability<br>
in undo/redo commands (see <a
moz-do-not-send="true"
href="http://hub.qgis.org/issues/11371"
target="_blank">http://hub.qgis.org/issues/11371</a>)<br>
- QgsComposition should not require a
QgsMapSettings/QgsMapRenderer.<br>
This should instead be set individually for
map items. Doing so would<br>
pave the way for features such as reprojection
support for individual<br>
map items.<br>
- the composer is full is deprecated methods
and legacy api<br>
<br>
I've slowly come to the conclusion that the
way forward is to move to<br>
a bunch of new classes, much like what was
done with symbologyV2. If<br>
<a moz-do-not-send="true"
href="https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9"
target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9</a>
passes then<br>
these would be named QgsLayout,
QgsLayoutDesigner, etc. If not, well,<br>
I'll have to resort to QgsCompositionV2, etc.<br>
<br>
The potential problem with this approach is
how to handle the GUI and<br>
existing projects. As far as I can see,
there's a few options:<br>
1. Expose both the existing composer and the
new layout designer to<br>
users. Composers aren't automatically upgraded
to layouts. This<br>
approach means that existing PyQgis code and
plugins will still<br>
function for existing projects, but at the
expense of a confusing<br>
experience for users.<br>
2. Add all the new layout classes and keep the
existing composer<br>
classes. Composer would NOT be exposed in the
GUI and compositions are<br>
upgraded to layouts when projects are opened.
This approach means that<br>
standalone python code would still operate,
but plugins or code which<br>
are designed to be run from within QGIS would
no longer function.<br>
3. Move totally to the new layout classes and
remove all composer<br>
classes (unlikely)<br>
<br>
I'm leaning toward option 2, but what are you
thoughts? What's the<br>
best approach to move forward? Obviously I'll
submit all this as a QEP<br>
when the plans are finalised, but for now I'm
just after advice on the<br>
preferred approach.<br>
<br>
Nyall<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org"
target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">Giovanni Allegri<br>
<a moz-do-not-send="true"
href="http://about.me/giovanniallegri"
target="_blank">http://about.me/giovanniallegri</a>
<div>Twitter: <a moz-do-not-send="true"
href="https://twitter.com/_giohappy_"
target="_blank">https://twitter.com/_giohappy_</a></div>
<div>blog: <a moz-do-not-send="true"
href="http://blog.spaziogis.it"
target="_blank">http://blog.spaziogis.it</a><br>
GEO+ geomatica in Italia <a
moz-do-not-send="true"
href="http://bit.ly/GEOplus"
target="_blank">http://bit.ly/GEOplus</a></div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Qgis-developer mailing list
<a moz-do-not-send="true" href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a moz-do-not-send="true" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>