- Dillo-dev - lists.mailman3.com

"Layout::resizeIdle calls" messages ignore show_msg=NO

by Kevin Koster

With Dillo 3.1.0-rc1 (and the current Git repo master branch), these messages are printed to stdout when pages load even with show_msg=NO in dillorc: ... Layout::resizeIdle calls = 578 Layout::resizeIdle calls = 579 Layout::resizeIdle calls = 580 Layout::resizeIdle calls = 581 Layout::resizeIdle calls = 582 Layout::resizeIdle calls = 583 ... I see that they come from a printf call in dw/layout.cc, line 876. Dillo 3.0.5 doesn't output such messages, and they are a minor inconvenience when starting dillo from a terminal window, so it would be nice if they obeyed the show_msg setting in dillorc when Dillo 3.1.0 is released.

May 3, 2024

Re: [PATCH] User defined new tab page

by Rodrigo Arias

On Thu, Apr 11, 2024 at 05:36:07PM +0200, a1ex(a)dismail.de wrote: > >> We may leave the value "about:blank" by default (and forbid ""), but >> then, when opening a new tab, if the new_tab_url matches >> "about:blank", we set it to NULL to leave the location empty, which >> follows the current behavior. Maybe, something like this? >> >> + if (!url && strcmp(URL_STR(prefs.new_tab_page), "about:blank") != >> 0) >> + url = prefs.new_tab_page; > >That does seem like the most elegant solution for now. Thanks! Related PR: https://github.com/dillo-browser/dillo/pull/147 Rodrigo.

May 2, 2024

Re: Feature idea: zoom buttons

by Rodrigo Arias

Hi, On Thu, May 02, 2024 at 09:53:39AM -0400, Charles E. Lehner wrote: >Sounds like a nice feature. >and/or as menu items > >On Wednesday, 1 May 2024 18:02:39 EDT, a1ex(a)dismail.de wrote: >>Hello, >> >>Sometimes the page text is not entirely wrapped to the browser >>window, resulting in lines extending off screen, which is a pain. What do you mean by "resulting in lines extending off screen"? If you mean the Dillo viewport, that is probably caused by some missing CSS feature, which we should fix too, but shouldn't happen with CSS disabled. >>This can be especially visible if remote CSS is disabled, and/or you >>are using a portrait display. Maybe this can be partially mitigated by >>having zoom buttons in the toolbar. Beyond that, there are many other >>reasons why you might want to make the text larger or smaller, >>depending on the page and display configuration, accessibility needs, >>etc. It's not always practical to edit dillorc and restart for every >>page in question. I agree. >>I think one of the Dillo forks did it before. Can we just dynamically >>adjust the 'font_factor' setting? Any interest in this? I think we should implement a zoom control, like on other browsers with Control + / Control -. Here is an issue on this topic: https://github.com/dillo-browser/dillo/issues/21 I have a patch that implements it by adding a zoom factor that changes with Ctrl + and Ctrl -, but it doesn't work well in some cases. Notice that the font_factor is not the same as "zooming" all elements. For example, if you load the old website and try to zoom with Ctrl +, the top image is not scaled accordingly: $ dillo https://dillo-browser.github.io/old/index.html Here is the branch[1] and patch[2]: [1]:https://github.com/dillo-browser/dillo/compare/zoom-control [2]:https://github.com/dillo-browser/dillo/commit/bfa6dfae82887ba51749cf4b71… I think it would made more sense to scale the complete page, and not only the font, but that would require a bit more work. We would need this anyway to implement proper DPI scaling. Rodrigo.

May 2, 2024

Re: Feature idea: zoom buttons

by Charles E. Lehner

Sounds like a nice feature. and/or as menu items On Wednesday, 1 May 2024 18:02:39 EDT, a1ex(a)dismail.de wrote: > Hello, > > Sometimes the page text is not entirely wrapped to the browser > window, resulting in lines extending off screen, which is a pain. > This can be especially visible if remote CSS is disabled, and/or you > are using a portrait display. Maybe this can be partially mitigated by > having zoom buttons in the toolbar. Beyond that, there are many other > reasons why you might want to make the text larger or smaller, > depending on the page and display configuration, accessibility needs, > etc. It's not always practical to edit dillorc and restart for every > page in question. > > I think one of the Dillo forks did it before. Can we just dynamically > adjust the 'font_factor' setting? Any interest in this? > > Regards, > Alex

May 2, 2024

Feature idea: zoom buttons

by a1ex＠dismail.de

Hello, Sometimes the page text is not entirely wrapped to the browser window, resulting in lines extending off screen, which is a pain. This can be especially visible if remote CSS is disabled, and/or you are using a portrait display. Maybe this can be partially mitigated by having zoom buttons in the toolbar. Beyond that, there are many other reasons why you might want to make the text larger or smaller, depending on the page and display configuration, accessibility needs, etc. It's not always practical to edit dillorc and restart for every page in question. I think one of the Dillo forks did it before. Can we just dynamically adjust the 'font_factor' setting? Any interest in this? Regards, Alex

May 1, 2024

Re: <td> width attributes ignored

by Rodrigo Arias

>Thanks. This is caused by commit f5a0b6[1], which should be already >solved[2]. Reverting it fixes this specific problem, I'll add some >regression tests and see if it doesn't break anything else. > >[1]:https://github.com/dillo-browser/dillo/commit/f5a0b6030c2001e5a0fcacf813… >[2]:https://github.com/dillo-browser/dillo/commit/b0f6a3f055039c5c9c3ab65102… Merged in: https://github.com/dillo-browser/dillo/commit/b18496029c93a601646245adeb193… Rodrigo.

April 28, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Rodrigo Arias

Hi, >> If you want to work on it, feel free to do so :-) > >I might have a go at it then. Nice :-) >> I pushed another patch that should fix this issue. It is caused >> primarily by the ".xhtml" extension not being recognized by the file >> plugin, which then tries to detect the doctype and fails in the same >> way, falling back to text/plain. > >All working well now, thanks again. Merged in: https://github.com/dillo-browser/dillo/commit/d9c506df8528c2db84d724048f9bc… Best, Rodrigo.

April 28, 2024

Re: Dillo not rendering HTML with comments before <!DOCTYPE>

by Kevin Koster

On Thu, 25 Apr 2024 21:36:04 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > We can improve the content detection to handle both HTML and > XML-style comments, but I prefer to defer it after the 3.1.0 release. > Websites shouldn't rely on the browser to guess the content type, it > should be stated in the HTTP header or the meta tag. So I don't > consider this a priority that should block the release for longer. Yes, that's reasonable. > If you want to work on it, feel free to do so :-) I might have a go at it then. > >I've built Dillo from that branch and pages on www.lemis.com now > >render correctly, thanks! If I save the homepage as lemis.xhtml it > >still shows as plain text when loaded with file://, though it is > >rendered if the comments before <!DOCTYPE> are removed or if the > >original file is saved as lemis.html. Not much of an issue, but it > >could cause confusion for someone. > > I pushed another patch that should fix this issue. It is caused > primarily by the ".xhtml" extension not being recognized by the file > plugin, which then tries to detect the doctype and fails in the same > way, falling back to text/plain. All working well now, thanks again.

April 27, 2024

Re: scroll_step description

by Rodrigo Arias

On Thu, Apr 25, 2024 at 09:52:50PM +0200, Rodrigo Arias wrote: >Thanks, I added them in this PR: > >https://github.com/dillo-browser/dillo/pull/142 Merged in: https://github.com/dillo-browser/dillo/commit/52110e1ea2a50e91e66bd04981103… Rodrigo.

April 26, 2024

Re: scroll_step description

by Rodrigo Arias

Hi, On Mon, Apr 22, 2024 at 09:38:19AM +1000, Kevin Koster wrote: >> Thanks, I agree. Could you provide a patch? > >OK, see the attached dillorc_scroll_step_description.patch (applied >directly to the file, eg. "patch dillo/dillorc < >dillorc_scroll_step_description.patch"). The patch also includes a fix >for a misspelling of "differentiates" in a later comment there. >I'd only add that a scroll_step is subtracted from the Pg. Up/Down >movement, as I've done in the other attached patch >(user_help_page_step.patch). >--- dillo/dillorc 2024-04-21 22:30:16.000000000 +1000 >+++ dillo_mod/dillorc 2024-04-21 23:22:36.666672639 +1000 >@@ -40,7 +40,10 @@ > # Set your default directory for download/save operations > #save_dir=/tmp > >-# Mouse wheel scroll step in pixels >+# Set the increment in pixels that the page is moved up/down with each input >+# from the mouse wheel, keyboard arrow keys, or scrollbar arrow buttons. >+# Page movement with the Page Up/Down keys is one scroll_step less than the >+# height of the visible page area. > #scroll_step=100 > > #------------------------------------------------------------------------- >@@ -89,7 +92,7 @@ > # If this is set to YES, all CSS size specifications for tables are > # adjusted so that all contents can be displayed. This is seperated > # from "adjust_min_width" so that it is able to mimic Firefox, which >-# differenciates between tables and, say, textblocks (in some cases). >+# differentiates between tables and, say, textblocks (in some cases). > #adjust_table_min_width=YES > > #------------------------------------------------------------------------- >--- dillo/doc/user_help.html 2024-04-21 23:20:19.319997475 +1000 >+++ dillo_mod/doc/user_help.html 2024-04-21 23:19:01.916659356 +1000 >@@ -177,7 +177,7 @@ > <li>Use the <code>Home</code> or <code>End</code> keys to jump to the top > or to the end of a page.</li> > <li>Use <code>PgUp</code> or <code>PgDn</code> to advance a whole >- page (window size).</li> >+ page (window size) minus one step.</li> > <li>Use the arrow keys to move the view a step in that > direction.</li> > <li>You can also use the <code>Space</code> key as <code>PgDn</code> and Thanks, I added them in this PR: https://github.com/dillo-browser/dillo/pull/142 Best, Rodrigo.

April 25, 2024