[Qgis-developer] Re: composer redesign branch

[Marco Hugentobler]

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)

> - 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?

>- 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).

Regards,
Marco

Am Montag 11 Februar 2008 19:14:58 schrieb Martin Dobias:
> Guys,
>
> when talking about improvements with composer, what are your plans -
> do the changes as small as possible or are you open for some more
> improvements? Generally I'd like to see these features:
> - introduce "map rendering context" which will contain information
> about rendering (we've talked about that already on the list)
> - 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.
> - separate map composer frontend and backend, so the backend will be
> moved to core library and could be used in plugins / 3rd party apps
>
> If you like these things (or at least some of them :-) I'll be happy
> to cooperate.
>
> Regards
> Martin



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee