- Dillo-dev - lists.mailman3.com

Re: Use SIGUSR1 to reload the page

by Rodrigo Arias

Hi Alex, On Mon, Sep 02, 2024 at 04:04:30PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >I find your recent idea[0] to refresh the page on local file changes >interesting, and it could be a quite useful feature. > >[0] https://github.com/dillo-browser/dillo/issues/255 I implemented this on the following PR: https://github.com/dillo-browser/dillo/pull/290 It reloads the focused tabs on all windows of the given Dillo process when a SIGUSR1 signal arrives. Example to reload a local file test.html: All Dillo processes: echo test.html | entr pkill -SIGUSR1 dillo Only one with pid 1234: echo test.html | entr kill -SIGUSR1 1234 I mostly wanted to quickly reload the changes when I edit an HTML page, but this can also be used to monitor a remote page over time, like: $ dillo https://twtxt.envs.net/api/plain/tweets & $ while [ 1 ]; do sleep 10; pkill -SIGUSR1 dillo; done & See: https://forums.raspberrypi.com/viewtopic.php?t=330705 Could you test it on OpenBSD, I hope the signaling part continues to work fine there. Best, Rodrigo.

Oct. 25, 2024

Re: Towards 3.2.0

by Kevin Koster

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?

Oct. 24, 2024

Re: Towards 3.2.0

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)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: > > https://github.com/dillo-browser/dillo/pull/199 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

Oct. 24, 2024

Re: Towards 3.2.0

by Xavier Del Campo Romero

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(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Oct. 24, 2024

Towards 3.2.0

by Rodrigo Arias

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.

Oct. 24, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > >How did you manage to install a new version of FLTK? > > Oh, I just saw they updated to 1.3.9 some days ago: > > https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… > > Maybe I can just update the repos somehow or wait a bit until it > appears. The newer version is now available in snapshots. I just tested it and unfortunately the issues remain the same. -Alex

Oct. 19, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > >How did you manage to install a new version of FLTK? > > Oh, I just saw they updated to 1.3.9 some days ago: > > https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… > > Maybe I can just update the repos somehow or wait a bit until it > appears. Nice catch, it seems that this update has not hit the snapshots yet, so we will have to wait and see. I am somewhat sceptical that this is an FLTK issue. But, to update the system FLTK package, you could just remove it (and the stock Dillo), and then just build/install them from source: # pkg_delete fltk dillo ... -Alex

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

>How did you manage to install a new version of FLTK? Oh, I just saw they updated to 1.3.9 some days ago: https://github.com/openbsd/ports/commit/589a761a9af2a91e81a5800b963fa4448ec… Maybe I can just update the repos somehow or wait a bit until it appears.

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, On Fri, Oct 18, 2024 at 09:40:49PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >Sorry, I forgot to include this, maybe it can aid you in getting a >Dillo build environment set up for OpenBSD: > >Once you have a working system, open an xterm and do: ># pkg_add dillo git automake-1.16.5 autoconf-2.71p0 > >Then get the Dillo source and do: >$ export AUTOMAKE_VERSION="1.16" >$ export AUTOCONF_VERSION="2.71" >$ export CPPFLAGS="-I/usr/local/include -I/usr/X11R6/include" >$ export LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib" > >You should then be able to run autogen.sh and configure. > >As far as debugging tools, there is a gdb built-in but it's pretty >limited. It's probably better to install 'egdb': ># pkg_add egdb > >Also, the built-in 'ktrace' tool might be useful. Thanks! Managed to reproduce a crash with stock Dillo 3.1.1 by: 1. Opening: https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html 2. Going to view source 3. Scroll to the bottom 4. Go to the previous tab 5. Reload 6. Crash: Nav_open_url: new url='dpi:/vsource/:https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html' Nav_open_url: new url='https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html' Segmentation fault (core dumped) There is a very weird behavior in the source code view with the long line of the image. How did you manage to install a new version of FLTK? Best, Rodrigo.

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Sorry, I forgot to include this, maybe it can aid you in getting a Dillo build environment set up for OpenBSD: Once you have a working system, open an xterm and do: # pkg_add dillo git automake-1.16.5 autoconf-2.71p0 Then get the Dillo source and do: $ export AUTOMAKE_VERSION="1.16" $ export AUTOCONF_VERSION="2.71" $ export CPPFLAGS="-I/usr/local/include -I/usr/X11R6/include" $ export LDFLAGS="-L/usr/local/lib -L/usr/X11R6/lib" You should then be able to run autogen.sh and configure. As far as debugging tools, there is a gdb built-in but it's pretty limited. It's probably better to install 'egdb': # pkg_add egdb Also, the built-in 'ktrace' tool might be useful. Regards, Alex

Oct. 18, 2024