[Qgis-developer] Re: composer redesign branch

[Marco Hugentobler]

Hi Martin,

So my suggestion is to have the rendering context somehow like this:

class QgsMapRenderContext
{
	QgsMapToPixel mMapToPixel;
	QgsCoordinateTransform mCoordTransform;
	QgsRect mExtent;
	bool drawEditingInformation;
	bool mRenderingStopped;
	double mResolutionRatio;
}; 

The resolution ratio is usually 1, except when drawing to a different paint 
device (like QPrinter). I hope it will allow to consider for different line 
width / symbol sizes on these output devices.

> 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

Maybe QgsComposerView (derived from QGraphicsView) could go to gui and the 
composer items to core? Then client applications (or some interface component 
in core) could arrange the items and call QGraphicsScene::render.

Regards,
Marco

Am Samstag 01 März 2008 19:16:59 schrieb 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



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