Skip to content

Commit 746d288

Browse files
committedMar 22, 2017
Don't emit layerOrderChanged when removing layers
Otherwise it automatically enables the layer order panel
1 parent b8fd1fd commit 746d288

File tree

2 files changed

+1
-5
lines changed

2 files changed

+1
-5
lines changed
 

‎src/core/qgsproject.cpp

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2171,7 +2171,6 @@ void QgsProject::removeMapLayers( const QList<QgsMapLayer *> &layers )
21712171
QStringList layerIds;
21722172
QList<QgsMapLayer *> layerList;
21732173

2174-
bool layerOrderHasChanged = false;
21752174
QList< QgsMapLayer * > currentOrder = layerOrder();
21762175
Q_FOREACH ( QgsMapLayer *layer, layers )
21772176
{
@@ -2180,7 +2179,6 @@ void QgsProject::removeMapLayers( const QList<QgsMapLayer *> &layers )
21802179
{
21812180
layerIds << layer->id();
21822181
layerList << layer;
2183-
layerOrderHasChanged = layerOrderHasChanged || currentOrder.contains( layer );
21842182
}
21852183
}
21862184

@@ -2204,8 +2202,6 @@ void QgsProject::removeMapLayers( const QList<QgsMapLayer *> &layers )
22042202
}
22052203

22062204
emit layersRemoved( layerIds );
2207-
if ( layerOrderHasChanged )
2208-
emit layerOrderChanged();
22092205
}
22102206

22112207
void QgsProject::removeMapLayer( const QString &layerId )

‎tests/src/python/test_qgsproject.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -210,7 +210,7 @@ def testLayerOrder(self):
210210
self.assertEqual(len(layer_order_changed_spy), 3)
211211
prj.removeMapLayer(layer)
212212
self.assertEqual(prj.layerOrder(), [layer2, layer3])
213-
self.assertEqual(len(layer_order_changed_spy), 4)
213+
self.assertEqual(len(layer_order_changed_spy), 3) # should be no signal
214214

215215
# save and restore
216216
file_name = os.path.join(str(QDir.tempPath()), 'proj.qgs')

3 commit comments

Comments
 (3)

m-kuhn commented on Mar 22, 2017

@m-kuhn
Member

Isn't the problem rather that the panel relies on the layer order change signal to be activated?

nyalldawson commented on Mar 22, 2017

@nyalldawson
CollaboratorAuthor

I was 50/50 on emitting that signal when a layer was removed in the first place. I'm not sure that removing a layer really consistutes reordering or not. But when I discovered it caused this bug it pushed me to just remove the signal.

If we did emit it for layer removal I can't see a clean way to detect that the signal was caused by layer removal and not by manual reordering. On the flipside if someone wants both conditions (manual layer reordering AND reordering via removal) they could just connect to both signals. Maybe I just need to make this clear in the docs.

m-kuhn commented on Mar 22, 2017

@m-kuhn
Member

I'm rewriting this code anyway right now. hasCustomLayerOrder is still only in gui.

Please sign in to comment.