You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
3 commit comments
m-kuhn commentedon Mar 22, 2017
Isn't the problem rather that the panel relies on the layer order change signal to be activated?
nyalldawson commentedon Mar 22, 2017
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 commentedon Mar 22, 2017
I'm rewriting this code anyway right now.
hasCustomLayerOrder
is still only in gui.