- Dillo-dev - lists.mailman3.com

Re: Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo, > >Just for fun, here is a version which uses curl instead of wget. This > >has the advantage that curl can output the Content-Type from the > >server, and we can use this to perform actions instead of relying on > >the file extension. Another advantage is that curl can tell us the > >output filename, so we don't have to mess around to get that > >anymore. > > These examples are very useful to test the ideas of rules and > actions. Here is how I could imagine it being written: > > action youtube label "Open YouTube in MPV" shell "mpv $url" > action audio label "Open audio in MPV" shell "mpv $url" > action video label "Open video in MPV" shell "mpv $url" > action image label "Open image in NSXIV" download shell "nsxiv > $out" action mupdf label "Open PDF in MuPDF" download shell "mupdf > $out" action default open-new-tab "$url" > > match url "outu" action youtube > match url "\.(mp3|ogg)$" action audio > match url "\.(mkv|mp4|webm)$" action video > # From here on Dillo needs to fetch the headers > match mime-type "image" action image > match mime-type "pdf" action mupdf > # Catchall for non-matched urls > match any action default This looks pretty reasonable. I guess the trick is to not make things too complicated, and yet still make it flexible enough. > Although, we may use Dillo to download the content on the fly, like > this: > > action image label "Open image in NSXIV" pipe "nsxiv -" > action mupdf label "Open PDF in MuPDF" pipe "mupdf -" > > So there is no need to download the file completely before it is piped > to the tools. I don't think mupdf will open a file piped from stdin. Neither does nsxiv. Maybe I'm missing something. It is possible to determine the Content-Type without downloading the file with something like: curl -XHEAD -s -w '%{content_type}' $url Also, it may be desirable to restrict the download filesize to a reasonable limit, which can also be determined with a similar method. > Anyway, I need to think more about it. I also need to consider how > this could be moved out of Dillo, so we don't bring more complexity > to it. > > Executing a user script is fine, but I also want to be able to rewrite > the page and bring it back to Dillo for display, which requires more > cooperation. I'm curious what the use-case for this is. Sounds interesting. > Just a small comment, you can use `exec` to avoid nesting the ifs as > it won't return: > > if echo $1 | grep outu; then > exec $youtube "$1" > fi > > Or exit: > > if echo $1 | grep outu; then > $youtube "$1" > exit $? > fi Oops! I should know better than that, but there is is.. Thanks for pointing it out. Regards, Alex

June 17, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Sun, Jun 16, 2024 at 06:54:41PM +0200, a1ex(a)dismail.de wrote: >> Sure, here is a very basic example which mainly just goes by the >> extension in the URL to handle some common filetypes. I suppose that >> for more complex links in which the filetype can't be parsed like >> this, you could curl the link into the 'file' command to determine >> the type: curl -s "https://example.com/filename" | file - >> But that's overkill for my needs. >> There are many ways to improve on this, but hopefully it at >> least illustrates the concept. > >Just for fun, here is a version which uses curl instead of wget. This >has the advantage that curl can output the Content-Type from the >server, and we can use this to perform actions instead of relying on >the file extension. Another advantage is that curl can tell us the >output filename, so we don't have to mess around to get that anymore. These examples are very useful to test the ideas of rules and actions. Here is how I could imagine it being written: action youtube label "Open YouTube in MPV" shell "mpv $url" action audio label "Open audio in MPV" shell "mpv $url" action video label "Open video in MPV" shell "mpv $url" action image label "Open image in NSXIV" download shell "nsxiv $out" action mupdf label "Open PDF in MuPDF" download shell "mupdf $out" action default open-new-tab "$url" match url "outu" action youtube match url "\.(mp3|ogg)$" action audio match url "\.(mkv|mp4|webm)$" action video # From here on Dillo needs to fetch the headers match mime-type "image" action image match mime-type "pdf" action mupdf # Catchall for non-matched urls match any action default Although, we may use Dillo to download the content on the fly, like this: action image label "Open image in NSXIV" pipe "nsxiv -" action mupdf label "Open PDF in MuPDF" pipe "mupdf -" So there is no need to download the file completely before it is piped to the tools. On the other hand, I can already spot a problem. When we right-click on a link to find out which actions are available, some of them require the mime type to be known, which would require a request to the server. So we cannot determine which actions will match beforehand. Maybe a better way is to define the set of menu entries first, which could also be altered by match rules: menu label "Open in default program" tag open menu label "Save in notes" tag save-notes Then we use the information of which menu item was selected *and* the clicked url to do the full handling: action youtube shell "mpv $url" action audio shell "mpv $url" action video shell "mpv $url" action image download shell "nsxiv $out" action mupdf download shell "mupdf $out" action save-notes shell "echo $url >> ~/.dillo/notes.txt && echo Saved" action default open-new-tab "$url" match tag open { match url "outu" action youtube match url "\.(mp3|ogg)$" action audio match url "\.(mkv|mp4|webm)$" action video # From here on Dillo needs to fetch the headers match mime-type "image" action image match mime-type "pdf" action mupdf } match tag save-notes action save-notes match any action default So when the user clicks "Save in notes" it doesn't go through the normal "open with" rules, but only matches the save-notes rule. Anyway, I need to think more about it. I also need to consider how this could be moved out of Dillo, so we don't bring more complexity to it. Executing a user script is fine, but I also want to be able to rewrite the page and bring it back to Dillo for display, which requires more cooperation. ># temporary file location >tmp_dir="/tmp/dillo" > ># youtube. checks for "outu" string in URL >if echo $1 | grep outu >then $youtube "$1" >else Just a small comment, you can use `exec` to avoid nesting the ifs as it won't return: if echo $1 | grep outu; then exec $youtube "$1" fi Or exit: if echo $1 | grep outu; then $youtube "$1" exit $? fi Best, Rodrigo.

June 16, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

On Sun, 16 Jun 2024 13:07:38 +0200 <a1ex(a)dismail.de> wrote: > On Sat, 15 Jun 2024 22:16:12 +0200 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > Thanks! I'm interested in how you are using a script to match > > several URLs and do some actions automatically, not sure if you > > would be interesting in sharing it (or some parts). > > > Sure, here is a very basic example which mainly just goes by the > extension in the URL to handle some common filetypes. I suppose that > for more complex links in which the filetype can't be parsed like > this, you could curl the link into the 'file' command to determine > the type: curl -s "https://example.com/filename" | file - > But that's overkill for my needs. > There are many ways to improve on this, but hopefully it at > least illustrates the concept. Just for fun, here is a version which uses curl instead of wget. This has the advantage that curl can output the Content-Type from the server, and we can use this to perform actions instead of relying on the file extension. Another advantage is that curl can tell us the output filename, so we don't have to mess around to get that anymore. --------------------------------------------------------------------- #!/bin/sh # Example Dillo URL action handler script using curl # handlers youtube="mpv" audio="mpv" video="mpv" image="nsxiv" pdf="mupdf" # temporary file location tmp_dir="/tmp/dillo" # youtube. checks for "outu" string in URL if echo $1 | grep outu then $youtube "$1" else # audio. uses file extension from URL if echo $1 | tail -c -5 | grep -e mp3 -e ogg then $audio "$1" else # video. uses file extension from URL if echo $1 | tail -c -5 | grep -e mkv -e mp4 -e webm then $video "$1" else # use curl to download the file, and save Content-Type and filename if [ ! -d $tmp_dir ] ; then mkdir $tmp_dir ; fi curl -s --write-out "%{content_type} \n%{filename_effective}" \ --remote-name --output-dir "$tmp_dir" "$1" > $tmp_dir/file_info set the filename based on curl output to file_info filename=$(tail -1 $tmp_dir/file_info) # images. checks content type from file_info if head -1 $tmp_dir/file_info | grep image ; then $image "$filename" fi # pdf. checks content type from file_info if head -1 $tmp_dir/file_info | grep pdf ; then $pdf "$filename" fi fi fi fi -------------------------------------------------------------------- Regards, Alex

June 16, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

On Sat, 15 Jun 2024 22:16:12 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Thanks! I'm interested in how you are using a script to match several > URLs and do some actions automatically, not sure if you would be > interesting in sharing it (or some parts). Sure, here is a very basic example which mainly just goes by the extension in the URL to handle some common filetypes. I suppose that for more complex links in which the filetype can't be parsed like this, you could curl the link into the 'file' command to determine the type: curl -s "https://example.com/filename" | file - But that's overkill for my needs. There are many ways to improve on this, but hopefully it at least illustrates the concept. --------------------------------------------------------------------- #!/bin/sh # Example Dillo URL action handler script # handlers youtube="mpv" audio="mpv" video="mpv" image="nsxiv" pdf="mupdf" # temporary file location tmp_dir="/tmp/dillo" # routine to download link and define $file dl() { if [ ! -d $tmp_dir ] ; then mkdir $tmp_dir ; fi wget "$1" --no-use-server-timestamps -P $tmp_dir file="$tmp_dir/$(ls -tp $tmp_dir | grep -v /$ | head -1)" } # youtube if echo $1 | grep outu then $youtube "$1" else # audio if echo $1 | tail -c -5 | grep -e mp3 -e ogg then $audio "$1" else # video if echo $1 | tail -c -5 | grep -e mkv -e mp4 -e webm then $video "$1" else # images if echo $1 | tail -c -5 | grep -e jpg -e jpeg -e png -e gif -e tif then dl "$1" $image "$file" else # pdf if echo $1 | tail -c -5 | grep pdf then dl "$1" $pdf "$file" fi ; fi ; fi ; fi ; fi ----------------------------------------------------------------------- Regards, Alex

June 16, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Sat, Jun 15, 2024 at 01:31:31PM +0200, a1ex(a)dismail.de wrote: > >> I've made a proof of concept. It is still ugly, but it seems to be >> working: >> >> https://github.com/dillo-browser/dillo/pull/199 > >Very cool! I have briefly tested this and it seems to work fine. Will >continue testing to see if any issues come up. Thanks! I'm interested in how you are using a script to match several URLs and do some actions automatically, not sure if you would be interesting in sharing it (or some parts). >> And here is how it looks like: https://0x0.st/XcyR.png > >I did a double-take when I saw this. Hello from a fellow vaporwave fan! >I happen to have several macroblank tracks in my playlist currently :) Nice to hear :-) Best, Rodrigo.

June 15, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

> I've made a proof of concept. It is still ugly, but it seems to be > working: > > https://github.com/dillo-browser/dillo/pull/199 Very cool! I have briefly tested this and it seems to work fine. Will continue testing to see if any issues come up. > And here is how it looks like: https://0x0.st/XcyR.png I did a double-take when I saw this. Hello from a fellow vaporwave fan! I happen to have several macroblank tracks in my playlist currently :) Regards, Alex

June 15, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Fri, Jun 14, 2024 at 05:25:16PM +0200, a1ex(a)dismail.de wrote: >> 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. > >I like this approach, but not sure how much I can help with it. I've made a proof of concept. It is still ugly, but it seems to be working: https://github.com/dillo-browser/dillo/pull/199 The syntax is the one I commented before. Here is my rulesrc file: action "Open with MPV" shell "mpv $url" action "Open with MPV (only audio)" shell "mpv --no-video $url" action "Open with Firefox" shell "firefox $url" And here is how it looks like: https://0x0.st/XcyR.png >For now, I have taken the example you gave and made barebones patch to >add an external handler to the link menu. It works quite well for me, >in fact its something I'll probably be using every day. A real time saver. > >Its obviously nowhere near as featureful as what you are proposing, but >for the time being, it gets the job done :) Thanks for the patch. I will try to have something merged soon to at least cover this feature. But if I it gets stuck, I wouldn't mind merging your patch or something similar. Best, Rodrigo.

June 14, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo, > >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. I like this approach, but not sure how much I can help with it. For now, I have taken the example you gave and made barebones patch to add an external handler to the link menu. It works quite well for me, in fact its something I'll probably be using every day. A real time saver. Its obviously nowhere near as featureful as what you are proposing, but for the time being, it gets the job done :) Here is the patch for anyone interested, hopefully not too mangled. Sent as an attachment as well, just in case. I haven't gotten around to setting up git send-email yet. diff -u dillorc.orig dillorc --- dillorc.orig Wed Jun 12 21:25:35 2024 +++ dillorc Fri Jun 14 16:37:49 2024 @@ -46,6 +46,9 @@ # height of the visible page area. #scroll_step=100 +# Set the external link handler +#ext_handler="mpv" + #------------------------------------------------------------------------- # RENDERING SECTION #------------------------------------------------------------------------- diff -u src/orig/menu.cc src/menu.cc --- src/orig/menu.cc Fri Jun 14 16:14:55 2024 +++ src/menu.cc Fri Jun 14 16:21:34 2024 @@ -122,6 +122,21 @@ } /** + * Open URL in external handler + */ +static void Menu_open_url_ex_cb(Fl_Widget*, void *user_data) +{ + DilloUrl *url = (DilloUrl *)user_data; + char str[500]; + strcpy(str, prefs.ext_handler); + strcat(str, " "); + strcat(str, URL_STR_(url)); + strcat(str, "> /dev/null 2>&1 &"); + puts(str); + system(str); +} + +/** * Add bookmark */ static void Menu_add_bookmark_cb(Fl_Widget*, void *user_data) @@ -432,8 +447,8 @@ static Fl_Menu_Item link_menu[] = { {"Open link in new tab", 0, Menu_open_url_nt_cb,0,0,0,0,0,0}, - {"Open link in new window", 0, Menu_open_url_nw_cb,0,FL_MENU_DIVIDER,0,0, - 0,0}, + {"Open link in new window", 0, Menu_open_url_nw_cb,0,0,0,0,0,0}, + {"Open with external", 0, Menu_open_url_ex_cb,0,FL_MENU_DIVIDER,0,0,0,0}, {"Bookmark this link", 0, Menu_add_bookmark_cb,0,0,0,0,0,0}, {"Copy link location", 0, Menu_copy_urlstr_cb,0,FL_MENU_DIVIDER,0,0,0,0}, {"Save link as...", 0, Menu_save_link_cb,0,0,0,0,0,0}, diff -u src/orig/prefs.c src/prefs.c --- src/orig/prefs.c Fri Jun 14 16:14:55 2024 +++ src/prefs.c Fri Jun 14 16:24:11 2024 @@ -26,6 +26,7 @@ #define PREFS_HTTP_REFERER "host" #define PREFS_HTTP_USER_AGENT "Dillo/" VERSION #define PREFS_THEME "none" +#define PREFS_EXT_HANDLER "mpv" /*----------------------------------------------------------------------------- * Global Data @@ -71,6 +72,7 @@ prefs.http_strict_transport_security = TRUE; prefs.http_force_https = FALSE; prefs.http_user_agent = dStrdup(PREFS_HTTP_USER_AGENT); + prefs.ext_handler = dStrdup(PREFS_EXT_HANDLER); prefs.limit_text_width = FALSE; prefs.adjust_min_width = TRUE; prefs.adjust_table_min_width = TRUE; @@ -151,6 +153,7 @@ dFree(prefs.http_proxyuser); dFree(prefs.http_referer); dFree(prefs.http_user_agent); + dFree(prefs.ext_handler); dFree(prefs.no_proxy); dFree(prefs.save_dir); for (i = 0; i < dList_length(prefs.search_urls); ++i) diff -u src/orig/prefs.h src/prefs.h --- src/orig/prefs.h Fri Jun 14 16:14:55 2024 +++ src/prefs.h Fri Jun 14 16:24:44 2024 @@ -45,6 +45,7 @@ char *http_proxyuser; char *http_referer; char *http_user_agent; + char *ext_handler; char *no_proxy; DilloUrl *start_page; DilloUrl *home; diff -u src/orig/prefsparser.cc src/prefsparser.cc --- src/orig/prefsparser.cc Fri Jun 14 16:14:55 2024 +++ src/prefsparser.cc Fri Jun 14 16:25:40 2024 @@ -187,6 +187,7 @@ { "adjust_table_min_width", &prefs.adjust_table_min_width, PREFS_BOOL, 0 }, { "load_images", &prefs.load_images, PREFS_BOOL, 0 }, { "load_background_images", &prefs.load_background_images, PREFS_BOOL, 0 }, + { "ext_handler", &prefs.ext_handler, PREFS_STRING, 0 }, { "load_stylesheets", &prefs.load_stylesheets, PREFS_BOOL, 0 }, { "middle_click_drags_page", &prefs.middle_click_drags_page, PREFS_BOOL, 0 }, mpv is just used as a common example. I'm using this with a custom shell script which does some basic parsing and takes various actions depending on the URL. Regards, Alex

June 14, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi, On Thu, Jun 13, 2024 at 09:59:03PM +0200, a1ex(a)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/7bd6b1c4592466d6e717eaf795e98b7c… >> >> 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

June 13, 2024

Re: Option to define external link handler

by a1ex＠dismail.de

> When downloading a file, it is often not only the URL what is needed > to retrieve it. A lot of sites require the session cookies and less > frequently the user agent. So it would be nice to allow passing that > information to the external tool. > > It may be nice to have multiple options, so for example I could > define an action for YouTube videos and another for PDF files. > > However, I would like to support a workflow in which specific URLs > are matched and the appropriate tool is selected to handle it. For > example, I could open YouTube URLs directly into MPV (or similar) by > just clicking on a link without even going to the "right-click > open > in MPV" menu. > > This has the problem that sometimes the URL is not enough, you need > to determine other things. For example, the server may reply that the > URL I just clicked on is in fact a PDF. It would be nice to be able > to tell Dillo to download the file and open it in my PDF viewer > *after* the server has replied with the MIME type. It should be > posible to directly pipe the server reply into the tool, no need to > wait for the download to finish. > Now, going back to your specific case, it may be good to have a > simpler solution first that can later be extended to the more general > approach, so we don't have to wait too long. > > 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. 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. 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. > A similar feature has been implemented in dilloNG: > > https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7c… > > 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. Regards, Alex

June 13, 2024