Hi Martin, Just a quick answer to thank you warmly for these improvements. I am working on OpenStreetMap data to print maps, and I think these changes will help me a lot. I have to compile master branch to test it, but will try to do it quickly, and then I would be able to report.
About your last questions, here are my first answers : - cloning of rules Very good idea, It will help a lot - filtering of rules in GUI - by label / filter expression / scale not a priority for me, since the tree should improve user experience. And you would have to dynamically change the tree, which could lead to weird behaviours ? Such as showing only some child nodes - "else" rule - will be used only if no other sibling rule matches no comment here, since I do not use it often - checkable rules? This would be very helpfull to dynamically test the rules - better item delegates for inline editing - e.g. filter editor with "..." button to open query builder no comment either Another thing I find hard to play with in the current 1.7 versions is the need to click again and again to change rule priority : click the rule, then click the array (increase or decrease), then reclick the rule (which location has changed), then reclick "increase", etc. I think. This is why I think the drag and drop (and multi-selection) you implemented would be very handy ! Thanks again Michael 2012/1/24 Martin Dobias <[email protected]> > Hi all > > I have just merged improved rule-based renderer to master branch. > There are various changes in both backend and GUI: > > * Rules now form a hierarchical structure: any rule can contain > further "child" rules. When rendering, child rules are applied only > when their parent rule matches. This allows users to build a logical > trees of rules instead of keeping all rules in a flat list with > complex filters. > > * The options "use only first rule" and "use symbol levels" have been > removed: now all the matching rules and applied and at the same time > the rendering order is given by the symbol levels. > > * GUI: rules are shown as a tree. They can be organized easily with > drag and drop (multiple selection is supported, too). Let me emphasize > again that the tree of rules does not say anything about the rendering > order (because in SLD and Mapnik the order of rules matters). The > rendering order can be set by the button in bottom-right corner of the > renderer widget - it triggers the same dialog as used for setting > symbol levels. > > * GUI: inline editing of labels, filters and scale range is now > possible - use F2 -or- click again a selected item to enter inline > editing. > > * Rules may not contain a symbol: usually parent rules are not > assigned a symbol because their child rules take care of rendering. > > * symbol levels dialog for other renderers is now accessible from a > menu from their "advanced" button - to avoid some clutter, > additionally renderers indicate whether they support symbol levels or > not. > > Originally I wanted to design the rule-based renderer to follow SLD / > Mapnik logic - the order of rules (and group of rules) determines the > rendering order. However this is not very user friendly: the user has > to prepare the rules in a way that is convenient to a software, not > the user. For example, when drawing a map of roads with nicely > rendered road outlines and varying Z-levels (bridges / tunnels), the > user has to split the road symbols into multiple rules and move them > away from each other - further editing of rules and symbols becomes > complex. In our approach the user can keep the rules in a hierarchy > that is most convenient and then define the rendering order > independently. So there is not a 1:1 relation between QGIS rule-based > rendering and SLD (or Mapnik) rules, however the import/export > capabilities can be implemented without problems. > > Please test, I would like to hear your comments, suggestions and bug > reports. I am especially interested to hear any notes related to > usability - I have some doubts regarding GUI, e.g.: > - expand all rules when GUI is opened? > - delete parent rule's symbol when refining it? or completely forbid > rules to contain a symbol if they have children? > > There are still some smaller things that might be added in future: > - cloning of rules > - filtering of rules in GUI - by label / filter expression / scale > - "else" rule - will be used only if no other sibling rule matches > - checkable rules? > - better item delegates for inline editing - e.g. filter editor with > "..." button to open query builder > > Finally, I would like to thank Ville de Morges, Switzerland for > sponsoring this work. > > Regards > Martin > _______________________________________________ > 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
