From a5d3b710eb46e58708b8dbb51f5231ba534561fd Mon Sep 17 00:00:00 2001 From: Florrie Date: Wed, 18 Sep 2019 17:56:11 -0300 Subject: Don't reload the listing if it's unnecessary ...in reveal(). This fixes the bug where the revealed track would always be positioned at the bottom of the screen, which happened because reloading the listing reset the scroll index back to the top. --- todo.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'todo.txt') diff --git a/todo.txt b/todo.txt index 161d7f9..3470204 100644 --- a/todo.txt +++ b/todo.txt @@ -384,6 +384,7 @@ TODO: Revealing a track shouldn't forcibly position it at the bottom of the if the item is already visible, and if it's above the current scroll area, make it appear at the top of the listing view instead of the bottom. + (Done!) TODO: Text file support. Yes. Heck yes. Heck hecking yes. Read text files contained in your music library folders. If there is a @@ -396,3 +397,9 @@ TODO: Make 'after selected song' the default in the context menu, too. I miight general, and if you prefer 'after current song', that option isn't hard to discover and select. (Done!) + +TODO: Investigate why reveal() has distinct support for grouplikes as well as + tracks - you can't append actual groups to the queue (only their + flattened children) after all. But if you could -- I think reveal should + work the same for groups as it does for tracks, i.e. opening the parent + and then selecting the item. -- cgit 1.3.0-6-gf8a5