Hi, 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 reusable. Thanks, Andreas On 03/31/2012 10:08 PM, [email protected] 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
