The animation effects list in the animation sidebar is followed by a row with four buttons: Add, remove, move up, move down. I suggest that buttons be added for "move to top" and "move to bottom". In terms of real-estate, it seems there is enough horizontal space for them. The icons would be pretty easy to make to - up and down arrows like for "Move Up" and "Move Down", with bounding lines above and below respectively.
No, there is no requirement. The Animation listing is the sequence in which the elements on the slide will be presented. It does not affect the placement on the slide in any way--only the order in which each element is exposed--so not a layout tool. Given that adjustments to a single slide's animations are done incrementally--moving up by one or down by one in the sequence is common. Moving an element to be the First or the Last element exposed would be a very low percentage requirement and not worth the work it would require to establish a new UNO control to implement or the UI tweaks needed to fit it in the Effects Content panel. Leave it alone. IMHO => WF
(In reply to V Stuart Foote from comment #1) > No, there is no requirement. I didn't suggest there's a requirement - it would be a convenience feature. Trade-off is a little bit more clutter vs avoiding the need to click the up or down buttons repeatedly. > The Animation listing is the sequence in which > the elements on the slide will be presented. It does not affect the > placement on the slide in any way I didn't suggest that it does. Perhaps my earlier comments were not phrased well enough? > Given that adjustments to a single slide's animations are done > incrementally--moving up by one or down by one in the sequence is common. At first, you add animations incrementally, but then when you insert a new item into a slide with animations and want to time its effects - it's not just one-up or one-down. Also, if you created your animations sequence by selecting multiple elements and adding an effect for each of them, this is useful for "max-sorting" the effect timings. I filed this bug because I find myself using this functionality relatively frequently. But of course that may not be the case for everyone.
I personally like drag and drop as alternative to the use of buttons for sorting animations.. unsure if this bug report being the proper place to mention this..
(In reply to Telesto from comment #3) > I personally like drag and drop as alternative to the use of buttons for > sorting animations.. unsure if this bug report being the proper place to > mention this.. If your effect list is very long, drag-and-drop is quite inconvenient for moving to the end or the start of the list. Also, bug 151343 may interest you.
If the requirement "Move To Top/Bottom" is valid I'd prefer to have it in the context menu along with Move Up/Down. Until now the context menu does not provide these options. As for the space consider languages that need more space to say "Add" (in German it would be "Hinzufügen"). And those button walls are not nice anyway.
(In reply to Heiko Tietze from comment #5) > If the requirement "Move To Top/Bottom" is valid I'd prefer to have it in > the context menu along with Move Up/Down. Hmmm. I didn't even think about that. The effect context menu doesn't have Move Up/Down; and it's not super-intuitive to right-click something in order to move it. But - if I can get this functionality via the context menu, I suppose it's good enough. It would be a different bug though.
(In reply to Eyal Rozenberg from comment #6) > It would be a different bug though. Clearly not. You should describe a use case and a workflow but not ask for a specific solution (unless you implement it yourself). Suggestions are welcome, of course.
We discussed the topic in the design meeting. Moving items in the list is done via drag 'n drop. That works well the usual number of items. More interactions including the considered context menu item(s) would be unexpected and hard to find. Last but not least the list can be enlarged - currently via splitter but maybe per expander following the request in bug 151377. So the recommendation is to not add the "Move to Top/Bottom" functions.