[Qgis-developer] Ellipse renderer

Marco Hugentobler marco.hugentobler at sourcepole.ch
Tue Jul 5 04:19:33 EDT 2011


Hi Martin

Welcome back :-)

Thank you for reviewing the ellipse renderer changes.

> However would not it be better to add data defined fields to the
> simple marker symbol layer instead of creating a new one? The ellipse
> symbol layer seem to duplicate a lot of code, the only difference I
> see is that ellipse marker supports unequal width and height).

Yes, it is width<->height, outlinewith option and data defined fields which are 
new (whereas it lacks x-/y-shift). The idea of the ellipse renderer was to 
have minimal impact on existing classes. But yes, bringing the additions into 
the simple marker class is also my preferred solution.

> I am merely a fan of "Advanced" buttons that show
> this functionality (maybe in a separate dialog or by adding further
> widgets). I guess this way the regular users do not get overwhelmed
> with complexity and power users are happy.

I don't have a strong opinion here. A dialog with an "Advanced" extension 
sounds good to me. Do we already have examples of such dialogs in QGIS? Tim, 
what do the HIG say?

> One more technical issue: in the ellipse symbol layer you store
> indexes together with the field names. This is suboptimal and the
> field indexes should be resolved in startRender() method.

I agree, storing only the name would be more robust towards attribute changes 
(e.g. storing projects, inserting fields into the db with external programs, 
then reopen again). 
Is there a way to resolve the indexes from within the symbol layer? Maybe it's 
something obvious that I just don't see. The symbollayer needs to know 
attribute name and index (name to say which attributes it needs, index in 
renderPoint). However, it does not know the vectorlayer to get the relation 
between name and index.

Regards,
Marco


Am Montag, 4. Juli 2011, 15.53:18 schrieb Martin Dobias:
> Hi Marco
> 
> finally I'm back :-)
> 
> On Tue, Jun 14, 2011 at 3:48 PM, Marco Hugentobler
> 
> <marco.hugentobler at sourcepole.ch> wrote:
> > - A pointer to the rendered QgsFeature* has been added to
> > QgsSymbolV2RenderContext (such that the symbollayer has the possibility
> > to check the data defined attribute values)
> > 
> > - A symbollayer has the possibility to specify which attribute fields it
> > needs for rendering (by default, QgsSymbolLayerV2::usedAttributes
> > returns an empty set).
> > 
> > - The symbollayer widgets receive a pointer to their vector layer. Normal
> > symbol layer widgets don't use it, the widgets of  data defined symbol
> > layers get the available fields through that pointer.
> 
> I have looked at the code and these changes look OK to me.
> 
> However would not it be better to add data defined fields to the
> simple marker symbol layer instead of creating a new one? The ellipse
> symbol layer seem to duplicate a lot of code, the only difference I
> see is that ellipse marker supports unequal width and height).
> Additionally it will probably make sense to add such data defined
> rendering also e.g. for simple line and simple fill.
> 
> Regarding the widget for symbol layer properties - I do not really
> like the tabbed approach (the second tab with lots of combo boxes
> looks scary :-), though I am not sure what would be the most user
> friendly approach. I am merely a fan of "Advanced" buttons that show
> this functionality (maybe in a separate dialog or by adding further
> widgets). I guess this way the regular users do not get overwhelmed
> with complexity and power users are happy.
> 
> One more technical issue: in the ellipse symbol layer you store
> indexes together with the field names. This is suboptimal and the
> field indexes should be resolved in startRender() method.
> 
> This is going to be another nice addition to the new symbology!
> 
> Regards
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee


More information about the Qgis-developer mailing list