[Qgis-developer] Latest features ready to commit - which branch?

[humarco]

Hi Brendan,

> Why?  My main hassle was in the situation where I'm modelling a street
> intersection and I want to move one of the "streets" away from that
> intersection, previous versions of QGIS would not allow me to choose
> which street.  Fine, it would snap to the appropriate vertex
> (representing the street intersection) but the street (linestring) that
> that vertex belonged to was arbitrary.

Right, this seems very usefull to me. Also, in the case of adjacent polygons 
it would be usefull to move the vertex of the polygon where the cursor is in.

> I considered it a usability bug, so acted appropriately. 

Ok, but a missing feature usually is a usability bug. Don't get me wrong, i 
appreciate the contributions very much. I just think that it is difficult for 
the release with bigger changes (e.g. snapping concept). Perhaps it would be 
good to have a release branch such that changes like this could be done in 
head (which leads us again to the 'subversion branching policy - debate' 
discussion...).

> I disagree that rubber banding should be handled in QgsGeometry.  I
> believe it is a property of the QgsMapToolVertexEdit (seeing as it is
> eye-candy to the Vertex Editing process), and really should have been
> coded there.
>
> I suggest the QgsGeometry closest segments tests should be more
> generalised, without the overhead of calculating the fore- and
> aft-vertex each time.

Yes, it would be much nicer to have the rubber banding just in 
QgsMapToolVertexEdit. I just don't see how to do this. I think that the 
information about the fore-and aft-vertex needs to come from QgsGeometry. 
BTW, calculating the fore- and aft-vertex is not so much overhead in the 
context of closest point/ closest segment calculation.

 
> Hmmm.  The problem it if you set the tolerance to 0, you can't actually
> select a vertex to edit or a segment to add a vertex to any more!

> Therefore there should be two settings - one to determine how far away
> to search to find which segment or vertex to edit (which we already
> have) and a second (new) setting to determine if we snap to existing
> verticies when editing the target vertex.

> I find it's a huge usability issue to not have the second setting
> customisable.  Things keep snapping to nearby verticies, and (as a side
> issue) each snap search causes the data provider to do a search back to
> the source data (this gets expensive when it comes to say a PostGIS
> provider, and certainly is not enterprise-friendly).

Ok, i agree that there is definitely a need for two settings. Again, i would 
vote for doing so not in the release version. 

> You'll notice I have a bit of a thing about usability (i.e. things
> should "just work" with few surprises for the user), and consider
> usability issues as bugs - I'm not sure if that developer body shares my
> enthusiasm and therefore again invite comment.

The question is what is for 0.8 and what is for >0.8. Maybe i'm to 
closed-minded with respect to 0.8 release?
It would be good if we could have some comments from other developers.


Greetings,
Marco