[Qgis-developer] Ellipse renderer

Tim Sutton lists at linfiniti.com
Wed Jul 6 17:54:40 EDT 2011


Hi

I also took some time to test your branch. It works very nicely - the
only option I miss is the ability to have a transparent fill :-)


On Tue, Jul 5, 2011 at 10:19 AM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> wrote:
> 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?

Marco we had quite a long discussion about the symbol editor
functionality in QGIS in Lisbon. The short version is that we would
like to make some generic widgets for representing symbols (and other
common ui patterns like managed lists and so on). For now I think your
tabs are ok (and better than having another popup dialog).

Regards

Tim

>
>> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================


More information about the Qgis-developer mailing list