<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Olivier,<br>
<br>
Regarding HTML editor:<br>
I very briefly discussed this with Nyall (and got an offer to do
it)). I proposed to embed a Javascript based HTML editor (like
TinyMCE (LGPL)). However, Nyall is probably now busy with
composer/report builder. So it would probably be ok, if someone else
works on this. I would also like to see this HTML editor in a text
area widget - so people could write rich text in an attribute form.
Maybe there is also a qt-based rich text widget we could use?<br>
<br>
Regarding live templates:<br>
I was hoping for a global live template that I could link into many
projects. Otherwise it wouldn't help me much. On the other hand I
don't need the overrides (maybe only the map title). I would only
put fixed content in the live templates that needs to be on every
print out (like company logo, print date, disclaimer, contact
information, etc.). However, maybe one day I would need the
overrides - one never knows ;-)<br>
<br>
Andreas<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 11.11.2014 12:46, Olivier Dalang
wrote:<br>
</div>
<blockquote
cite="mid:CAExk7p0VeD+r1n_R4AxneSVBMpd1-b9VDPKRGwc-EsvyN0HO5w@mail.gmail.com"
type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div><br>
</div>
<div>Another thing which deserves some work IMO is the text
boxes : either you have to write HTML, or you're limited to 1
font/color/size per text box. Even if it's not really linked
to the global structure of the composer, an improvement on
this would have great impact on usability.</div>
<div><br>
</div>
<div>There must be some lightweight wysiwyg html editor library
hat we could use ? Ideally it should implement styles that you
can apply throughout a project (probably through css classes,
but I have the feeling someone already talked about this idea
?).</div>
<div><br>
</div>
<div><br>
</div>
<div>And more about the live templates idea (if it's too much of
a thread hijacking please start another one) :</div>
<div><br>
</div>
<div>Maybe to avoid confusion between templates and live
templates, we could call the live templates "masters" ? That's
how they are called in Adobe Indesign (which is probably the
most polished layouting software around).</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://helpx.adobe.com/indesign/using/master-pages.html">http://helpx.adobe.com/indesign/using/master-pages.html</a><br>
</div>
<div><br>
</div>
<div>The thing Indesign isn't not doing well IMO is overrides :
it involves an awkward keyboard shortcut and it's hard to know
what exactly is overridden and what's not (what element, and
what part of the element).</div>
<div>The property system you're mentioning would probably be an
excellent thing to manage inheritance.</div>
<div><br>
</div>
<div>And then, there's a question about whether the masters are
global or per-project.</div>
<div>The problem with global masters is that you can have
effects on other files without knowing it, and also that
projects may display differently on different setups. I think
we should only have per-project masters.</div>
<div>And updating a project's layouts only involves reimporting
the main master once (that may be a bit tricky though if we
want to keep overrides, but using composer's items UUIDs we
may make it work for some simple cases).</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks a lot for those bigger refactoring initiatives !</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-11 10:52 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,<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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Andreas</font></span>
<div>
<div class="h5"><br>
<br>
<br>
<div>On 07.11.2014 20:10, Olivier Dalang wrote:<br>
</div>
<blockquote 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><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"
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>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>