- Dillo-dev - lists.mailman3.com

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

Re: Option to define external link handler

by Rodrigo Arias

Hi Alex, On Thu, Jun 13, 2024 at 05:52:55PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo and list, > >Thanks for all the recent improvements! > >I have one more feature which I would like to propose, or hopefully at >least get some guidance with. An option to open a link with an external >program. This could be a custom downloader, or whatever else the user >wants. > >Ideally it would be a setting in dillorc, something like: >external_downloader="/usr/bin/some_command -x -y -z" > >And in the right-click Link menu there would be an option to open the >link with the external program, something like "Open link with >external app". > >I can envision various workflows, especially repetitive ones, in which >this would be a real time-saver. There is nothing really wrong with the >built-in downloader, but it's not always ideal. Obviously it's possible >to copy the link and use it in whatever program, but that results in >extra clicks / key-presses. > >Is there any interest in a feature like this? Certainly!, it is one of the firsts issues I opened back in 2020: https://github.com/dillo-browser/dillo/issues/3 However, there are several concerns that we may want to take into account. 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. There is an issue to cover this (and other things): https://github.com/dillo-browser/dillo/issues/56 Those tools may not only take care of downloading the file, they can also perform some substitutions in HTML or CSS files and send them back to Dillo, allowing arbitrary modifications of pages. 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. >I've been looking at the source, but am not really seeing a way to >easily replace the current download program (or even where it is >defined). If anyone has hints on how to do this, I'd appreciate the >help. Or, even better, someone more talented could step up and implement >the feature :) 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. Best, Rodrigo.

June 13, 2024

Option to define external link handler

by a1ex＠dismail.de

Hi Rodrigo and list, Thanks for all the recent improvements! I have one more feature which I would like to propose, or hopefully at least get some guidance with. An option to open a link with an external program. This could be a custom downloader, or whatever else the user wants. Ideally it would be a setting in dillorc, something like: external_downloader="/usr/bin/some_command -x -y -z" And in the right-click Link menu there would be an option to open the link with the external program, something like "Open link with external app". I can envision various workflows, especially repetitive ones, in which this would be a real time-saver. There is nothing really wrong with the built-in downloader, but it's not always ideal. Obviously it's possible to copy the link and use it in whatever program, but that results in extra clicks / key-presses. Is there any interest in a feature like this? I've been looking at the source, but am not really seeing a way to easily replace the current download program (or even where it is defined). If anyone has hints on how to do this, I'd appreciate the help. Or, even better, someone more talented could step up and implement the feature :) Regards, Alex

June 13, 2024

Re: unwanted change in behavior of Dillo Download dialog

by pastebin＠gmx.com

Hi, yes - it id fixed from master (dpi/downloads.cc) thanks On Wed, 12 Jun 2024 21:38:51 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Wed, Jun 12, 2024 at 09:06:47PM +0200, Rodrigo Arias wrote: > >Thanks, I can reproduce it. I opened an issue on GitHub: > > > >https://github.com/dillo-browser/dillo/issues/196 > > Should be fixed in master now (5db6c99). > > Rodrigo > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by Rodrigo Arias

Hi, On Wed, Jun 12, 2024 at 09:06:47PM +0200, Rodrigo Arias wrote: >Thanks, I can reproduce it. I opened an issue on GitHub: > >https://github.com/dillo-browser/dillo/issues/196 Should be fixed in master now (5db6c99). Rodrigo

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by Rodrigo Arias

Hi, On Wed, Jun 12, 2024 at 12:03:09PM -0600, pastebin(a)gmx.com wrote: >Hi, > >using fltk-1.3.9 and dillo-3.1.1 on a linux machine > >when i click 'done' on one of multiple 'save as links' it gives following and the box disappears > >> *** Error in `/usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi': munmap_chunk(): invalid pointer: 0x000000000040783f *** > >if i cp the downloads.dpi from my old dillo-3.1/dillo-3.0.5 into /usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi it is fine and no error Thanks, I can reproduce it. I opened an issue on GitHub: https://github.com/dillo-browser/dillo/issues/196 Rodrigo.

June 12, 2024

Re: unwanted change in behavior of Dillo Download dialog

by pastebin＠gmx.com

Hi, using fltk-1.3.9 and dillo-3.1.1 on a linux machine when i click 'done' on one of multiple 'save as links' it gives following and the box disappears > *** Error in `/usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi': munmap_chunk(): invalid pointer: 0x000000000040783f *** if i cp the downloads.dpi from my old dillo-3.1/dillo-3.0.5 into /usr/local/dillo-3.1.x/lib/dillo/dpi/downloads/downloads.dpi it is fine and no error --- On Tue, 11 Jun 2024 16:55:49 -0600 pastebin(a)gmx.com wrote: > > after saving a number of html from a duck search (save link as) - clicking on done on Dillo Download dialog closes All the downloads not just the one the done was clicked on > > this is very inconvenient as any downloads that were aborted can no longer be identified > > > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 12, 2024