[Qgis-developer] new generation symbology

[Hugentobler Marco]

Hi Martin

>Right, using decorator patter might be a solution. But... in fact what
>other decorations will we need? I can't really think of more useful
>decorations now.
>
>I'm asking that with KISS principle in mind: unnecessary complexity
>should be avoided. Adding support for additional decorators might lead
>to more complex code, more complex GUI and new bugs...

Go to a vector drawing program, say inkscape. Draw a line and go to 'stroke style'. You'll find about 50 types as 'begin markers', 'middle markers' and 'end markers'. I think it would make the class LineSymbol very hard to read if all of those would be hard coded the same way as the _draw_arrow function is now.
And there are more possible decorators for special purposes. Think of cold front and warm front symbols in meteorology. Or another one would be middle markers in certain distance interval (so not at the edge points).
But you might also keep the arrows hardcoded as they are now and additional ones could be added as decorators (e.g. by third party people with special purpose applications).

Regards,
Marco


-----Ursprüngliche Nachricht-----
Von: Martin Dobias [mailto:wonder.sk at gmail.com]
Gesendet: Mi 21.01.2009 14:54
An: Hugentobler  Marco
Cc: qgis-developer at lists.osgeo.org
Betreff: Re: [Qgis-developer] new generation symbology
 
On Wed, Jan 21, 2009 at 2:25 PM, Hugentobler  Marco
<marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin
>
>>Well, but adding ArrowLineSymbolLayer would mean that people will need
>>to duplicate code from SimpleLineSymbolLayer and implement the
>>decoration. And I don't like the idea of code duplication.
>>But probably it would be wise to move arrow decoration from LineSymbol
>>to LineSymbolLayer but keep it available for any line symbol. What do
>>you think?
>
> Maybe you know the decorator pattern from the 'design pattern' book (Gamma et al.). I think that would be the most elegant solution for this problem as it allows to add new decorations by adding new subclasses. The code duplication is avoided by a reference to another LineSymbolLayer object and by calling the 'renderPolyline' method of that object before drawing the arrow.

Right, using decorator patter might be a solution. But... in fact what
other decorations will we need? I can't really think of more useful
decorations now.

I'm asking that with KISS principle in mind: unnecessary complexity
should be avoided. Adding support for additional decorators might lead
to more complex code, more complex GUI and new bugs...


>>I think that will be possible. Imagine that we add
>> QgsVectorLayer::drawV2() function that will use new rendering
>> capabilities, while the original QgsVectorLayer::draw() will keep
>> working. Similarly, the new classes might be kept in an other
>> directory and with different names, e.h. QgsSymbolV2, QgsRendererV2.
>> Once this will be implemented in core library, it will be possible to
>> alter QgsMapRenderer, QgsMapCanvas and QGIS user interface to use the
>> new classes.
>
> Hm, it's not clear to me how QgsMapRender knows if it should call the old draw method or the new one.
> But I'm going to read the RFC.

There are some possibilities - e.g. adding a function
QgsMapRenderer::setRendererVersion() with an enum as a parameter which
would determine whether QgsRenderer or QgsRendererV2 should be used in
rendering.

Martin