[Qgis-developer] Re: composer redesign branch

[Martin Dobias]

Hi Marco!

On Sat, Mar 1, 2008 at 5:29 PM, Marco Hugentobler
<marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin and others,
>
>  I'd like to come back to the composer redesign idea. I'd prefer to do the
>  redesign in steps, so not all three things at once. Just because it's easier
>  to get started and more motivating if the changes can be merged back to trunk
>  soon. As you already wrote, the first step (map rendering context) would be
>  basically a rearrangement of arguments. And in my opinion, it could already
>  solve some of the most basic problems:
>
>  -possibility to stop map rendering
>  -difference between resolution of output device could be a member of map
>  rendering context (e.g. ratio of resolution between screen and current device
>  in x- and y- direction)

You're right, probably doing the changes in iterations will be a
better deal than creating a huge set of changes and then waiting long
time until it gets merged. So I agree with creating rendering context
first, merging it back to trunk and then to start thinking of more
advanced topics.


>  > - improve renderers' interface so that renderer itself will do the
>  > drawing (instead of letting QgsVectorLayer do the real drawing). This
>  > will help renderer to decide whether to draw and cache pixmaps
>  > depending on the rendering context (i.e. drawing to a pixmap or
>  > drawing to vector output). Moreover this will enable clean
>  > implementation of advanced renderers like drawing arrows etc.
>
>  I like this too. As I see it, it would involve many changes to all the
>  renderer classes, the dialogs and also the project file. Would you mind if we
>  do these changes in the longer term, or at least after step1 has been merged
>  to trunk?

Yes, it makes sense!


>  >- separate map composer frontend and backend, so the backend will be
>  >moved to core library and could be used in plugins / 3rd party apps
>
>  I also like this idea. What functionality of the print composer would you like
>  to see in core?
>  The composer (or parts of it) could also be moved to gui such that plugins
>  have access to the composer dialog (or to parts of it).

I'd like to have a good map printing platform in core library :-)
It should be as flexible as possible, while being easy to use: create
map composer object, give it a set of layers, tell it how to lay out
the page(s) - manually or using templates and being able to do output
to printer, pdf, svg, png etc.
I can see this change also in several steps:
- separation of backend from current implementation of map composer to
core library
- addition of more functionality like loading / saving of templates,
set of default templates etc.
- making map composer gui available in gui library

Regards
Martin