Skip to content

Commit

Permalink
Don't emit layerOrderChanged when removing layers
Browse files Browse the repository at this point in the history
Otherwise it automatically enables the layer order panel
  • Loading branch information
nyalldawson committed Mar 22, 2017
1 parent b8fd1fd commit 746d288
Show file tree
Hide file tree
Showing 2 changed files with 1 addition and 5 deletions.
4 changes: 0 additions & 4 deletions src/core/qgsproject.cpp
Expand Up @@ -2171,7 +2171,6 @@ void QgsProject::removeMapLayers( const QList<QgsMapLayer *> &layers )
QStringList layerIds;
QList<QgsMapLayer *> layerList;

bool layerOrderHasChanged = false;
QList< QgsMapLayer * > currentOrder = layerOrder();
Q_FOREACH ( QgsMapLayer *layer, layers )
{
Expand All @@ -2180,7 +2179,6 @@ void QgsProject::removeMapLayers( const QList<QgsMapLayer *> &layers )
{
layerIds << layer->id();
layerList << layer;
layerOrderHasChanged = layerOrderHasChanged || currentOrder.contains( layer );
}
}

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

emit layersRemoved( layerIds );
if ( layerOrderHasChanged )
emit layerOrderChanged();
}

void QgsProject::removeMapLayer( const QString &layerId )
Expand Down
2 changes: 1 addition & 1 deletion tests/src/python/test_qgsproject.py
Expand Up @@ -210,7 +210,7 @@ def testLayerOrder(self):
self.assertEqual(len(layer_order_changed_spy), 3)
prj.removeMapLayer(layer)
self.assertEqual(prj.layerOrder(), [layer2, layer3])
self.assertEqual(len(layer_order_changed_spy), 4)
self.assertEqual(len(layer_order_changed_spy), 3) # should be no signal

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

3 comments on commit 746d288

@m-kuhn
Copy link
Member

@m-kuhn m-kuhn commented on 746d288 Mar 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@nyalldawson
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

@m-kuhn m-kuhn commented on 746d288 Mar 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Please sign in to comment.