Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wishlist: File information in overlay #59

Open
chrysn opened this issue May 5, 2020 · 2 comments
Open

wishlist: File information in overlay #59

chrysn opened this issue May 5, 2020 · 2 comments
Assignees
Labels
awaiting feedback If you are the reporter, please let me know if this fixes your issue enhancement

Comments

@chrysn
Copy link
Contributor

chrysn commented May 5, 2020

When a popover is opened in a collection, there is no indication to the user which file is being displayed.

I'd suggest that the page title is updated temporarily, and that the file name be shown above or below the image / movie.

dom111 added a commit that referenced this issue May 6, 2020
…closed. Still work to do with potentially managing the popstate handler for files too. Potentially addresses the main problem in #59.
@dom111
Copy link
Owner

dom111 commented May 11, 2020

Minor changes for this are in place, the title and the URL are updated when the preview is open. Appreciate that might not be enough but hopefully it's a decent enough start. This can be viewed, along with #60 using the a build from https://github.com/dom111/webdav-js/tree/feature/file-information-on-preview

@dom111 dom111 self-assigned this May 11, 2020
@dom111 dom111 added the awaiting feedback If you are the reporter, please let me know if this fixes your issue label May 11, 2020
@chrysn
Copy link
Contributor Author

chrysn commented May 12, 2020

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.

There's probably different schools of thought, but I don't think that the image itself should be pushed into the path -- after all, the user's "browser cursor" is not on the image itself, it is on the directory view at the position where it's viewing that image. So what I'd do about the paths is not to push the path in (as that doesn't survive a refresh), but just push a fragment identifier, say, http://server/path/#view:${FILENAME} that, when present, opens the image in preview right away.

dom111 added a commit that referenced this issue Aug 25, 2022
…hen closed. Still work to do with potentially managing the `popstate` handler for files too. Potentially addresses the main problem in #59.
dom111 added a commit that referenced this issue Aug 27, 2022
…hen closed. Still work to do with potentially managing the `popstate` handler for files too. Potentially addresses the main problem in #59.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback If you are the reporter, please let me know if this fixes your issue enhancement
Projects
None yet
Development

No branches or pull requests

2 participants