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

Mediatype handlers #121

Closed
2 tasks done
makew0rld opened this issue Nov 17, 2020 · 5 comments
Closed
2 tasks done

Mediatype handlers #121

makew0rld opened this issue Nov 17, 2020 · 5 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request roadmap A user-facing feature on the roadmap. UI Deals with the visual user interface
Milestone

Comments

@makew0rld
Copy link
Owner

makew0rld commented Nov 17, 2020

Currently there is support for using different applications per URL scheme, see the [url-handlers] section of the config. Another section should be made to support defining a list of mediatypes that the specified application would handle. Currently the only option for binary files (images, audio, etc) is to download it or open it in the portal. Adding this would allow more seamless browsing.

The download modal buttons should change to "Open" and "Download". The "Open in Portal" button has always been a bit of a hack.

Example config, using an array of tables

# Explanation here...

[[mediatype-handlers]]
cmd = ["feh"]
types = ["image/jpeg"]


[[mediatype-handlers]]
cmd = ["vlc", "--flag"]
types = ["audio", "video"] # Can capture an entire type by just not specifying the subtype

[[mediatype-handlers]]
cmd = ["some-command"]
types = [
	"application/pdf",
	"*", # Override the default catch-all handler
]
  • Put this on the roadmap (also talk about scheme handlers in the same bullet maybe)
  • Add way to specify piping/streaming content versus downloading the entire thing first
@makew0rld makew0rld added enhancement New feature or request roadmap A user-facing feature on the roadmap. labels Nov 17, 2020
@makew0rld makew0rld added this to the v1.8.0 milestone Nov 18, 2020
@makew0rld makew0rld changed the title Add mimetype handler support Add mediatype handler support Nov 18, 2020
@makew0rld makew0rld self-assigned this Nov 18, 2020
@makew0rld makew0rld mentioned this issue Nov 20, 2020
16 tasks
@makew0rld makew0rld changed the title Add mediatype handler support Mediatype handlers Nov 23, 2020
@makew0rld
Copy link
Owner Author

makew0rld commented Nov 23, 2020

On Unix systems default to using xdg-open for files if no other handler is found. Display an error to the user if there are no handlers and xdg-open does not exist.

For Windows and macOS do the same, but use the commands used for each OS in webbrowser/ instead.

For other OSes just raise the error if there's no handlers.

The user can override this default catch-all handler with the types = ["*"] line as described in the original comment.

@makew0rld makew0rld added the UI Deals with the visual user interface label Nov 23, 2020
@makew0rld
Copy link
Owner Author

The download modal would still display until the file is entirely downloaded and the application is launched -- except for piped/streamed mediatypes.

@makew0rld
Copy link
Owner Author

makew0rld commented Dec 8, 2020

The [url-handlers] section of the config has this in it:

# This is a special key that defines the handler for all URL schemes for which
# no handler is defined.
other = 'off'

Maybe when this feature is added, then that key can be removed and ignored. And instead of displaying an error when the user tries to open an unknown scheme, Amfora will fallback to the default opening command for the user's OS, as mentioned above.

If the above happens, there should be a modal that shows up if the user has not explicitly specified a handler, saying "Do you want to try to open a <scheme> URL in your default application?". And of course, an error modal should appear if anything goes wrong, whether the handler was explicit or not.

Edit: I'm going to leave this unchanged for now.

@makew0rld
Copy link
Owner Author

makew0rld commented Dec 14, 2020

This feature has been added in #134 thanks to @sudobash1, in mediatype-handlers branch. Once the streaming part is added on that branch and v1.7.0 is released, then that branch can be merged to master and this issue can be closed.

The CHANGELOG.md file will need to be updated before merging.

@makew0rld makew0rld added the documentation Improvements or additions to documentation label Dec 15, 2020
@makew0rld
Copy link
Owner Author

The mediatype-handlers branch has been merged into master. This feature is now complete and appears to work well, including streaming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request roadmap A user-facing feature on the roadmap. UI Deals with the visual user interface
Projects
None yet
Development

No branches or pull requests

1 participant