Hi all,
On Thu, Oct 24, 2024 at 10:45:49PM +0200, Xavier Del Campo Romero wrote:
I would have preferred to resume my work on multipart/form-data, but I
have been too busy with other projects and IRL. The required changes
were way too complex to shoehorn into this release, so I assume they
will have to wait for the next one :)
No worries :-)
On Thu, Oct 24, 2024 at 11:09:46PM +0200, a...@dismail.de wrote:
I don't know about the complexity, but it worked fine here!
Yeah, but I prefer to move to a new file when the format is more stable,
so you can keep your rules intact. Now I'm experimenting.
Sounds good, but in that case, maybe we should provide an example
handler script in the docs, since that could be a barrier for some
users.
I'm still using a variant of this[1] patch, but with multiple
entries, which still seems to be the easiest way of allowing external
actions.
[1] https://alex.envs.net/patches/00-ext-link-handler.patch
Yeah, maybe I could also make it like this so you can specify a program
directly:
actions="Open with external tool:/path/to/the/handler.sh default $URL"
actions="Open as audio:/path/to/the/handler.sh audio \"$URL\""
actions="Open with MPV:mpv $URL"
actions="Open with Firefox:firefox $URL"
But this won't work well when the URL has characters that are
interpreted by the shell.
It "should" be like:
actions="Open with external tool:/path/to/the/handler.sh default \"$URL\""
actions="Open as audio:/path/to/the/handler.sh audio \"$URL\""
actions="Open with MPV:mpv \"$URL\""
actions="Open with Firefox:firefox \"$URL\""
But is quite ugly. And I'll have to check if you can still inject some
command in the URL, which would be dangerous.
On Fri, Oct 25, 2024 at 09:12:21AM +1000, Kevin Koster wrote:
One action which would probably complicate things, but likely be
among the most used for me, would actually be something like "View
as text" (in Dillo). Effectively the inverse of "Save link as...".
Websites with annoying MIME settings can give links that one wants
to view as text (eg. source code files), but the server assigns a
MIME value to them that makes Dillo download them to file. This
would force Dillo to display the link as a Text file regardless.
Yes, I have also experienced this annoyance. It may be nice yes, not
sure how complex to implement.
Also the view source plugin/rendering can choke a bit
performance-wise (on the modestly-powered computers I use, at
least) with the multi-MB webpages that are common today. Just
viewing as text might be a quicker option, eg. when looking to
manually extract a URL meant to load via Javascript.
I think for very long text files this may continue to choke Dillo. Maybe
you could add a external tool that pipes it to more(1) or less(1).
Then, your handler will be invoked using the label as:
/bin/the-handler <URL> <action-label>
And you do whatever you find convenient in your handler, so you have
more context to decide the proper action based on the label. I think
this would cover most of the use cases of opening URLs with other
programs without being too convoluted.
What would the default behaviour be? Will Dillo install a default
handler with its own separate configuration file for setting up the
default 'action' behaviours? Or does the feature only appear after
each user has created their own handler?
By default, no extra options. As you add the actions they appear on the
menu. We may want to distribute an example handler for users to have a
reference.
Best,
Rodrigo.
_______________________________________________
Dillo-dev mailing list -- dillo-dev@mailman3.com
To unsubscribe send an email to dillo-dev-le...@mailman3.com
