Hi Martin,<br><br>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.<br>I have to compile master branch to test it, but will try to do it quickly, and then I would be able to report.<br>
<br>About your last questions, here are my first answers :<br>- cloning of rules<br><br>Very good idea, It will help a lot<br><br>
- filtering of rules in GUI - by label / filter expression / scale<br><br>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<br>
<br>
- "else" rule - will be used only if no other sibling rule matches<br><br>no comment here, since I do not use it often<br><br>
- checkable rules?<br><br>This would be very helpfull to dynamically test the rules<br><br>
- better item delegates for inline editing - e.g. filter editor with<br>
"..." button to open query builder<br><br>no comment either<br><br>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.<br>
This is why I think the drag and drop (and multi-selection) you implemented would be very handy !<br><br>Thanks again<br><br>Michael<br><br><br><div class="gmail_quote">2012/1/24 Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all<br>
<br>
I have just merged improved rule-based renderer to master branch.<br>
There are various changes in both backend and GUI:<br>
<br>
* Rules now form a hierarchical structure: any rule can contain<br>
further "child" rules. When rendering, child rules are applied only<br>
when their parent rule matches. This allows users to build a logical<br>
trees of rules instead of keeping all rules in a flat list with<br>
complex filters.<br>
<br>
* The options "use only first rule" and "use symbol levels" have been<br>
removed: now all the matching rules and applied and at the same time<br>
the rendering order is given by the symbol levels.<br>
<br>
* GUI: rules are shown as a tree. They can be organized easily with<br>
drag and drop (multiple selection is supported, too). Let me emphasize<br>
again that the tree of rules does not say anything about the rendering<br>
order (because in SLD and Mapnik the order of rules matters). The<br>
rendering order can be set by the button in bottom-right corner of the<br>
renderer widget - it triggers the same dialog as used for setting<br>
symbol levels.<br>
<br>
* GUI: inline editing of labels, filters and scale range is now<br>
possible - use F2 -or- click again a selected item to enter inline<br>
editing.<br>
<br>
* Rules may not contain a symbol: usually parent rules are not<br>
assigned a symbol because their child rules take care of rendering.<br>
<br>
* symbol levels dialog for other renderers is now accessible from a<br>
menu from their "advanced" button - to avoid some clutter,<br>
additionally renderers indicate whether they support symbol levels or<br>
not.<br>
<br>
Originally I wanted to design the rule-based renderer to follow SLD /<br>
Mapnik logic - the order of rules (and group of rules) determines the<br>
rendering order. However this is not very user friendly: the user has<br>
to prepare the rules in a way that is convenient to a software, not<br>
the user. For example, when drawing a map of roads with nicely<br>
rendered road outlines and varying Z-levels (bridges / tunnels), the<br>
user has to split the road symbols into multiple rules and move them<br>
away from each other - further editing of rules and symbols becomes<br>
complex. In our approach the user can keep the rules in a hierarchy<br>
that is most convenient and then define the rendering order<br>
independently. So there is not a 1:1 relation between QGIS rule-based<br>
rendering and SLD (or Mapnik) rules, however the import/export<br>
capabilities can be implemented without problems.<br>
<br>
Please test, I would like to hear your comments, suggestions and bug<br>
reports. I am especially interested to hear any notes related to<br>
usability - I have some doubts regarding GUI, e.g.:<br>
- expand all rules when GUI is opened?<br>
- delete parent rule's symbol when refining it? or completely forbid<br>
rules to contain a symbol if they have children?<br>
<br>
There are still some smaller things that might be added in future:<br>
- cloning of rules<br>
- filtering of rules in GUI - by label / filter expression / scale<br>
- "else" rule - will be used only if no other sibling rule matches<br>
- checkable rules?<br>
- better item delegates for inline editing - e.g. filter editor with<br>
"..." button to open query builder<br>
<br>
Finally, I would like to thank Ville de Morges, Switzerland for<br>
sponsoring this work.<br>
<br>
Regards<br>
Martin<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br>