Hi, On Thu, Jun 13, 2024 at 09:59:03PM +0200, a1ex@dismail.de wrote:
I have some ideas of how to do it, but I would like to ask you to give concrete examples of that feature so I can test it with those programs.
For me, it could be a number of filetypes, plus things like youtube or other media links. These would be opened in various programs. Obviously, many programs can't directly open a URL and will fail.
Why not just have 3 generic options and let the user decide:
link_handler_1="" link_handler_2="" link_handler_3=""
or whatever name is more suitable.
If the option is undefined, it doesn't show up in the link menu.
Maybe it would be more suitable to follow the syntax of the "search_url" option, which can be used multiple times to define a list of things, so we don't need a predefined number of options. You probably want to set a list of actions with names too: action=Open with MPV;mpv "$url" action=Open with Feh;feh -- "$url" action=Open with Firefox;firefox "$url" Then let the shell expand $url from the envionment, previously set by Dillo with setenv(). What I don't like is that we are mixing the menu label and the command line in the same option value. And we also have to take into account how the shell will interact with the quotes and other symbols (#).
Even if there was only one handler option, personally I would just have it call a shell script which parses the URL and extension and takes appropriate action.
That would be something like this: action=Open with script;/path/to/script.sh And then the script can use $url and possibly other variables from the environment set by Dillo.
This doesn't have to be a 'one size fits all' feature, and I think most Dillo users are advanced enough to use this to their advantage.
Your ideas above regarding Dillo handling the logic for various file and content types are excellent, and also complicated :)
But, these can be two separate features, with optional external link handlers acting as an override for the built-in handling.
Yes, they can be two separate features. I don't have a strong opinion about it yet, I'll have to think about the consequences of having two systems. On the other hand, I think we can design a very simple rule language just to model the actions that can later be extended to other more complex rules without breaking the compatibility with previous configurations. This way we cover all uses with a unified syntax. The previous examples could be written in ~/.dillo/rulesrc as: action "Open with MPV" shell "mpv $url" action "Open with Feh" shell "feh -- $url" action "Open with Firefox" shell "firefox $url" Which only defines a set of available actions, and by default they appear on the link menu as you suggest. I think using a small language is a more elegant solution than trying to squeeze the menu label and the command in a single dillorc option. For now I would only focus on a single rule: action <name> shell <command> Then we can do other things like this to pipe the page to some program: action "Open in editor" pipe "gvim -" Or this, to only show "Download video" on YouTube: match url "http[s]://[www\.]youtube\.com" { action "Download video" shell "yt-dlp -f 18 -- $url" } But see how the syntax is the same, so we don't break the compatibility with previously defined rules.
A similar feature has been implemented in dilloNG:
https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7ce...
But as it is currently implemented is not very extensible, only a "media player" and a "media downloader" options are posible.
Thanks for pointing this out, looks like a good template for testing. If it works well, I'll post a demo patch for anyone interested.
Thanks, Rodrigo