QGIS » QGIS Application

ups...code should be:
points = [ [QgsPoint(0, 0), QgsPoint(20, 30), QgsPoint(0, 60)] ]

it looks like it's failing to update the lower and right sides.
Your script did not work here: TypeError: QgsGeometry.fromPolygon(unknown-type): argument 1 has unexpected type 'tuple'

Any way to reproduce this with some core tool ?

Or (even better), could you provide an automated test to include in the suite ?

This script works fine in 2.8.1 (redmine eat double brackets)

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from qgis.gui import *
from qgis.core import *

mCursor = QgsVertexMarker(iface.mapCanvas())
mCursor.setIconType(QgsVertexMarker.ICON_BOX)
mCursor.setIconSize(20)
mCursor.setZValue(5)

points = [ [QgsPoint(0, 0), QgsPoint(20, 30), QgsPoint(0, 60)] ]

rb = QgsRubberBand(iface.mapCanvas(), True)
rb.setToGeometry(QgsGeometry.fromPolygon(points), None)
rb.setColor(QColor(125, 125, 0))
rb.show()

def changeCursorPos(p):
    mCursor.setCenter(p)

iface.mapCanvas().xyCoordinates.connect(changeCursorPos)

iface.mapCanvas().xyCoordinates.connect(changeCursorPos)    
  File "<input>", line 4
    iface.mapCanvas().xyCoordinates.connect(changeCursorPos)
        ^
SyntaxError: invalid syntax

Got it, I need to enter an additional empty line to signal end of "changeCursorPos" function (in the python console) -- trying

Sandro - you probably need to override the boundingRect method in QgsRubberBand to return the correct rubber band bounds. It would seem the base implementation of this method is returning a rect which is too small for the rubber band. That would account for this behaviour...

I actually wonder if QgsMapCanvasItem::boundingRect is correct, in that it assumes the bounding rectangle always starts at the upper-left corner. Reading the code it looks like "mItemSize" should be correct (it's set by QgsMapCanvasItem::setRect) but boundingRect does not take mRect in consideration at all!

I've added debugging output in 2.6 and 2.8 branches to see what's going on.
First of all I noticed that even with an empty project, the QgsRubberBand::boundingRect (I added an override there, just for the sake of printing a debugging output) gets called for every pan and zoom.

Second, with the python code above, moving the rubberband around the canvas does not change the returned "boundingRect" which seems to only depend on scale. I continue to think it's always been bogus somehow...

Oops, sorry, only now I realize that the "rubberband" in the test is the triangle, not the cursor. It makes sense for it to not change when moving the cursor. Looking better now :)

Ok now I confirm that no matter where I pan (moving the rubberband triangle around the screen) the boundingRect (with 2.6) always reports the same value, which is only dependent on zoom/size-of-rubberband, and always starts with -1,-1.

For example
at scale 1:140,273,942:
src/gui/qgsrubberband.cpp: 522: (boundingRect) XXX rect is -1.0000000000000000,-1.0000000000000000 : 45.7176168480304597,135.0688211983073757

Alright one difference is that while in 2.6 the rectangle size updates with scale, in master it seems to be fixed.
updateRect is called once at rubberband creation time in both cases. Dunno what else is supposed to change mItemSize

QgsMapCanvasItem::updatePosition calls setRect again in 2.6. In master qgsrubberband overrides updatePosition to do nothing, thus the mItemSize does not change.

QgsRubberBand::updateRect calls QgsMapCanvasItem::setRect too

  // This is an hack to pass QgsMapCanvasItem::setRect what it
  // expects (encoding of position and size of the item)
  QgsPoint topLeft = m2p.toMapPoint( r.xMinimum(), r.yMinimum() ); <-
  double res = m2p.mapUnitsPerPixel();
  QgsRectangle rect( topLeft.x(), topLeft.y(), topLeft.x() + r.width()*res, topLeft.y() - r.height()*res ); <-

Maybe thats the point? Why should we subtract r.height()*res from r.yMinimum()?

updateRect call to setRect is ok, I think.

I confirm dropping the override fixes this bug. But it's to be checked what else (if anything) breaks.
I think it's better to have an automated test for this bug before fixing it. If not else if any other breackage comes out the fix for that won't re-introduce this.

Do you think you can provide an automated test for this, Anatoliy ?

Dont know how to automate it, sorry.

Theres a tests/src/gui/testqgsrubberband.cpp file you could start from

Ok, Im look at it

A fix is available here: https://github.com/qgis/QGIS/pull/1968
Adding your test there would be useful, before merging.

Tested master on debian, it seems ok, refreshing works fine.