<div dir="ltr"><div class="gmail_extra">Hi,<br><br></div><div class="gmail_extra">I'll try to address all concerns in a single mail (what a challenge!)<br><br></div><div class="gmail_extra">First I would like to say that everybody has access to a different set of "average/typical users" and I cannot claim any statistical relevance to the group of users I've been in touch with.<br><br></div><div class="gmail_extra">But the user's feedback that I've got so far is that the Value-Relation widget (V-RW) is easier to use and to understand: its scope it's limited to how data are entered and viewed and does not depend on a model-project-level constraint (the Relation-Reference R-RW does).<br><br></div><div class="gmail_extra">Those (statistically insignificant) users were quite emotional and ready to fight to keep V-RW live and healthy :)<br><br></div><div class="gmail_extra">Code-wise I totally agree that the two widgets could share more logic and options, but given the intricacies of the attr-table and widgets-forms logic this is not trivial at all, and it's not in scope with this QEP 116 enhancement.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Coming to the new functionalities introduced by QEP 116, the way they will be implemented will make them easily reusable in the context of the R-RW:<br><br></div><div class="gmail_extra">- form scope context with geometry and attributes<br></div><div class="gmail_extra">- form scope available in both the form and the attribute table<br><br></div><div class="gmail_extra">Of course existing bugs and glitches in the V-RW workflow will be fixed on the way when they not imply rewriting the whole QGIS core ;)<br><br><div class="gmail_extra"><br></div><div class="gmail_extra">What could be considered here, is to add a second goal to the campaign for making the new features available to the R-RW too, what do you think?<br></div><div class="gmail_extra"><div class="gmail_extra"><br></div></div>But even without this additional goal, I still think 
that this QEP (which is not a complete refactoring of the whole 
form/attr-table *-R widgets) is a step forward and in the direction
 of a future better integration of the existing *-R-widgets.<br><div class="gmail_extra"><br></div><br><div class="gmail_extra">That's why I'm joining Nyall's call to contribute and make this a reality.<br></div><br><br></div><div class="gmail_extra">Also note that some of Règis requirements, like a geographical dynamic filter will be possible with an expression like:<br><br>... AND contains(buffer( $current_form_geometry, 10), $geometry)<br><br></div><div class="gmail_extra">note that this expression is the one used to filter the values in the related layer, and it will have access to the geometry of the feature currently being edited/added in the form (or table row) as well as to the form (row) values, so:<br><br></div><div class="gmail_extra">- $current_form_geometry = the geometry of the feature currently being edited in the form<br></div><div class="gmail_extra">- $geometry = the geometry of the related layer that is being filtered to get the list of values for the combo/search/etc...<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Also note that the V-RW is already used in the identify results panel (and form of course).<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers<br><br>-- <br><div class="m_-8678018939614742598gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></div>