wishlist: Navigation in overlay
chrysn opened this issue · comments
In collections heavy with overlay-viewable files, it would be convenient for some use cases to navigate the items in the collection from inside the overlay view, maybe using left/right or up/down arrow and/or clickable arrows next to the file name if #59 is implemented. (Generally, this depends a bit on #59, as while originally the user should know what they opened, no information is available to them any more when going from one item to the next).
This would be very useful in collections containing lots of images, as it allows effortless walks through an album. Some care might be necessary around interactive content (movies, PDFs), as their usage model might mean that they should receive some arrow keys (whatever is default in the browser's built-in media player; probably left-right for seeking) that might need priority over switch-to-next-item arrow key usage.
One reason not to do this would be to keep webdav-js from becoming a gallery viewer, which (while being useful) is not the usual purpose of a file manager (although some functionality does overlap).
This is definitely something I've considered, especially when I first started working on the keyboard navigation (it's alluded to in TODO.md) so I'm definitely in favour of this.
I've added a change for this in https://github.com/dom111/webdav-js/tree/feature/file-information-on-preview (along with the changes for #59). It's still very much not a gallery and just a way to quickly scan through the preview content. If you interact with the content in the overlay, the list itself will lose focus and you'll need to interact via the mouse. This skips content that doesn't have a preview supporting type and updates the push-state. This means that if you refresh the page once the history has changed, that you'd need to manually navigate back to a directory, I've not really looked into this, but I imagine that's potentially tricky to work around without server-side rewrite rules that involve setting a header or something to differentiate requests that hit for the raw data and requests that need to be routed through the script - hopefully that's not too much of a blocker.
Awesome, the navigation works great for my use case!
I'm a bit conflicted about this requiring keyboard interaction. On one hand, this is excluding the feature from keyboardless use cases -- on the other hand, the predominant keyboardless platforms all have touch displays, which could use gestures instead, and thus the clean look of "nothing on the screen but the content and the directory behind the shade" could be preserved.
(And also, thanks again for maintaining this. I know I'd go mad about all the web user interface decisions that go with it.)
The keyboard navigation is merged in #109, but I'll add in some UI for this too. Keeping open for now :) Thanks!