Hi, I'm planning to close the feature window shortly, so I will need to think what else to include for 3.2.0 before it is closed. One of the features I would like to include is the ability to open a link with an external handler. We have a proof of concept that uses the rule file, but I think it is too complex for now: https://github.com/dillo-browser/dillo/pull/199 I'm thinking it may be better to add an easier variant first, that we can extend later. I'm considering adding these to dillorc: actions="default Open with external tool" actions="firefox Open with Firefox" actions="mpv Open with MPV" actions="mpv-audio Open with MPV (audio)" handler="/bin/the-handler" Where you can define multiple "actions" but only one "handler". The actions have a label at the beginning (first word) and a human readable text that will be presented in the menu. 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. Best, Rodrigo.
Hi Rodrigo, 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 :) Best regards, Xavi On 24/10/24 20:49, Rodrigo Arias wrote:
Hi,
I'm planning to close the feature window shortly, so I will need to think what else to include for 3.2.0 before it is closed.
One of the features I would like to include is the ability to open a link with an external handler. We have a proof of concept that uses the rule file, but I think it is too complex for now:
https://github.com/dillo-browser/dillo/pull/199
I'm thinking it may be better to add an easier variant first, that we can extend later. I'm considering adding these to dillorc:
actions="default Open with external tool" actions="firefox Open with Firefox" actions="mpv Open with MPV" actions="mpv-audio Open with MPV (audio)" handler="/bin/the-handler"
Where you can define multiple "actions" but only one "handler". The actions have a label at the beginning (first word) and a human readable text that will be presented in the menu.
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.
Best, Rodrigo. _______________________________________________ Dillo-dev mailing list -- dillo-dev@mailman3.com To unsubscribe send an email to dillo-dev-leave@mailman3.com
Hi, Rodrigo Arias <rodarima@gmail.com> wrote:
One of the features I would like to include is the ability to open a link with an external handler. We have a proof of concept that uses the rule file, but I think it is too complex for now:
I don't know about the complexity, but it worked fine here!
I'm thinking it may be better to add an easier variant first, that we can extend later. I'm considering adding these to dillorc:
actions="default Open with external tool" actions="firefox Open with Firefox" actions="mpv Open with MPV" actions="mpv-audio Open with MPV (audio)" handler="/bin/the-handler"
Where you can define multiple "actions" but only one "handler". The actions have a label at the beginning (first word) and a human readable text that will be presented in the menu.
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.
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 Regards, Alex
Rodrigo Arias wrote:
actions="default Open with external tool" actions="firefox Open with Firefox" actions="mpv Open with MPV" actions="mpv-audio Open with MPV (audio)" handler="/bin/the-handler"
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. 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. This would be a separate feature to implement, but maybe it would be a good fit for the same sub-menu.
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?
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, a1ex@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.
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.
Hi, On Fri, Oct 25, 2024 at 10:00:44PM +0200, Rodrigo Arias wrote:
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"
I implemented this here using the option "link_action" which will *only* add new entries to the Link menu: https://github.com/dillo-browser/dillo/pull/326 https://github.com/dillo-browser/dillo/pull/326.patch I set the $url environment variable to hold the link URL and $origin to hold the current page URL, in case you want to handle links different based on which page you where clicking from. It would be nice if it gets some testing, specially with strange URL looking cases. Hopefully it covers all your use cases, Alex.
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.
This doesn't seem to be necessary, $() or $foo are not expanded when they appear in the $url.
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.
The current design also covers this "tag" mechanism as a specific case: link_action="Open video:my-handler video" link_action="Open audio:my-handler audio" And in my opinion is more simple, as it can be used directly without any script: link_action="Open with MPV:mpv $url" link_action="Open with Firefox:firefox $url" In the future we can also add a similar thing for when Dillo opens an URL but the content type is unknown, so that it offers more options than a download. At that point we will know the content type, so we can do better handling. But let's keep it simple for 3.2.0. Best, Rodrigo.
Hi Rodrigo, Rodrigo Arias <rodarima@gmail.com> wrote:
I implemented this here using the option "link_action" which will *only* add new entries to the Link menu:
https://github.com/dillo-browser/dillo/pull/326
https://github.com/dillo-browser/dillo/pull/326.patch
I set the $url environment variable to hold the link URL and $origin to hold the current page URL, in case you want to handle links different based on which page you where clicking from.
It would be nice if it gets some testing, specially with strange URL looking cases. Hopefully it covers all your use cases, Alex.
So far this is working flawlessly with every URL I have thrown at it, including stufff with a lot of symbols, and also extra-long links. I will keep testing this heavily, but hopefully it's good to go! Looks like I will be able to retire my inferior link handler patch now, thank you very much! Best regards, Alex
Hi,
So far this is working flawlessly with every URL I have thrown at it, including stufff with a lot of symbols, and also extra-long links. I will keep testing this heavily, but hopefully it's good to go!
Looks like I will be able to retire my inferior link handler patch now, thank you very much!
Nice!, I will merge it soon then :) Best, Rodrigo.
participants (4)
-
a1ex＠dismail.de -
Kevin Koster -
Rodrigo Arias -
Xavier Del Campo Romero