I'm not sure about the final scheduling for the composer refactoring.
Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0?
giovanni
Il 11/nov/2014 21:20 Olivier Dalang olivier.dal...@gmail.com ha scritto:
I just checked, there's a rich text example for Qt5 :
PS: assuming the QEP will be accepted...
Il 13/nov/2014 00:05 G. Allegri gioha...@gmail.com ha scritto:
I'm not sure about the final scheduling for the composer refactoring.
Following the discussions about LTS and QGIS 3.0 will it be shifted to 3.0?
giovanni
Il 11/nov/2014 21:20 Olivier
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
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
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
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
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
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
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
On 08/11/2014 6:11 am, Olivier Dalang olivier.dal...@gmail.com 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 ?
It would allow standalone scripts which utilise compositions, or scripts
which
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
11 matches
Mail list logo
