Hi Olivier,
Regarding HTML editor:
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?
Regarding live templates:
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 ;-)
Andreas
On 11.11.2014 12:46, Olivier Dalang wrote:
Hi,
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.
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 ?).
And more about the live templates idea (if it's too much of a thread
hijacking please start another one) :
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).
http://helpx.adobe.com/indesign/using/master-pages.html
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).
The property system you're mentioning would probably be an excellent
thing to manage inheritance.
And then, there's a question about whether the masters are global or
per-project.
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.
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).
Thanks a lot for those bigger refactoring initiatives !
Olivier
2014-11-11 10:52 GMT+01:00 Andreas Neumann <[email protected]
<mailto:[email protected]>>:
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 <[email protected]
<mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>>:
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
[email protected]
<mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
<mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
