SUMMARY When a single frame is selected on the AnimationTimeline frames view, normally selecting or moving a layer in the LayerBox, the FRAME selection moves with the LAYER selection to focus on the active/visible layer. However, when duplicating or pasting a layer, the LAYER selection is changed to focus on the NEW layer, but the FRAME selection is still pointing to a frame on the OLD layer. This is a minor issue, but has the effect of somewhat confusing behavior when adding or removing frames in this scenario. STEPS TO REPRODUCE 1. In a file with a layer, duplicate or copy/paste a second animated layer into the document. 2. Hit the "add keyframe" button on the Animation Timeline Docker's toolbar. OBSERVED RESULT Notice that the frame that you've added has appeared on the previously selected layer. (The one that you copied from, not the one that you just pasted.) EXPECTED RESULT Having been confused about this myself, I think it'd probably be less confusing to have the single fame selection move to the newly pasted layer, so that hitting the "Add Frame" button adds a frame on the new one without requiring an extra click. (Though this is probably up for debate.) SOFTWARE/OS VERSIONS Fedora 40 Linux, gnome x11, git master as of writing this, built with dmitry's docker.
Hi, Emmet! I cannot reproduce the issue here locally (at least on Windows). I have two different ways how it behaves and it looks consistent with the rest of list-box behavior: Case 1: frame selection is on the currently active layer, and active layer is duplicated 1) Select a layer, select a frame on this layer on the timeline 2) Duplicate this very layer 3) The new layer appears on the timeline and a frame is selected on it (as expected) Case 2: frame selection is on any non-active layer, and active layer is duplicated 1) Select a layer, select a frame on any different layer 2) Duplicate active layer 3) The new layer appears on the timeline, but the frame is still selected on the old layer (since it is not on the active layer) Can you confirm that the both cases work as I describe that? Or it works differently on Linux? This behavior is the standard behavior of Qt's list controls. I'm not really sure we should change that (though we could discuss that with a wider community).
Add needsinfo
Hey Dmitry, I think you're right because I can't reproduce this anymore either, which either means I was confused somehow (most likely... probably...) or there is some rare condition involved. The other day when I was testing for a different bug I felt like I ran into some unexpected behavior, but everything seems to be working as expected now. *shrug* Let's go ahead and close this for now, and I'll open it again in the future if I happen to run into something unexpected again. Sorry for the false alarm. lol :)