- Dillo-dev - lists.mailman3.com

Dillo 3.1.0 on Mac OS X Tiger
by Sevan Janiyan 08 May '24

08 May '24

Attached is a screenshot taken today of Dillo 3.1.0 running on Mac OS X Tiger 10.4, linked against latest versions of OpenSSL 3.2, zlib, libpng, libjpeg. :) Sevan

2 1

Dark mode screenshot and tutorial
by a1ex＠dismail.de 05 May '24

05 May '24

Hi list, Attached is a screenshot of Dillo with a simple "Dark Mode" theme. For those interested in how to do this, here is a small tutorial: Put this in ~/.dillo/style.css: * { background-color: #000000 !important; color: #999999 !important; } :link { color: #ffffff !important; text-decoration: none !important; } :visited { color: #ffffff !important; text-decoration: underline !important; } Put this in ~/.dillo/dillorc: bg_color=000000 ui_fg_color=999999 ui_main_bg_color=000000 ui_text_bg_color=000000 ui_selection_color=444444 ui_button_highlight_color=ffffff ui_tab_active_bg_color=999999 ui_tab_active_fg_color=000000 ui_tab_bg_color=000000 And then we can tighten up the UI to taste: panel_size=tiny small_icons=YES show_search=NO show_help=NO Hopefully someone will find this useful :) Regards, Alex

1 1

Dillo 3.1.0 released
by Rodrigo Arias 04 May '24

04 May '24

Hi, I'm happy to announce that version 3.1.0 is finally released! https://dillo-browser.github.io/latest.html Thank you all for the patches and tests! Best, Rodrigo.

2 1

Re: Broken CSS in Hacker News
by Rodrigo Arias 04 May '24

04 May '24

FYI ----- Forwarded message from Hacker News <hn(a)ycombinator.com> ----- Date: Sat, 4 May 2024 13:58:22 -0700 From: Hacker News <hn(a)ycombinator.com> To: Rodrigo Arias <rodarima(a)gmail.com> Subject: Re: Broken CSS in Hacker News Should be fixed now. Thanks! dang On Sat, May 4, 2024 at 4:36 AM Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > I'm adding Hacker News in CC. > > On Sat, May 04, 2024 at 11:20:25AM +0200, a1ex(a)dismail.de wrote: > >Hi Rodrigo, > > > >> >>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. > > > >Here is an example: > >https://news.ycombinator.com/item?id=40250573 > > > >Viewing the page in Dillo with CSS turned off, some of the text > >runs off the window and I have to scroll right to see it. With CSS > >turned on, the text is very small and impossible to read on my monitor > >(but now the offending lines fit on the window). > >In Firefox, the text appears correctly and is always wrapped to the > >window regardless of zoom level. > > I see what is going on. > > By default, Dillo doesn't wrap the content of <pre> elements. But, the > following rule in HN CSS should cause it to wrap the text at spaces and > newlines: > > > pre { overflow: auto; padding: 2px; white-space: pre-wrap; > > overflow-wrap:anywhere; } > > But Dillo fails to process the CSS document because it doesn't > understand a previous rule: > > > input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; } > > The 'input[type=\"submit\"]' selector is causing the CSS parser to > ignore the rest of the CSS style sheet. > > I believe this is a bug in HN CSS, as it should be: > > > input[type="submit"] { font-family:Verdana, Geneva, sans-serif; } > > Which works properly, I attached a reproducer. > > I have to check what is going on in the parser, by I suspect the first > \" causes the parser to enter "string mode", and then the second \" is > parsed as a quote inside the string because it is escaped, not as the > closing quote. So everything else in the CSS file is treated as the > content of the string. This should be fixed on HN side. > > We should make the CSS parser more robust to these problems. > > In the meanwhile, you can add this workaround in ~/.dillo/style.css to > make <pre> wrapped by default in all pages: > > > pre { white-space: pre-wrap; } > > Best, > Rodrigo > ----- End forwarded message -----

1 0

Feature idea: zoom buttons
by a1ex＠dismail.de 04 May '24

04 May '24

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

3 6

"Layout::resizeIdle calls" messages ignore show_msg=NO
by Kevin Koster 04 May '24

04 May '24

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.

2 2

[PATCH] User defined new tab page
by a1ex＠dismail.de 02 May '24

02 May '24

Hi list, Here is a patch to add a new tab page to dillo. You can define any url in dillorc preference 'new_tab_page', and it will be automatically opened in new tabs. Setting the value "about:blank" will retain the default blank page behavior. I tried to make it work with an empty value of "", but for some reason dillo prepends 'http:' to the value. Hopefully this won't be a problem, because now the about:blank is pre-selected and you can just start typing over it. If there is a better way to do this, I'm open to suggestions. Regards, Alex --- dillorc Thu Apr 11 11:11:01 2024 +++ dillorc Thu Apr 11 11:14:18 2024 @@ -154,6 +154,11 @@ # home="file:/home/jcid/HomePage/Home.html" #home="https://dillo-browser.github.io/" +# Set the new tab page. +# new_tab_page="dpi:/bm/" +# new_tab_page="https://example.com/" #new_tab_page="about:blank" + # Set the URLs used by the web search dialog. # "%s" is replaced with the search keywords separated by '+'. # Format: search_url="[prefix ][<label> ]<url>" --- src/prefs.c Thu Apr 11 11:18:24 2024 +++ src/prefs.c Thu Apr 11 11:21:16 2024 @@ -14,6 +14,7 @@ #define PREFS_START_PAGE "about:splash" #define PREFS_HOME "https://dillo-browser.github.io/" +#define PREFS_NEW_TAB_PAGE "about:blank" #define PREFS_FONT_SERIF "DejaVu Serif" #define PREFS_FONT_SANS_SERIF "DejaVu Sans" #define PREFS_FONT_CURSIVE "URW Chancery L" @@ -109,6 +110,7 @@ prefs.show_ui_tooltip = TRUE; prefs.small_icons = FALSE; prefs.start_page = a_Url_new(PREFS_START_PAGE, NULL); + prefs.new_tab_page = a_Url_new(PREFS_NEW_TAB_PAGE, NULL); prefs.theme = dStrdup(PREFS_THEME); prefs.ui_button_highlight_color = -1; prefs.ui_fg_color = -1; @@ -143,6 +145,7 @@ dFree(prefs.font_sans_serif); dFree(prefs.font_serif); a_Url_free(prefs.home); + a_Url_free(prefs.new_tab_page); dFree(prefs.http_language); a_Url_free(prefs.http_proxy); dFree(prefs.http_proxyuser); --- src/prefs.h Thu Apr 11 11:23:35 2024 +++ src/prefs.h Thu Apr 11 11:24:35 2024 @@ -48,6 +48,7 @@ char *no_proxy; DilloUrl *start_page; DilloUrl *home; + DilloUrl *new_tab_page; bool_t allow_white_bg; int32_t white_bg_replacement; int32_t bg_color; --- src/prefsparser.cc Thu Apr 11 11:26:31 2024 +++ src/prefsparser.cc Thu Apr 11 11:28:12 2024 @@ -171,6 +171,7 @@ { "fullwindow_start", &prefs.fullwindow_start, PREFS_BOOL, 0 }, { "geometry", NULL, PREFS_GEOMETRY, 0 }, { "home", &prefs.home, PREFS_URL, 0 }, + { "new_tab_page", &prefs.new_tab_page, PREFS_URL, 0 }, { "http_language", &prefs.http_language, PREFS_STRING, 0 }, { "http_max_conns", &prefs.http_max_conns, PREFS_INT32, 0 }, { "http_persistent_conns", &prefs.http_persistent_conns, PREFS_BOOL, 0 }, --- src/uicmd.cc Thu Apr 11 11:31:18 2024 +++ src/uicmd.cc Thu Apr 11 12:06:13 2024 @@ -778,6 +778,7 @@ a_UIcmd_set_location_text(new_bw, URL_STR(url)); BW2UI(new_bw)->focus_main(); } else { + a_UIcmd_open_url((BrowserWindow*)new_bw, prefs.new_tab_page); BW2UI(new_bw)->focus_location(); a_UIcmd_set_buttons_sens(new_bw); }

2 8

<td> width attributes ignored
by Kevin Koster 28 Apr '24

28 Apr '24

Another page rendering issue that's introduced after the 3.0.5 release, this time affecting my own website. URL: http://www.ombertech.com/ CSS: enabled or disabled Summary: <td> width attributes ignored. 3.0.5: Heading table at the top of the page displays correctly scaled with links in the middle formatted in a horizontal row if they all fit in 1/3rd of the browser window's width. 3.1.0-rc1: The "width" attributes of the <td> elements are ignored and the links in the middle are thereby squashed into a vertical row. Further testing with modified versions of the page shows that this table cell width problem is only present if the width attribute in the <td> elements is a percentage and the <table> element also has a width attribute set as a percentage, then the <td> width attributes get ignored. If either (or both) table or td width is in pixels, the problem isn't present, only when table and td width are both specified as percentages. So far as I can tell setting width in <table> and <td> elements as a percentage is valid for HTML 4.01 Transitional, and other browsers (Links, Firefox) render the table correctly.

2 2

Dillo not rendering HTML with comments before <!DOCTYPE>
by Kevin Koster 28 Apr '24

28 Apr '24

This problem was present in 3.0.5 as well as in 3.1.0-rc1. URL: http://www.lemis.com/ CSS: enabled or disabled Summary: Won't render HTML with comments before <!DOCTYPE>. Pages on this website aren't rendered, just displayed as source code. Although they are XHTML, this doesn't appear to be due to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036382 If I save the file as lemis.xhtml and remove the two comment lines before the <!DOCTYPE> declaration, then it renders when I load it with file:// or http://, otherwise it doesn't. My reading is that comments there are valid for HTML 4 (which is declared in the page's <!DOCTYPE>) since the standard says: White space (spaces, newlines, tabs, and comments) may appear before or after each section. https://www.w3.org/TR/html401/struct/global.html#h-7.1

2 7

scroll_step description
by Kevin Koster 26 Apr '24

26 Apr '24

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).

2 4