[Qgis-developer] Re: Working on Symbology Improvement for the GSOC

Andreas Neumann a.neumann at carto.net
Sat Mar 31 16:58:30 EDT 2012


I think improving the symbology system would be very rewarding and
beneficial for many - but be sure to discuss the technical issues with
Martin and Marco. They probably know the system best.

Work on the SVG symbol repository and better management of the SVG
symbols (categories, metadata (also multilingual), ability to pick only
groups that interest the user (e.g. only geology, geomorphology), etc.)
would be great and benefitial to many. By default there should be fewer
SVG symbols but the repository should allow to easily add additional ones.

Other improvements I would like to see:

* ability to separately define opacity for stroke and for fill (e.g.
fill is transparent and stroke is not)
* ability to define separate units for each symbol component: e.g. the
size of the symbol (e.g. elliptical symbol) should be in map units, but
the stroke thickness in mm

Regarding the many nested dialogues:

I think there is a technical reason why there are so many nested
dialogues - it is because of the reuse of the dialogues in different
situations. As an example, a dialogue setting SVG symbols can be reused
for point symbols, but also for marker lines - or a color chooser can be
used in many situations. Also fill and stroke properties are reused in
different renderers.

I agree that from a usability point of the view the many nested
dialogues are not so optimal, but I remember hearing from Martin Dobias
that this way the whole system was easier to maintain and dialogues more


On 03/31/2012 10:08 PM, aruntheguy at gmail.com wrote:
> Hello,
> After working with the Symbology as a user for the past couple of days and
> trying to accomplish various things, here is my idea of simplifying things:
> Decouple Style management and Style application (renderer) logic at the GUI
> level itself.
> First let us start where it all begins, simplification of the GUI and
> reducing the number of modal dialogs that keep opening as we go customizing
> the symbol layers. This presumably is the best approach as it gives the
> possibility to provide almost infinite customization options to the user.
> But, customization of layers is not going to be my priority when I am
> applying styles, or at least thats not what I intend to do. I just want to
> see the styles and pick the most suitable.
> If I want to be creative and design new symbols/styles, which I may now use
> or may not now use, why should I be doing it in a layers properties dialog.
> I would rather have a designer where I can design my styles of the liking.
> I ma even get to preview a composition of all the symbol styles that I have
> created.
> So the idea is to create such a decoupled designer, which is something like
> a "Style Manager ++ (decoupled)". I am writing the possible solution and a
> couple of ideas as a proposal which might contain some over sighted goals.
> Kindly go through, evaluate and comment.
> Proposal:
> + Remove Symbol Creating/Editing capabilities from the "Style" tab of Layer
> Properties and retain only application(renderer) customizations like, size,
> color, angle etc., This will remove the iterative dialog popup situation
> and also keep the clutter in the UI to minimum.
> + Create a new symbol designer, that can be summoned up from Menu rather
> than from the properties
> + The designer to perform following functions
>     - Create new symbols/styles
>     - Grouping and management of styles through a tree structure
>     - Create and manage virtual groups (or themes) that would pull symbols
> from various groups and a combination of renders to create a overall
> cartographic stylesheet (almost same as present save/load style).
>     - Ability to save a retrieve such stylesheets (duplicates the present
> save/load style)
> Apart from the above solution, the GSOC proposal to include,
> - Creating tree structure for managing the SVG symbols
> - Creating a non-modal widget type editor to change symbols on the fly or
> adding that capability to the Layers legend.
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

More information about the Qgis-developer mailing list