- Dillo-dev - lists.mailman3.com

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

Re: Navigation by pages

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I decided to leave on YES for a simple reason: the laptop I was using > Dillo on didn't have a middle button, so the only way to close the > tabs was to press both buttons at the same time to emulate the middle > one (or the X button). So I assumed that it is possible that the same > scenario happens to other people too which only use an old laptop, > and they may think that the only way to close tabs is on the X button > on the right, as we don't have an X over each tab. > > Of course you can always change it to your preferences, but I think > it is a safer default this way to be easily discovered. Sounds fair, thanks for explaining. I guess there is no 'one size fits all' solution, but the setting is easy enough to change. I like the middle button specifically because it is harder to push, making it more difficult to close a tab by accident. > I would also prefer opening new tabs without the mouse wheel button > or the keyboard. So far I can to by clicking and holding the right > button, dragging a couple of pixels to the right to open in a new > tab, then releasing it. I'm thinking it may be nice to make this work > without the need of dragging, so by default it selects open in a new > tab. We can place a threshold to not consider quick press and release > events to cause the selection to be clicked. > > The same may be also doable with the left button, so if you click but > keep it pressed for a configurable threshold it is opened in a new > tab (of the other way around). Interesting! I like this idea and think it would be useful in various situations like limited hardware, or accessibility needs, etc. Hopefully its not too difficult to implement. Regards, Alex

Oct. 18, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >I suspect that its OpenBSD which is helping to bring this issue out > >more. > > I got a QEMU virtual machine with OpenBSD 7.6 and Xorg, I'll try to > install a development environment there and do some testing. It is > taking me some time. I was able to reproduce the issue in QEMU with a completely stock OpenBSD install: https://alex.envs.net/test/qemu-dillo-test1.png -Alex

Oct. 18, 2024

Re: scroll_step description

by Kevin Koster

Rodrigo Arias wrote: > On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: >>There's a new "scroll_step" option in the example configuration file for >>3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that >>this only affects the mouse wheel, but it also changes the distance the >>page moves when the arrow keys are pressed and the overlap of >>previous page content that's left when you press Page Up/Down. I think >>that's a little confusing, especially as the value has changed since >>the default behaviour in 3.0.5 (the old value seems to have been about >>25). > > This is now controlled independently with the scroll_page_overlap, which > by default uses the value 50 px. While the scroll_step controls how much > it advances with the arrows, by default 100 pixels. > > See: https://github.com/dillo-browser/dillo/pull/277 Great work! Much better to have separate settings.

Oct. 17, 2024

Re: Navigation by pages

by Rodrigo Arias

Hi, >Works fine for me! Thanks! I have also added two other improvements (last ones I promise). Clicking on the up and down buttons of the scrollbar in page mode jumps to the top and bottom. And scrolling a full page, now takes into account if the horizontal scrollbar is visible or not when computing the overlap, so the number of pixels of overlap you specify are always duplicated in the next page. Now I'm starting to miss the page scrolling mode in other programs... >> Also, do you usually set focus_new_tab to NO?, I'm considering >> switching the default to NO. Same with show_quit_dialog. > >I set 'NO' for both of those, but can understand why the original >decision was made to default to 'YES'. > >I think that Dillo was originally trying to cater to beginners and >people unfamiliar with how a browser works, but times have changed and >maybe adjusting some of these defaults would better serve our actual >userbase. I agree. Okay, so I will flip those then. >In my opinion this should also be the default: >right_click_closes_tab=NO > >It may be a matter of preference, but that is how the other browsers do >it. Most people are probably used to using the middle click for >this, and so having it close the tab with the right click might be >unexpected and undesired. I decided to leave on YES for a simple reason: the laptop I was using Dillo on didn't have a middle button, so the only way to close the tabs was to press both buttons at the same time to emulate the middle one (or the X button). So I assumed that it is possible that the same scenario happens to other people too which only use an old laptop, and they may think that the only way to close tabs is on the X button on the right, as we don't have an X over each tab. Of course you can always change it to your preferences, but I think it is a safer default this way to be easily discovered. In any case I have not done any research to back my claims. On my desktop I also use the right button, because I don't like clicking the mouse wheel (I think in my mouse is really hard to press), but this doesn't justify the defaults. I would also prefer opening new tabs without the mouse wheel button or the keyboard. So far I can to by clicking and holding the right button, dragging a couple of pixels to the right to open in a new tab, then releasing it. I'm thinking it may be nice to make this work without the need of dragging, so by default it selects open in a new tab. We can place a threshold to not consider quick press and release events to cause the selection to be clicked. The same may be also doable with the left button, so if you click but keep it pressed for a configurable threshold it is opened in a new tab (of the other way around). Best, Rodrigo.

Oct. 16, 2024