[Qgis-developer] Field calculator does attribute changes silently

[Matthias Kuhn]

Hi,

Currently,when the field calculator does changes to attributes 
(modification, not adding a new column) it blocks signals of the vector 
layer while doing this. This leads e.g. to bug #9268 [1], that the 
attribute table is not updating properly. The fix would be very easy 
(i.e. remove the blockSignals() call) but I wanted to ask first, if 
there is a reason not to do this.

The main reason why I am afraid is, that apart from the blockSignals() 
call, there is also the paramter emitSignal specified as false in the 
call to vectorlayer->changeAttributeValue(). This parameter is currently 
not working, so I suppose that the blockSignals() call was introduced as 
a workaround.

However, there was a good reason, to block the signals explained in 
issue #7071 [2], fixed by Jürgen, that at the time when we only 
supported one iterator per layer, emitting this signal would break the 
update process and produce only partially updated results. This is 
fortunately no longer the case, so this reason can be considered obsolete.

Another reason which I could imagine (but I have no proof of) is that 
for big layers, emitting the signal for each feature can possibly take a 
long time. However, if this is actually the case we should rather think 
about batching the signal or fix unperformant consumer slots of this signal.

Be aware, that at the current state, there is no possibility, neither 
for plugins nor in QGIS core, to get reliable push-notifications when an 
attribute changes.

So my proposal is:

   * Remove the blockSignal calls and let attribute changes always be 
promoted
   * If there are problems introduced, lets fix the problems instead of 
working around them at the cost of unreliability
   * Don't fix the emitSignal parameter for 
QgsVectorLayer::changeAttribute and deprecate it for future removal.

If there is no objection, I would vote to make this changes before the 
QGIS 2.2 freeze

Best
Matthias

[1] http://hub.qgis.org/issues/9268
[2] http://hub.qgis.org/issues/7071