Dillo-dev

Download

By thread

dillo-dev@mailman3.com

2 participants
11672 messages

Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello! When trying to build current HEAD of dillo in NetBSD the build fails with: [...] g++ ... -o dialog.o dialog.cc [...] dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' 37 | #include "dlib/dlib.h" +++ |+#include <cstdlib> 38 | dialog.cc:192:11: error: 'exit' was not declared in this scope 192 | exit(1); | ^~~~ dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' *** [dialog.o] Error code 1 [...] Including <stdlib.h> fixes that and the attached patch does that. Thank you!

Jan. 12, 2026

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > I took a closer look and it seems that this patch doesn't address the > actual problem. The problem is that BSD inherits the non-blocking > behavior while Linux doesn't (POSIX doesn't seem to indicate what should > be done). We want the new_fd to work in blocking mode, so this patch > should fix it for BSD and Linux (otherwise let me know): > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..0d11187e 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) > > int new_fd = accept(control_fd, NULL, NULL); > if (new_fd < 0) { > - if (errno != EWOULDBLOCK) { > - MSG("accept failed: %s\n", strerror(errno)); > + if (errno == EAGAIN || errno == EWOULDBLOCK) { > + /* Nothing? */ > + return; > + } else { > + MSG_ERR("accept failed: %s\n", strerror(errno)); > exit(1); > } > - /* Nothing? */ > - return; > + } > + > + /* From accept(2) man page: > + * > + * On Linux, the new socket returned by accept() does not inherit > + * file status flags such as O_NONBLOCK and O_ASYNC from the > + * listening socket. This behavior differs from the canonical BSD > + * sockets implementation. Portable programs should not rely on > + * inheritance or noninheritance of file status flags and always > + * explicitly set all required flags on the socket returned from > + * accept(). > + * > + * So, disable O_NONBLOCK flag explicitly. > + */ > + if (fcntl(new_fd, F_SETFL, 0) == -1) { > + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); > + exit(1); > } > > ssize_t r; > ---8<--- Tested & works fine here :)

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > > PS. Any chance of adding an option to reload dillorc prefs too? :) > > That would be doable, but I'm not sure if we can just re-parse all > settings as-is without propagating the new values to other parts of > Dillo which might have made a copy. > > Which use case do you have in mind? For the user agent rotation? That was my initial use-case, but I also think that being able to change things like fonts and colors without having to restart dillo could be more useful for average users. For example switching between a light and dark color mode, or switching between regular fonts and CJK, etc. Thanks! Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Tested & works fine here :) Thanks for testing, I merged it. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > > Right away dillo exits and the console message shows this: > > > > ** ERROR **: Control_read_cb Resource temporarily unavailable > > Hmm, I don't think I'm catching all possible errors from that socket. > Maybe this patch can help: > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..c6cd15bf 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > r = read(new_fd, buf, 1); > _MSG("read = %zd\n", r); > if (r < 0) { > - if (errno == EINTR) { > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > continue; > } else { > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > ---8<--- > > Let me know if that makes it work. Looks to be working now! Thanks for this very cool new feature, BTW! Regards, Alex PS. Any chance of adding an option to reload dillorc prefs too? :)

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, On Sat, Dec 20, 2025 at 01:24:55PM +0000, a1ex(a)dismail.de wrote: > > Hmm, I don't think I'm catching all possible errors from that > > socket. Maybe this patch can help: > > > > ---8<--- > > diff --git a/src/IO/control.c b/src/IO/control.c > > index 6f677e52..c6cd15bf 100644 > > --- a/src/IO/control.c > > +++ b/src/IO/control.c > > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > > r = read(new_fd, buf, 1); > > _MSG("read = %zd\n", r); > > if (r < 0) { > > - if (errno == EINTR) { > > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > > continue; > > } else { > > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > > ---8<--- > > > > Let me know if that makes it work. > > Looks to be working now! Thanks for this very cool new feature, BTW! I took a closer look and it seems that this patch doesn't address the actual problem. The problem is that BSD inherits the non-blocking behavior while Linux doesn't (POSIX doesn't seem to indicate what should be done). We want the new_fd to work in blocking mode, so this patch should fix it for BSD and Linux (otherwise let me know): ---8<--- diff --git a/src/IO/control.c b/src/IO/control.c index 6f677e52..0d11187e 100644 --- a/src/IO/control.c +++ b/src/IO/control.c @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) int new_fd = accept(control_fd, NULL, NULL); if (new_fd < 0) { - if (errno != EWOULDBLOCK) { - MSG("accept failed: %s\n", strerror(errno)); + if (errno == EAGAIN || errno == EWOULDBLOCK) { + /* Nothing? */ + return; + } else { + MSG_ERR("accept failed: %s\n", strerror(errno)); exit(1); } - /* Nothing? */ - return; + } + + /* From accept(2) man page: + * + * On Linux, the new socket returned by accept() does not inherit + * file status flags such as O_NONBLOCK and O_ASYNC from the + * listening socket. This behavior differs from the canonical BSD + * sockets implementation. Portable programs should not rely on + * inheritance or noninheritance of file status flags and always + * explicitly set all required flags on the socket returned from + * accept(). + * + * So, disable O_NONBLOCK flag explicitly. + */ + if (fcntl(new_fd, F_SETFL, 0) == -1) { + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); + exit(1); } ssize_t r; ---8<--- Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I have just merged the support to control dillo from a UNIX control > socket. There is now a new program called "dilloc" to send commands > from the CLI. If there is only one dillo process it will choose it, > otherwise it needs to be specified in the DILLO_PID env var. I just went to test this and ran into a possible issue. This is with a fully stock dillo build/install, running on OpenBSD 7.8 amd64: $ dillo -v Dillo Libraries: fltk/1.3.9 jpeg/3.1.2 png/1.6.50 webp/1.6.0 zlib/1.3.1.1-motley brotli/1.0.9 LibreSSL/4.2.0 Features: +GIF +JPEG +PNG +SVG +WEBP +BROTLI +XEMBED +TLS +IPV6 +CTL $ dillo paths: Creating directory '/home/user/.dillo/' paths: Cannot open file '/home/user/.dillo/dillorc': No such file or directory paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/home/user/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/user/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 4.2.0 Cookies: Created file: /home/user/.dillo/cookiesrc Disabling cookies. paths: Cannot open file '/home/user/.dillo/hsts_preload': No such file or directory paths: Using /usr/local/etc/dillo/hsts_preload Nav_open_url: new url='about:splash' Dillo starts normally, then I do this: $ dilloc help Right away dillo exits and the console message shows this: ** ERROR **: Control_read_cb Resource temporarily unavailable This is with just one dillo process running, but I also tested with setting the DILLO_PID variable. That actually gives a working result for only one try, and then gives the error if you try again: $ dillo & [1] 12345 ... $ export DILLO_PID=12345 $ dilloc ping pong $ dilloc ping ** ERROR **: Control_read_cb Resource temporarily unavailable (dillo exits) I verified that the process ID remains unchanged and the variable is still set between dilloc runs, so I'm not sure what's going on. Happy to troubleshoot further if you have any suggestions. Regards, Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Bobby Hiltz

That is exactly what happened. I didn't run dillo, I tried running `dilloc help` first. Like many errors, this one was between the keyboard and the chair.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Looks to be working now! Thanks for this very cool new feature, BTW! Nice! Let me know if you find some other problems. > PS. Any chance of adding an option to reload dillorc prefs too? :) That would be doable, but I'm not sure if we can just re-parse all settings as-is without propagating the new values to other parts of Dillo which might have made a copy. Which use case do you have in mind? For the user agent rotation? Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Not a big deal, but I did need to manual make the ~/.dillo/ctl > directory. It is possible that I missed that part in the instructions. When running dillo it should create the directory on its own (let me know otherwise). But if you run dilloc first without the ctl directory, it will complain and exit: % dilloc ping error: cannot open /home/ram/.dillo/ctl directory: No such file or directory Even if the ctl directory is present but no dillo is found, it should fail with: % dilloc ping error: cannot find ctl socket, is dillo running? Maybe I can make the error message a bit more user friendly for the case when there is no directory. In any case, users should not need to create any directory. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Right away dillo exits and the console message shows this: > > ** ERROR **: Control_read_cb Resource temporarily unavailable Hmm, I don't think I'm catching all possible errors from that socket. Maybe this patch can help: ---8<--- diff --git a/src/IO/control.c b/src/IO/control.c index 6f677e52..c6cd15bf 100644 --- a/src/IO/control.c +++ b/src/IO/control.c @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) r = read(new_fd, buf, 1); _MSG("read = %zd\n", r); if (r < 0) { - if (errno == EINTR) { + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { continue; } else { MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); ---8<--- Let me know if that makes it work. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Bobby Hiltz

Hello, On Fri, 19 Dec 2025 18:29:03 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > I have just merged the support to control dillo from a UNIX control > socket. There is now a new program called "dilloc" to send commands > from the CLI. > ... > I think it will also be useful for users. I have been looking forward to this since I saw the demo on Mastodon. I am sure that I'll find a use. > Let me know if you find something that doesn't work well, it is > experimental for now. Not a big deal, but I did need to manual make the ~/.dillo/ctl directory. It is possible that I missed that part in the instructions. Best, Bobby Hiltz

Dec. 20, 2025

Remote control socket (experimental)

by Rodrigo Arias

Hi, I have just merged the support to control dillo from a UNIX control socket. There is now a new program called "dilloc" to send commands from the CLI. If there is only one dillo process it will choose it, otherwise it needs to be specified in the DILLO_PID env var. Use "dilloc help" to see all the commands available. It needs to be enabled at configure time with --enable-control-socket. The origin of this feature is to improve the test suite by controlling dillo automatically, but I think it will also be useful for users. In particular, the load and dump commands allow the manipulation of any loaded page as a UNIX pipeline: % dilloc dump | <manipulate-cmd> | dilloc load Or go to an alternative page from the current URL: % dilloc open $(dilloc url | sed 's/www\.reddit/old.reddit/') Let me know if you find something that doesn't work well, it is experimental for now. Best, Rodrigo.

Dec. 19, 2025

Re: CJK Fonts

by Bobby Hiltz

Hi, On Sun, 14 Dec 2025 22:49:56 +0000 <a1ex(a)dismail.de> wrote: > Do you have the desired font configured in ~/.dillo/dillorc ? > > Something like this should work (assuming you have the font available > in your OS): > > font_sans_serif="Noto Sans JP" Thanks. It is "Noto Sans CJK JP" on Debian like Rodrigo said. That will have to be my solution for those times I need to visit sites with Japanese (or other CJK fonts) until font substitution support is available. Best, Bobby

Dec. 15, 2025

Re: CJK Fonts

by a1ex＠dismail.de

Hi, "B Hiltz" <bbbhltz(a)mailbox.org> wrote: > I think I have compiled something wrong on my end. When visiting sites > with CJK fonts (e.g. > https://www.unicode.org/standard/translations/japanese.html) none of > the characters display (just empty blocks). Do you have the desired font configured in ~/.dillo/dillorc ? Something like this should work (assuming you have the font available in your OS): font_sans_serif="Noto Sans JP" Regards, Alex

Dec. 14, 2025

Re: CJK Fonts

by Bobby Hiltz

Hello, Thank you both for your replies. > To make it work you can specify a font that has Japanese glyphs like Alex suggested or use a CSS rule in ~/.dillo/style.css in case the site doesn't use "sans-serif" as the font. I will try both of these solutions. Best, Bobby Hiltz (Sorry, I've switched email aliases so that might lead to delays or mix-ups in the mailing list.)

Dec. 14, 2025

Re: CJK Fonts

by Rodrigo Arias

Hi, On Sun, Dec 14, 2025 at 10:49:56PM +0000, a1ex(a)dismail.de wrote: >Hi, > >"B Hiltz" <bbbhltz(a)mailbox.org> wrote: > >> I think I have compiled something wrong on my end. When visiting sites >> with CJK fonts (e.g. >> https://www.unicode.org/standard/translations/japanese.html) none of >> the characters display (just empty blocks). This email didn't reach my inbox or spam folder (maybe gmail delayed it). >Do you have the desired font configured in ~/.dillo/dillorc ? > >Something like this should work (assuming you have the font available in >your OS): > >font_sans_serif="Noto Sans JP" You can use fc-match to see what a given font resolves to in your system. As I don't have Noto, it resolves DejaVu which doesn't handle Japanese either: % fc-match 'Noto Sans JP' DejaVuSans.ttf: "DejaVu Sans" "Book" This is the same problem I described in fedi for Emojis: https://fosstodon.org/@dillo/115702790786501718 https://fosstodon.org/@dillo/115702838816687466 To make it work you can specify a font that has Japanese glyphs like Alex suggested or use a CSS rule in ~/.dillo/style.css in case the site doesn't use "sans-serif" as the font. I tried myself installing noto-fonts and noto-fonts-cjk, but then: % fc-match 'Noto Sans JP' NotoSans-Regular.ttf: "Noto Sans" "Regular" Doesn't find it, it seems to be called "Noto Sans CJK JP": % fc-match 'Noto Sans CJK JP' NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular" So this did it for me: % grep Noto ~/.dillo/dillorc font_sans_serif="Noto Sans CJK JP" Hopefully this won't be needed in FLTK 1.4, which has font substitution support (it will find a fallback font in your system that has Japanese). Best, Rodrigo.

Dec. 14, 2025

CJK Fonts

by B Hiltz

Hello, I think I have compiled something wrong on my end. When visiting sites with CJK fonts (e.g. https://www.unicode.org/standard/translations/japanese.html) none of the characters display (just empty blocks). Running v3.2.0-92-g527846a3 on Debian 13. Also, thank you for keeping Dillo going. I only use it once or twice a week but it is a great tool to have. Best regards, Bobby Hiltz

Dec. 14, 2025

Re: dillo.org get back

by Jesse Lawton

Actually the website is apparantly hosted by Google Cloud. So maybe you could use their abuse form to get the website at least taken down. -- Thanks Jesse Lawton

Dec. 12, 2025

Re: dillo.org get back

by Jesse Lawton

> I have just contacted the Registrar, I didn't realized the name of the > company was literally "Withheld for Privacy". Hah, thats odd. Here though (https://who.is/whois/dillo.org) it shows spaceship as the registrar. -- Thanks Jesse Lawton

Dec. 12, 2025

Re: dillo.org get back

by Rodrigo Arias

Hi, On Thu, Dec 11, 2025 at 10:02:32PM +0000, Jesse Lawton wrote: >Ok, yeah it would be good to get it back sometime for the prime purpose >that it misleads users into thinking its the website. >I might try doing some more work getting it back ;) I have just contacted the Registrar, I didn't realized the name of the company was literally "Withheld for Privacy". Best, Rodrigo.

Dec. 11, 2025

Re: dillo.org get back

by Jesse Lawton

Ok, yeah it would be good to get it back sometime for the prime purpose that it misleads users into thinking its the website. I might try doing some more work getting it back ;) > Thanks, I also reached to Spaceship in the past, but I'm afraid this will > need to be mediated via the IANA or by directly suing the company that is > doing the domain catching. > > As we now have dillo-browser.org I haven't worried much about it. Maybe in > the future I can try to fight to get it back, as now I'm busy with other > aspects of Dillo. > > For now it serves as a great example of the usage of AI slop. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com -- Thanks Jesse Lawton

Dec. 11, 2025

Re: dillo.org get back

by Rodrigo Arias

Hi, On Thu, Dec 11, 2025 at 09:10:38PM +0000, Jesse Lawton wrote: >Hi, I heard about what happened to dillo.org so tried to see if I could >get it back. I contacted the registrar (Spaceship, I found out by >whois), and they replied and I asked them to contact you to see what >could be done and they said this: "Hello, > > Thank you for contacting us back! > > We are sorry for the inconvenience you have faced. Unfortunately, we > won't be able to move the domain to your developer or make any changes > to the domain if you are not its Registrant. > > If you act on behalf of the party interested in the domain name, then > we suggest contacting the Registrant of the [1]dillo.org directly using > the contact information specified in the public > Whois: [2]https://www.spaceship.com/domains/whois/ > > You may contact the Registrant and discuss with them if they can move > the domain to you or your developers. > > If you need any additional information, please do not hesitate to > contact us. > > - > Best regards, > Spaceship Team" > >So it looks like if you contact them you might get it back! Thanks, I also reached to Spaceship in the past, but I'm afraid this will need to be mediated via the IANA or by directly suing the company that is doing the domain catching. As we now have dillo-browser.org I haven't worried much about it. Maybe in the future I can try to fight to get it back, as now I'm busy with other aspects of Dillo. For now it serves as a great example of the usage of AI slop. Best, Rodrigo.

Dec. 11, 2025

dillo.org get back

by Jesse Lawton

Hi, I heard about what happened to dillo.org so tried to see if I could get it back. I contacted the registrar (Spaceship, I found out by whois), and they replied and I asked them to contact you to see what could be done and they said this: "Hello, Thank you for contacting us back! We are sorry for the inconvenience you have faced. Unfortunately, we won't be able to move the domain to your developer or make any changes to the domain if you are not its Registrant. If you act on behalf of the party interested in the domain name, then we suggest contacting the Registrant of the [1]dillo.org directly using the contact information specified in the public Whois: [2]https://www.spaceship.com/domains/whois/ You may contact the Registrant and discuss with them if they can move the domain to you or your developers. If you need any additional information, please do not hesitate to contact us. - Best regards, Spaceship Team" So it looks like if you contact them you might get it back! -- Thanks Jesse Lawton

Dec. 11, 2025

[PATCH] Experimental FLTK 1.4.X support

by a1ex＠dismail.de

Hi, Here is a patch to enable experimental FLTK 1.4.X support which adds a '--enable-fltk14' flag to 'configure'. By default we still use 1.3.X. This addresses bug #509: https://bug.dillo-browser.org/509/ --- a/configure.ac Tue Nov 11 13:06:16 2025 +++ b/configure.ac Fri Nov 21 10:48:50 2025 @@ -115,6 +115,11 @@ AC_ARG_ENABLE([brotli], [enable_brotli=$enableval], [enable_brotli=yes]) +AC_ARG_ENABLE([fltk14], + [AS_HELP_STRING([--enable-fltk14], [Enable FLTK 1.4.X (EXPERIMENTAL)])], + [enable_fltk14=$enableval], + [enable_fltk14=no]) + AC_ARG_WITH([ca-certs-file], [AS_HELP_STRING([--with-ca-certs-file=FILE], [Specify where to find a bundle of trusted CA certificates for TLS])], CA_CERTS_FILE=$withval) @@ -225,25 +230,39 @@ fi dnl ------------------------- -dnl Test for FLTK 1.3 library +dnl Test for FLTK library dnl ------------------------- dnl dnl For debugging and to be user friendly -AC_PATH_PROGS(FLTK_CONFIG,[fltk-config1.3 fltk-config]) -AC_MSG_CHECKING([FLTK 1.3]) +AC_PATH_PROGS(FLTK_CONFIG,[fltk-config1.3 fltk-config1.4 fltk-config]) fltk_version="`$FLTK_CONFIG --version 2>/dev/null`" -case $fltk_version in - 1.3.*) AC_MSG_RESULT(yes) +if test "x$enable_fltk14" = "xyes"; then + AC_MSG_CHECKING([FLTK 1.4.X]) + case $fltk_version in + 1.4.*) AC_MSG_RESULT(yes) LIBFLTK_CXXFLAGS=`$FLTK_CONFIG --cxxflags` LIBFLTK_CFLAGS=`$FLTK_CONFIG --cflags` LIBFLTK_LIBS=`$FLTK_CONFIG --ldflags`;; - 1.4.*) AC_MSG_RESULT(no) - AC_MSG_ERROR([FLTK $fltk_version not supported yet; use FLTK 1.3]);; ?*) AC_MSG_RESULT(no) - AC_MSG_ERROR(FLTK 1.3 required; version found: $fltk_version);; + AC_MSG_ERROR(FLTK 1.4.X required; version found: $fltk_version);; *) AC_MSG_RESULT(no) - AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) -esac + AC_MSG_ERROR(FLTK 1.4.X required; fltk-config not found) + esac +else + AC_MSG_CHECKING([FLTK 1.3]) + case $fltk_version in + 1.3.*) AC_MSG_RESULT(yes) + LIBFLTK_CXXFLAGS=`$FLTK_CONFIG --cxxflags` + LIBFLTK_CFLAGS=`$FLTK_CONFIG --cflags` + LIBFLTK_LIBS=`$FLTK_CONFIG --ldflags`;; + 1.4.*) AC_MSG_RESULT(no) + AC_MSG_ERROR([FLTK $fltk_version not supported yet; use FLTK 1.3]);; + ?*) AC_MSG_RESULT(no) + AC_MSG_ERROR(FLTK 1.3 required; version found: $fltk_version);; + *) AC_MSG_RESULT(no) + AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) + esac +fi dnl ----------------------------------- dnl Test for X11 (only on some systems) Regards, Alex

Nov. 21, 2025

Re: [PATCH] replace github with new site in full tree

by Rodrigo Arias

Hi Alex, On Tue, Nov 11, 2025 at 03:28:33PM +0000, a1ex(a)dismail.de wrote: >Hi, > >I went ahead and updated the whole tree for the new website. Maybe it's >premature and you aren't ready to fully make the switch yet. Yeah, I'll leave them for now until I continue to check that everything works well. I still have to patch cgit to support the new git protocol via HTTP. Thanks!, Rodrigo.

Nov. 11, 2025

[PATCH] replace github with new site in full tree

by a1ex＠dismail.de

Hi, I went ahead and updated the whole tree for the new website. Maybe it's premature and you aren't ready to fully make the switch yet. If so, please disregard. diff -upr a/ChangeLog b/ChangeLog --- a/ChangeLog Tue Nov 11 13:06:16 2025 +++ b/ChangeLog Tue Nov 11 14:56:37 2025 @@ -4,7 +4,7 @@ Dillo project Here we list changes that are relatively significant and/or visible to the user. For a history of changes in full detail, see our Git repository -at https://github.com/dillo-browser/dillo +at https://git.dillo-browser.org/dillo dillo-3.3.0 [Unreleased] diff -upr a/README b/README --- a/README Tue Nov 11 13:06:16 2025 +++ b/README Tue Nov 11 15:02:18 2025 @@ -6,7 +6,7 @@ privacy. It is built with the [FLTK 1.3 GUI toolkit](h Screenshot of the [Dillo Website][dillo] rendered in Dillo: -[dillo]: https://dillo-browser.github.io/ +[dillo]: https://dillo-browser.org/ <p align="center"><img src="doc/dillo.png" width="60%" /></p> @@ -27,9 +27,9 @@ Dillo][mobilized]. > [!WARNING] > As of December 2023, the host `dillo.org` is [no longer under control][gone] > of Dillo developers. A copy of the old website is archived in -> [GitHub Pages][old] and the [Wayback Machine (May 2022)][may]. +> [Dillo website][old] and the [Wayback Machine (May 2022)][may]. -[gone]: https://dillo-browser.github.io/dillo.org.html -[old]: https://dillo-browser.github.io/old/ +[gone]: https://dillo-browser.org/dillo.org.html +[old]: https://dillo-browser.org/old/ [may]: http://web.archive.org/web/20220508022123/https://www.dillo.org/ diff -upr a/README.md b/README.md --- a/README.md Tue Nov 11 13:06:16 2025 +++ b/README.md Tue Nov 11 15:02:18 2025 @@ -6,7 +6,7 @@ privacy. It is built with the [FLTK 1.3 GUI toolkit](h Screenshot of the [Dillo Website][dillo] rendered in Dillo: -[dillo]: https://dillo-browser.github.io/ +[dillo]: https://dillo-browser.org/ <p align="center"><img src="doc/dillo.png" width="60%" /></p> @@ -27,9 +27,9 @@ Dillo][mobilized]. > [!WARNING] > As of December 2023, the host `dillo.org` is [no longer under control][gone] > of Dillo developers. A copy of the old website is archived in -> [GitHub Pages][old] and the [Wayback Machine (May 2022)][may]. +> [Dillo website][old] and the [Wayback Machine (May 2022)][may]. -[gone]: https://dillo-browser.github.io/dillo.org.html -[old]: https://dillo-browser.github.io/old/ +[gone]: https://dillo-browser.org/dillo.org.html +[old]: https://dillo-browser.org/old/ [may]: http://web.archive.org/web/20220508022123/https://www.dillo.org/ diff -upr a/devdoc/Dillo.txt b/devdoc/Dillo.txt --- a/devdoc/Dillo.txt Tue Nov 11 13:06:16 2025 +++ b/devdoc/Dillo.txt Tue Nov 11 14:59:55 2025 @@ -46,7 +46,7 @@ jpeg.c and png.c) 5.- The dpi framework: a gateway to interface the browser with external programs (Example: the bookmarks server plugin). -Dpi spec: https://dillo-browser.github.io/old/dpi1.html +Dpi spec: https://dillo-browser.org/old/dpi1.html ------------------------- diff -upr a/devdoc/Dpid.txt b/devdoc/Dpid.txt --- a/devdoc/Dpid.txt Tue Nov 11 13:06:16 2025 +++ b/devdoc/Dpid.txt Tue Nov 11 14:59:29 2025 @@ -16,7 +16,7 @@ Nomenclature: dpi1: specific term for dillo's plugin spec version 1. - at: https://dillo-browser.github.io/old/dpi1.html + at: https://dillo-browser.org/old/dpi1.html dpi program: any plugin program itself. diff -upr a/devdoc/IO.txt b/devdoc/IO.txt --- a/devdoc/IO.txt Tue Nov 11 13:06:16 2025 +++ b/devdoc/IO.txt Tue Nov 11 15:20:42 2025 @@ -42,7 +42,7 @@ handling of data and its error control was put under of the CCC (Concomitant Control Chain), and the old widget system was replaced with a new one (Dw). The source code is currently regarded as "very stable beta", and is available at -<https://github.com/dillo-browser/dillo>. Dillo is a project +<https://dillo-browser.org/>. Dillo is a project licensed under the GNU General Public License. This paper covers basic design aspects of the hybrid approach diff -upr a/devdoc/README b/devdoc/README --- a/devdoc/README Tue Nov 11 13:06:16 2025 +++ b/devdoc/README Tue Nov 11 15:03:17 2025 @@ -1,7 +1,7 @@ README: Last update Jul 2009 These documents cover dillo's internals. -For user help, see https://dillo-browser.github.io/old/dillo3-help.html +For user help, see https://dillo-browser.org/old/dillo3-help.html -------------------------------------------------------------------------- diff -upr a/dillorc b/dillorc --- a/dillorc Tue Nov 11 13:06:16 2025 +++ b/dillorc Tue Nov 11 15:04:44 2025 @@ -182,13 +182,13 @@ # Set the start page. # start_page="about:blank" -# start_page="https://dillo-browser.github.io/" +# start_page="https://dillo-browser.org/" # start_page="file:/home/jcid/custom_page.html" #start_page="about:splash" # Set the home location # home="file:/home/jcid/HomePage/Home.html" -#home="https://dillo-browser.github.io/" +#home="https://dillo-browser.org/" # Set the new tab page. # new_tab_page="dpi:/bm/" diff -upr a/doc/README b/doc/README --- a/doc/README Tue Nov 11 13:06:16 2025 +++ b/doc/README Tue Nov 11 15:05:24 2025 @@ -1,5 +1,5 @@ Last update: June 2015 This directory contains user documentation. Developer documentation is -only stored in the Git repository at <https://github.com/dillo-browser/dillo>, in +only stored in the Git repository at <https://git.dillo-browser.org/dillo>, in the directory "devdoc", but not part of the tarball. diff -upr a/doc/dillo.1.in b/doc/dillo.1.in --- a/doc/dillo.1.in Tue Nov 11 13:06:16 2025 +++ b/doc/dillo.1.in Tue Nov 11 15:05:49 2025 @@ -114,4 +114,4 @@ Hyphenation pattern files. .BR wget (1) .PP Dillo website: -.B https://dillo-browser.github.io/ +.B https://dillo-browser.org/ diff -upr a/doc/install.md b/doc/install.md --- a/doc/install.md Tue Nov 11 13:06:16 2025 +++ b/doc/install.md Tue Nov 11 15:07:56 2025 @@ -58,7 +58,7 @@ $ sudo make install ### From git ```sh -$ git clone https://github.com/dillo-browser/dillo.git +$ git clone https://git.dillo-browser.org/dillo $ cd dillo $ ./autogen.sh $ mkdir build @@ -174,7 +174,7 @@ libiconv-devel libpng-devel libjpeg-devel libwebp-deve ``` **Note**: Dillo can also be built with OpenSSL (libssl-devel) but there is a -[known problem with detached threads](https://github.com/dillo-browser/dillo/issues/172) +[known problem with detached threads](https://bug.dillo-browser.org/172/) used by the DNS resolver and OpenSSL that causes a crash. If you use OpenSSL, disable the threaded resolver with `--disable-threaded-dns`. @@ -193,7 +193,7 @@ setup-x86_64.exe -q -P gcc-core,gcc-g++,autoconf,autom To build Dillo, follow the usual steps from a Cygwin shell: ```sh -$ git clone https://github.com/dillo-browser/dillo.git +$ git clone https://git.dillo-browser.org/dillo $ cd dillo $ ./autogen.sh $ mkdir build diff -upr a/doc/user_help.in.html b/doc/user_help.in.html --- a/doc/user_help.in.html Tue Nov 11 13:06:16 2025 +++ b/doc/user_help.in.html Tue Nov 11 15:12:05 2025 @@ -747,10 +747,10 @@ service.</p> <p>Plugins can be written in <em>any programming language</em> and they interact with the browser using the -<a href="https://dillo-browser.github.io/old/dpi1.html">DPI protocol</a>. A -<a href="https://dillo-browser.github.io/#plugins">list of plugins</a> +<a href="https://dillo-browser.org/old/dpi1.html">DPI protocol</a>. A +<a href="https://dillo-browser.org/#plugins">list of plugins</a> is available on the Dillo website. Some plugins are just a -<a href="https://raw.githubusercontent.com/dillo-browser/dillo-plugin-man/master/man…">few +<a href="https://git.dillo-browser.org/plugins/man/tree/man.filter.dpi">few lines of shell script</a>, so you are encouraged to read them to learn how to write your own plugins. Plugins are searched by looking for files that end with the <code>.dpi</code> extension (or <code>.dpi.exe</code> in Windows) in @@ -776,7 +776,7 @@ the Plugins may have other software dependencies required for it to work.</p> <p>Here is an example of how to manually install the -<a href="https://github.com/dillo-browser/dillo-plugin-gemini">Gemini protocol plugin</a> +<a href="https://git.dillo-browser.org/plugins/gemini">Gemini protocol plugin</a> (it comes with a Makefile that automates the process, so this is not necessary), which is a filter plugin written in shell script:</p> <pre> @@ -794,7 +794,7 @@ by Dillo.</p> <h3 id="bug-meter">Bug Meter</h3> <p> Dillo includes a -<a href='https://dillo-browser.github.io/old/help/bug_meter.html'>bug meter</a> +<a href='https://dillo-browser.org/old/help/bug_meter.html'>bug meter</a> which shows the number of detected bugs inside the page. The bugs are caught at parsing time, so the error messages also show the line where they occur and provide a hint of what was expected instead. @@ -846,7 +846,6 @@ The list of default bindings is given in the following <footer> <p>This manual has been written in HTML <em>by hand</em> using Vim.<br> If you find any issue, please report it via -<a href="https://github.com/dillo-browser/dillo/issues/new">GitHub</a> or <a href="mailto:dillo-dev@mailman3.com">email</a>. </footer> </div> diff -upr a/dw/style.cc b/dw/style.cc --- a/dw/style.cc Tue Nov 11 13:06:16 2025 +++ b/dw/style.cc Tue Nov 11 15:13:27 2025 @@ -753,7 +753,7 @@ Length StyleImage::ExternalWidgetImgRenderer::getBackg * use a trapezium as draw polygon, or drawTypedLine() for dots and dashes. * Although the concept is simple, achieving pixel accuracy is laborious [1]. * - * [1] https://dillo-browser.github.io/old/css_compat/tests/border-style.html + * [1] https://dillo-browser.org/old/css_compat/tests/border-style.html */ static void drawBorderTop(View *view, Style *style, int x1, int y1, int x2, int y2) diff -upr a/dw/textblock.cc b/dw/textblock.cc --- a/dw/textblock.cc Tue Nov 11 13:06:16 2025 +++ b/dw/textblock.cc Tue Nov 11 15:13:54 2025 @@ -637,7 +637,7 @@ void Textblock::sizeAllocateImpl (core::Allocation *al */ /* align=bottom (base line) */ /* Commented lines break the n2 and n3 test cases at - * https://dillo-browser.github.io/old/test/img/ */ + * https://dillo-browser.org/old/test/img/ */ childAllocation.y = lineYOffsetCanvas (line, allocation) + (line->borderAscent - word->size.ascent); diff -upr a/src/IO/about.c b/src/IO/about.c --- a/src/IO/about.c Tue Nov 11 13:06:16 2025 +++ b/src/IO/about.c Tue Nov 11 15:14:32 2025 @@ -56,7 +56,7 @@ const char *const AboutSplash= "</ul>\n" "\n" "<p>See more details in the\n" -"<a href=\"https://dillo-browser.github.io/\">Dillo website</a>.</p>\n" +"<a href=\"https://dillo-browser.org/\">Dillo website</a>.</p>\n" "\n" "</div>\n" "</body>\n" diff -upr a/src/menu.cc b/src/menu.cc --- a/src/menu.cc Tue Nov 11 13:06:16 2025 +++ b/src/menu.cc Tue Nov 11 15:15:53 2025 @@ -287,7 +287,7 @@ static void Menu_bugmeter_validate_w3c_cb(Fl_Widget*, */ static void Menu_bugmeter_about_cb(Fl_Widget*, void*) { - a_UIcmd_open_urlstr(popup_bw, "https://dillo-browser.github.io/old/help/bug_meter.html"); + a_UIcmd_open_urlstr(popup_bw, "https://dillo-browser.org/old/help/bug_meter.html"); } /** diff -upr a/src/prefs.c b/src/prefs.c --- a/src/prefs.c Tue Nov 11 13:06:16 2025 +++ b/src/prefs.c Tue Nov 11 15:16:15 2025 @@ -13,7 +13,7 @@ #include "prefs.h" #define PREFS_START_PAGE "about:splash" -#define PREFS_HOME "https://dillo-browser.github.io/" +#define PREFS_HOME "https://dillo-browser.org/" #define PREFS_NEW_TAB_PAGE "about:blank" #define PREFS_FONT_SERIF "DejaVu Serif" #define PREFS_FONT_SANS_SERIF "DejaVu Sans" diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Tue Nov 11 13:06:16 2025 +++ b/src/ui.cc Tue Nov 11 15:16:58 2025 @@ -269,7 +269,7 @@ static void help_cb(Fl_Widget *w, void *) } else { MSG("Can't read local help file at \"%s\"." " Getting remote help...\n", path); - a_UIcmd_open_urlstr(bw, "https://dillo-browser.github.io/user_help.html"); + a_UIcmd_open_urlstr(bw, "https://dillo-browser.org/user_help.html"); } dFree(path); } @@ -654,7 +654,7 @@ void UI::make_status_bar(int ww, int wh) // Status box StatusOutput = new Fl_Output(0, wh-sh, ww-bm_w, sh); - StatusOutput->value("https://dillo-browser.github.io/"); + StatusOutput->value("https://dillo-browser.org/"); StatusOutput->labelsize(8); StatusOutput->box(FL_THIN_DOWN_BOX); StatusOutput->clear_visible_focus(); diff -upr a/test/html/manual/floats2.html b/test/html/manual/floats2.html --- a/test/html/manual/floats2.html Tue Nov 11 13:06:16 2025 +++ b/test/html/manual/floats2.html Tue Nov 11 15:17:40 2025 @@ -3,7 +3,7 @@ accusantium doloremque laudantium, totam rem aperiam e ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo. <div style="float:left; border: 1px dashed black">Some text in a -float.<br /><img src="https://dillo-browser.github.io/old/dw/html/not-so-simple-container.png" /></div> +float.<br /><img src="https://dillo-browser.org/old/dw/html/not-so-simple-container.png" /></div> nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, diff -upr a/test/html/manual/floats3.html b/test/html/manual/floats3.html --- a/test/html/manual/floats3.html Tue Nov 11 13:06:16 2025 +++ b/test/html/manual/floats3.html Tue Nov 11 15:18:01 2025 @@ -3,7 +3,7 @@ accusantium doloremque laudantium, totam rem aperiam e ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo.</p> <div style="float:left; border: 1px dashed black">Some text in a -float.<br /><img src="https://dillo-browser.github.io/old/dw/html/not-so-simple-container.png" /></div> +float.<br /><img src="https://dillo-browser.org/old/dw/html/not-so-simple-container.png" /></div> <p>nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem diff -upr a/test/html/manual/floats5.html b/test/html/manual/floats5.html --- a/test/html/manual/floats5.html Tue Nov 11 13:06:16 2025 +++ b/test/html/manual/floats5.html Tue Nov 11 15:18:19 2025 @@ -2,7 +2,7 @@ Sed ut perspiciatis, unde omnis iste natus error sit v accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo. -<div style="float:left; border: 1px dashed black"><img src="https://dillo-browser.github.io/old/Icons/ProgramIcon16.png" /></div> +<div style="float:left; border: 1px dashed black"><img src="https://dillo-browser.org/old/Icons/ProgramIcon16.png" /></div> nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, Regards, Alex

Nov. 11, 2025

[PATCH] add new website to the about:spash page

by a1ex＠dismail.de

Hi, a small patch in case you missed it :) --- a/src/IO/about.c Tue Nov 11 13:08:32 2025 +++ b/src/IO/about.c Tue Nov 11 13:10:19 2025 @@ -56,7 +56,7 @@ const char *const AboutSplash= "</ul>\n" "\n" "<p>See more details in the\n" -"<a href=\"https://dillo-browser.github.io/\">Dillo website</a>.</p>\n" +"<a href=\"https://dillo-browser.org/\">Dillo website</a>.</p>\n" "\n" "</div>\n" "</body>\n"

Nov. 11, 2025

Re: Platform-specific UI affordances?

by Rodrigo Arias

Hi, On Sun, Nov 09, 2025 at 08:45:23AM +1100, Kevin Koster wrote: > a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: > > Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: > >> >Got inspired to do a little vibecoding on @dillo to see how hard it > >> >would be to get native Mac menus. > >> > >> I'm afraid I won't read code aided or generated by a chatbot. It is also > >> a legal liability as the license of that code is not clear. > >> > >> They are literally destroying whatever was that remained of the Web, > >> causing many sites to stop working in Dillo due to the JS-walls. > > > > Strongly agree. I propose a small change to the website to clarify this > > position for future contributors: > > > > --- a/dillo-browser.org.html Sat Nov 8 09:11:31 2025 > > +++ b/dillo-browser.org.html Sat Nov 8 09:12:41 2025 > > @@ -60,6 +60,7 @@ table { margin: 1.5em; } > > <li>Helps authors to comply with web standards by using the > > <a href="old/help/bug_meter.html">bug meter</a> > > <img alt="Bugmeter icon" style="vertical-align:middle" src="img/bugmeter.png">.</li> > > + <li>100% human-made. No AI or LLM is used to create Dillo.</li> > > </ul> > > <p> > > Read the <a href="user_help.html">user manual</a> to discover how to use > > I take such things too literally, I know, but FWIW to me this > implies the project only accepts code that is verifiably human > generated, which is hard to do. You'd need the maintainer watching > over your shoulder while you write it or something. > > Something like "AI-generated code contributions are not accepted" > would inform contributors without implying the ability to verify > the unverifiable. Thanks, I will consider adding some contribution guidelines. Eventually, I'm afraid that we will be unable to recognize honest contributions. Best, Rodrigo.

Nov. 8, 2025

Re: Platform-specific UI affordances?

by Kevin Koster

a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: > Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >> >Got inspired to do a little vibecoding on @dillo to see how hard it >> >would be to get native Mac menus. >> >> I'm afraid I won't read code aided or generated by a chatbot. It is also >> a legal liability as the license of that code is not clear. >> >> They are literally destroying whatever was that remained of the Web, >> causing many sites to stop working in Dillo due to the JS-walls. > > Strongly agree. I propose a small change to the website to clarify this > position for future contributors: > > --- a/dillo-browser.org.html Sat Nov 8 09:11:31 2025 > +++ b/dillo-browser.org.html Sat Nov 8 09:12:41 2025 > @@ -60,6 +60,7 @@ table { margin: 1.5em; } > <li>Helps authors to comply with web standards by using the > <a href="old/help/bug_meter.html">bug meter</a> > <img alt="Bugmeter icon" style="vertical-align:middle" src="img/bugmeter.png">.</li> > + <li>100% human-made. No AI or LLM is used to create Dillo.</li> > </ul> > <p> > Read the <a href="user_help.html">user manual</a> to discover how to use I take such things too literally, I know, but FWIW to me this implies the project only accepts code that is verifiably human generated, which is hard to do. You'd need the maintainer watching over your shoulder while you write it or something. Something like "AI-generated code contributions are not accepted" would inform contributors without implying the ability to verify the unverifiable.

Nov. 8, 2025

Re: Platform-specific UI affordances?

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > >Got inspired to do a little vibecoding on @dillo to see how hard it > >would be to get native Mac menus. > > I'm afraid I won't read code aided or generated by a chatbot. It is also > a legal liability as the license of that code is not clear. > > They are literally destroying whatever was that remained of the Web, > causing many sites to stop working in Dillo due to the JS-walls. Strongly agree. I propose a small change to the website to clarify this position for future contributors: --- a/dillo-browser.org.html Sat Nov 8 09:11:31 2025 +++ b/dillo-browser.org.html Sat Nov 8 09:12:41 2025 @@ -60,6 +60,7 @@ table { margin: 1.5em; } <li>Helps authors to comply with web standards by using the <a href="old/help/bug_meter.html">bug meter</a> <img alt="Bugmeter icon" style="vertical-align:middle" src="img/bugmeter.png">.</li> + <li>100% human-made. No AI or LLM is used to create Dillo.</li> </ul> <p> Read the <a href="user_help.html">user manual</a> to discover how to use Regards, Alex

Nov. 8, 2025

Re: Platform-specific UI affordances?

by Steve Landey

As I said, I'd be happy to redo the work at higher quality. I found it helpful to explore the possibilities and level of effort, just like I'm engaging with you now to find out whether you're interested in my human-written contributions. I am familiar with the macOS SDK and am capable of making the changes myself without a robot. You don't need to read the code slop if you don't want to, although the linked sections are short. I explained the general shape of things in my email, typed with my own fingers. It might help future contributors if you added a written LLM usage policy so your expectations can be clear up front. In any case, from the tone of your response it sounds like I'm not welcome as a contributor, so I'll see myself out. Best of luck. -Steve On Thu, Nov 6, 2025, at 12:32 PM, Rodrigo Arias wrote: > Hi, > >>I've been doing some experiments to see if I can integrate Dillo with >>macOS a bit better. Here's a short video demonstrating a proof of >>concept of some basic changes, just using the native window toolbar and >>menu instead of the FLTK NavBar: >>https://mastodon.gamedev.place/@irskep/115501294400482061 > > From that Mastodon post: > >>Got inspired to do a little vibecoding on @dillo to see how hard it >>would be to get native Mac menus. > > I'm afraid I won't read code aided or generated by a chatbot. It is also > a legal liability as the license of that code is not clear. > > They are literally destroying whatever was that remained of the Web, > causing many sites to stop working in Dillo due to the JS-walls. > > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Nov. 6, 2025

Re: Platform-specific UI affordances?

by Rodrigo Arias

Hi, >I've been doing some experiments to see if I can integrate Dillo with >macOS a bit better. Here's a short video demonstrating a proof of >concept of some basic changes, just using the native window toolbar and >menu instead of the FLTK NavBar: >https://mastodon.gamedev.place/@irskep/115501294400482061 From that Mastodon post: >Got inspired to do a little vibecoding on @dillo to see how hard it >would be to get native Mac menus. I'm afraid I won't read code aided or generated by a chatbot. It is also a legal liability as the license of that code is not clear. They are literally destroying whatever was that remained of the Web, causing many sites to stop working in Dillo due to the JS-walls. Rodrigo.

Nov. 6, 2025

Platform-specific UI affordances?

by steve＠stevelandey.com

Hello, and apologies if this is a duplicate thread. I tried to subscribe to the list via web and then initially emailed it from the wrong address. I've been doing some experiments to see if I can integrate Dillo with macOS a bit better. Here's a short video demonstrating a proof of concept of some basic changes, just using the native window toolbar and menu instead of the FLTK NavBar: https://mastodon.gamedev.place/@irskep/115501294400482061 I'd be happy to redo this work to a higher standard and submit a proper patch. But before I do that, I wanted to ask, is this sort of change in line with the direction of the project? Are you interested in deeper system integrations, or do you prefer to maintain an entirely cross-platform codebase and rely just on FLTK? The code for my prototype is here, just to get a sense of what's needed: https://codeberg.org/irskep/dillo/compare/master...appkit-experiments The primary needs for platform affordances fall into two buckets: message passing, and customization. For message passing, some UI state would need to be communicated out to the platform-specific code, stuff like whether back/forward buttons should be enabled, or which tab is currently active. I wanted to tweak the window title to add a tab count, so I added that as well. Those types of changes are here: https://codeberg.org/irskep/dillo/compare/master...appkit-experiments#diff-… For customization, I'm referring to things like not showing the FLTK-based NavBar if its controls are being shown elsewhere in the UI. Those types of changes are here: https://codeberg.org/irskep/dillo/compare/master...appkit-experiments#diff-… Let me know how you'd like me to proceed or if this outside the scope of what you want to have in the codebase. I want to be a help and not a burden! Thanks, Steve

Nov. 6, 2025

Re: dillo plugin patches

by Rodrigo Arias

Hi, >Thanks, I got the "fix-bsd" branch. Both OpenBSD and NetBSD >compiled without warnings. Plus testing succeeded, no >issues on either system. I think the issues are fixed. Nice!, merged. Rodrigo

Nov. 2, 2025

Re: dillo plugin patches

by John McCue

On Sat, Nov 01, 2025 at 09:20:39PM +0100, Rodrigo Arias wrote: >Hi, > >>I'll try and backtrace, I never did that before, I usually >>throw printfs all over the place. But ... >> >>the version from >> git clone https://git.dillo-browser.org/plugins/gopher >> >>is working after I added this <sys/socket.h> to io.c to >>compile it. > >Should be there: > >https://git.dillo-browser.org/plugins/gopher/tree/io.c?h=fix-bsd#n10 > >Make sure you use the "fix-bsd" branch (currently at a32f745): Thanks, I got the "fix-bsd" branch. Both OpenBSD and NetBSD compiled without warnings. Plus testing succeeded, no issues on either system. I think the issues are fixed. [...] >> >>I attached the warnings to this email as warn_openbsd.txt in >>case you want it. I think many of the warnings can be >>ignored. >> >>NetBSD has no warnings and it too works fine. > >All those warnings should be fixed in the fix-bsd branch. Additional >problems may be caught by the new CFLAGS flags that stick to the C99 >standard (no GNUsisms) and POSIX 2001. Correct, no warnings anywhere. >Best, >Rodrigo. Thanks for all your work, John

Nov. 1, 2025

Re: dillo plugin patches

by Rodrigo Arias

Hi, >I'll try and backtrace, I never did that before, I usually >throw printfs all over the place. But ... > >the version from > git clone https://git.dillo-browser.org/plugins/gopher > >is working after I added this <sys/socket.h> to io.c to >compile it. Should be there: https://git.dillo-browser.org/plugins/gopher/tree/io.c?h=fix-bsd#n10 Make sure you use the "fix-bsd" branch (currently at a32f745): % git clone -b fix-bsd https://git.dillo-browser.org/plugins/gopher Cloning into 'gopher'... % cd gopher % git branch -v * fix-bsd a32f745 Build with C99 standard and POSIX 2001 % grep sys/socket io.c #include <sys/socket.h> >I also checked the original version, that works now, very >odd. I will play around with this to see if I could figure >out what I may have done differently. Thanks! >After I added this <sys/socket.h> to io.c I can compile it >on OpenBSD. > >I attached the warnings to this email as warn_openbsd.txt in >case you want it. I think many of the warnings can be >ignored. > >NetBSD has no warnings and it too works fine. All those warnings should be fixed in the fix-bsd branch. Additional problems may be caught by the new CFLAGS flags that stick to the C99 standard (no GNUsisms) and POSIX 2001. Best, Rodrigo.

Nov. 1, 2025

Re: dillo plugin patches

by John McCue

On Sat, Nov 01, 2025 at 12:34:17AM +0100, Rodrigo Arias wrote: >Hi, > >I added an exception for your email to the list. Following replies >should get archived. Thanks >On Fri, Oct 31, 2025 at 11:34:04AM -0400, John McCue wrote: [...] >>2. dpi.txt -- Corrects an odd issue on OpenBSD with the >> gopher plugin. Access a gopher hole works fine on first >> try, accessing a 2nd hole does nothing, no data is >> presented. Selecting the "Stop" button in dillo works to >> stop the attempted load. My wild guess is one of the >> casts fixed the issue. > >I cannot reproduce this, with or without the patch. Tested in order: > >- gopher://gopher.quux.org:70/1/ >- gopher://gopher.floodgap.com/ > >If you can reliably reproduce this, you could dump the backtrace while >is "doing nothing" in case it got stuck in some network operation. > I'll try and backtrace, I never did that before, I usually throw printfs all over the place. But ... the version from git clone https://git.dillo-browser.org/plugins/gopher is working after I added this <sys/socket.h> to io.c to compile it. I also checked the original version, that works now, very odd. I will play around with this to see if I could figure out what I may have done differently. [...] >> buf[30] = '\0'; >>- rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); >>+ rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) key); >The address of key may not be aligned to the size of a word. Some >architectures will cause an invalid access trying to write an int to a >non-aligned address. > >A better solution is to declare key as an unsigned int. I applied your >fixes and then changed the key variables. This sounds fine by me, I just made changes to "get it working" :) [...] >>diff --git a/Makefile b/Makefile >>index 1ff7047..e41e173 100644 >>--- a/Makefile >>+++ b/Makefile >>@@ -13,6 +13,7 @@ $(DPIDRC): >> mkdir -p $(DPI_DIR) >> if [ -f /etc/dillo/dpidrc ]; then cp /etc/dillo/dpidrc $@; \ >> elif [ -f /usr/local/etc/dillo/dpidrc ]; then cp /usr/local/etc/dillo/dpidrc $@; \ >>+ elif [ -f /usr/pkg/etc/dillo/dpidrc ]; then cp /usr/pkg/etc/dillo/dpidrc $@; \ >> else echo "Can't find dpidrc, is dillo installed?"; false; fi > >This is not in our upstream, but I would rather avoid having each >possible path here. I added a DILLO_PREFIX variable, empty by default. >So you can use `make install DILLO_PREFIX=/usr/pkg` to find dpidrc in >your system. By default it only looks at /etc/dillo/dpidrc. Fine by me. >>diff --git a/io.c b/io.c >>index 615f346..f437c2e 100644 >>--- a/io.c >>+++ b/io.c >>@@ -7,6 +7,7 @@ >>#include <fcntl.h> >>#include <netdb.h> >>#include <netinet/in.h> >>+#include <sys/socket.h> > >Applied. > >> >>#include "io.h" >> > >I fixed several other problems and set the C standard to C99 and >enabled POSIX 2001 by default in CFLAGS. I also performed the build >with gcc and clang on Linux with -Werror -Wall -Wextra -pedantic as >well as with -fsanitize=address to see if I catch something while >running the plugin. Nothing so far. > >I pushed it here (we are moving away from GitHub): > > https://git.dillo-browser.org/plugins/gopher/log/?h=fix-bsd > >Let me know if you encounter problems building it on any BSD. After I added this <sys/socket.h> to io.c I can compile it on OpenBSD. I attached the warnings to this email as warn_openbsd.txt in case you want it. I think many of the warnings can be ignored. NetBSD has no warnings and it too works fine. >Thanks!, >Rodrigo. John

Nov. 1, 2025

Re: dillo plugin patches

by Rodrigo Arias

Hi, I added an exception for your email to the list. Following replies should get archived. On Fri, Oct 31, 2025 at 11:34:04AM -0400, John McCue wrote: >Hi Rodrigo, > >Attached are these 3 patches, the third one is >a very minor one for the gemini plugin's Makefile. Thanks for the patches. >1. io.txt -- A patch to io.c to avoid a compile error > on OpenBSD. This is based upon the email I responded to > earlier today. > >2. dpi.txt -- Corrects an odd issue on OpenBSD with the > gopher plugin. Access a gopher hole works fine on first > try, accessing a 2nd hole does nothing, no data is > presented. Selecting the "Stop" button in dillo works to > stop the attempted load. My wild guess is one of the > casts fixed the issue. I cannot reproduce this, with or without the patch. Tested in order: - gopher://gopher.quux.org:70/1/ - gopher://gopher.floodgap.com/ If you can reliably reproduce this, you could dump the backtrace while is "doing nothing" in case it got stuck in some network operation. >3. gemini_mk.txt -- a simple change to the gemini plugin's > Makefile. It allows the gemini plugin to 'compile' on > NetBSD. NetBSD installs packages in /usr/pkg. > >As mentioned in the last email, I will be happy to test >on OpenBSD and NetBSD. > >Thanks >John >diff --git a/dpi.c b/dpi.c >index 7b38800..52547f8 100644 >--- a/dpi.c >+++ b/dpi.c >@@ -7,7 +7,7 @@ > #include "io.h" > > static void check_auth() { >- char buf[30]; >+ char buf[31]; > int rc; > char key[4], local_key[4]; > char keys[128]; >@@ -16,16 +16,16 @@ static void check_auth() { > rc = read_all(STDIN_FILENO, buf, 29); > if (rc < 0) err(1, "read auth"); > buf[30] = '\0'; >- rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); >+ rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) key); The address of key may not be aligned to the size of a word. Some architectures will cause an invalid access trying to write an int to a non-aligned address. A better solution is to declare key as an unsigned int. I applied your fixes and then changed the key variables. > if (rc < 0) err(1, "auth: %.*s", 29, buf); > if (rc < 1) errx(1, "auth: %.*s", 29, buf); > home = getenv("HOME"); > if (!home) home = "."; > sz = read_file(keys, sizeof(keys), "%s/.dillo/dpid_comm_keys", home); > if (sz < 0) err(1, "read dillo comm keys"); >- rc = sscanf(keys, "%*d %4x' '>", local_key); >- if (rc < 0) err(1, "comm key: %.*s", sz, keys); >- if (rc < 1) errx(1, "comm key: %.*s", sz, keys); >+ rc = sscanf(keys, "%*d %4x' '>", (unsigned int *) local_key); >+ if (rc < 0) err(1, "comm key: %.*s", (int) sz, keys); >+ if (rc < 1) errx(1, "comm key: %.*s", (int) sz, keys); > if (memcmp(key, local_key, 4)) errx(1, "wrong dillo key"); > } > >@@ -38,7 +38,7 @@ static void get_url(char *url_buf, size_t url_len) { > rc = read_all(STDIN_FILENO, buf, sizeof(buf)); > if (rc < 0) err(1, "read open_url"); > if (strncmp(buf, "<cmd='open_url' url='", 21)) { >- err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); >+ err(1, "bad open_url cmd: %.*s", (int) sizeof(buf), buf); > } > len = url_len; > rc = read_some(STDIN_FILENO, url_buf, &len); >@@ -48,7 +48,7 @@ static void get_url(char *url_buf, size_t url_len) { > if (url_buf[i] == '\'' && url_buf[i+1] == ' ') break; > } > if (i > len-3 || strncmp(url_buf + i, "' '>", 4)) { >- err(1, "bad url end: %.*s", len, url_buf); >+ err(1, "bad url end: %.*s", (int) len, url_buf); > } > url_buf[i] = '\0'; > } >diff --git a/Makefile b/Makefile >index 1ff7047..e41e173 100644 >--- a/Makefile >+++ b/Makefile >@@ -13,6 +13,7 @@ $(DPIDRC): > mkdir -p $(DPI_DIR) > if [ -f /etc/dillo/dpidrc ]; then cp /etc/dillo/dpidrc $@; \ > elif [ -f /usr/local/etc/dillo/dpidrc ]; then cp /usr/local/etc/dillo/dpidrc $@; \ >+ elif [ -f /usr/pkg/etc/dillo/dpidrc ]; then cp /usr/pkg/etc/dillo/dpidrc $@; \ > else echo "Can't find dpidrc, is dillo installed?"; false; fi This is not in our upstream, but I would rather avoid having each possible path here. I added a DILLO_PREFIX variable, empty by default. So you can use `make install DILLO_PREFIX=/usr/pkg` to find dpidrc in your system. By default it only looks at /etc/dillo/dpidrc. > install-proto: $(DPIDRC) >diff --git a/io.c b/io.c >index 615f346..f437c2e 100644 >--- a/io.c >+++ b/io.c >@@ -7,6 +7,7 @@ > #include <fcntl.h> > #include <netdb.h> > #include <netinet/in.h> >+#include <sys/socket.h> Applied. > > #include "io.h" > I fixed several other problems and set the C standard to C99 and enabled POSIX 2001 by default in CFLAGS. I also performed the build with gcc and clang on Linux with -Werror -Wall -Wextra -pedantic as well as with -fsanitize=address to see if I catch something while running the plugin. Nothing so far. I pushed it here (we are moving away from GitHub): https://git.dillo-browser.org/plugins/gopher/log/?h=fix-bsd Let me know if you encounter problems building it on any BSD. Thanks!, Rodrigo.

Oct. 31, 2025

Re: FWD - dillo gopher plugin issue (reddit)

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I don't have a machine with OpenBSD at hand, can you test if the build > succeeds using the current master code in OpenBSD with these CFLAGS? > It does on Linux: > > % git > clone https://git.dillo-browser.org/plugins/gopher && cd gopher % make CC=clang CFLAGS= > "-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" $ make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c io.c io.c:84:20: error: use of undeclared identifier 'AF_UNSPEC' 84 | hints.ai_family = AF_UNSPEC; | ^ io.c:95:8: warning: call to undeclared function 'socket'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 95 | fd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); | ^ io.c:97:7: warning: call to undeclared function 'connect'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 97 | if (connect(fd, rp->ai_addr, rp->ai_addrlen) == 0) break; | ^ 2 warnings and 1 error generated. > There are many warnings that should be fixed (as below), but the > current includes should work otherwise. If not, does adding the extra > > + #include <sys/socket.h> > > line solves it? Looks better, now we get this: $ make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c io.c clang -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -I/usr/local/include -I/usr/X11R6/include -c dpi.c dpi.c:19:47: warning: format specifies type 'unsigned int *' but the argument has type 'char *' [-Wformat] 19 | rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); | ~~~ ^~~ | %3s dpi.c:26:35: warning: format specifies type 'unsigned int *' but the argument has type 'char *' [-Wformat] 26 | rc = sscanf(keys, "%*d %4x' '>", local_key); | ~~~ ^~~~~~~~~ | %3s dpi.c:27:34: warning: field precision should have type 'int', but argument has type 'ssize_t' (aka 'long') [-Wformat] 27 | if (rc < 0) err(1, "comm key: %.*s", sz, keys); | ~~^~ ~~ dpi.c:28:35: warning: field precision should have type 'int', but argument has type 'ssize_t' (aka 'long') [-Wformat] 28 | if (rc < 1) errx(1, "comm key: %.*s", sz, keys); | ~~^~ ~~ dpi.c:18:2: warning: array index 30 is past the end of the array (that has type 'char[30]') [-Warray-bounds] 18 | buf[30] = '\0'; | ^ ~~ dpi.c:10:2: note: array 'buf' declared here 10 | char buf[30]; | ^ dpi.c:41:31: warning: field precision should have type 'int', but argument has type 'unsigned long' [-Wformat] 41 | err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); | ~~^~ ~~~~~~~~~~~ dpi.c:51:26: warning: field precision should have type 'int', but argument has type 'size_t' (aka 'unsigned long') [-Wformat] 51 | err(1, "bad url end: %.*s", len, url_buf); | ~~^~ ~~~ 7 warnings generated. Regards, Alex

Oct. 31, 2025

Re: FWD - dillo gopher plugin issue (reddit)

by Rodrigo Arias

Hi Alex, John, On Thu, Oct 30, 2025 at 12:05:51PM +0000, a1ex(a)dismail.de wrote: > Hi, > > I saw this issue on Reddit today pertaining to the Gopher plugin not > working correctly on OpenBSD. It includes a fix (I haven't tested it): > > https://eddrit.com/r/openbsd/comments/1oj3ljg/dillo_gopher_plugin_issue_wor… Thanks, I saw it as well. Nice frontend btw. > Date: Thu, 30 Oct 2025 11:10:21 -0400 > From: John McCue <jmccue(a)jmcunx.com> > To: a1ex(a)dismail.de > Cc: dillo-dev(a)mailman3.com > Subject: Re: Dillo gopher plugin on OpenBSD issue > > > [...] > > Somehow I missed it seeing there was a list. I found another > issues with the gopher plugin on OpenBSD. > > The issue I am testing is with dpi.c. On OpenBSD, it has to > do with how clang works on OpenBSD. The diffs are below. I can reproduce many issues on Linux with `CC=clang make`. I'm getting a few more warnings that should be easy to solve. > So far, with the changes to io.c and dpi.c, the plugin > works fine on both OpenBSD and NetBSD. > > diff --git a/io.c b/io.c > index 615f346..a10a0b3 100644 > --- a/io.c > +++ b/io.c > @@ -1,3 +1,4 @@ > +#include <sys/param.h> > #include <string.h> > #include <errno.h> > #include <unistd.h> > @@ -8,6 +9,12 @@ > #include <netdb.h> > #include <netinet/in.h> > > +#ifdef OpenBSD I don't think we need to handle OpenBSD differently, but instead make the code portable by targeting C and POSIX standards. > +#include <sys/socket.h> This is always needed as we use socket(), but it should not be needed here as it would be included via <netinet/in.h>, from netinet_in.h(0P): > Inclusion of the <netinet/in.h> header may also make visible all > symbols from <inttypes.h> and <sys/socket.h> Not sure if OpenBSD follows this, otherwise can simply include it unconditionally. > +#include <net/if.h> > +#include <net/route.h> Needed? > +#endif > + Building with: % make CC=clang CFLAGS="-std=c11 -Wall -pedantic" Already reveals many problems. We can probably lower the C standard to C99. I don't have a machine with OpenBSD at hand, can you test if the build succeeds using the current master code in OpenBSD with these CFLAGS? It does on Linux: % git clone https://git.dillo-browser.org/plugins/gopher && cd gopher % make CC=clang CFLAGS="-Wall -std=c99 -D_POSIX_C_SOURCE=200112L" There are many warnings that should be fixed (as below), but the current includes should work otherwise. If not, does adding the extra + #include <sys/socket.h> line solves it? > #include "io.h" > > int read_all(int fd, unsigned char *buf, size_t len) { > > > diff --git a/dpi.c b/dpi.c > index 7b38800..52547f8 100644 > --- a/dpi.c > +++ b/dpi.c > @@ -7,7 +7,7 @@ > #include "io.h" > > static void check_auth() { > - char buf[30]; > + char buf[31]; > int rc; > char key[4], local_key[4]; > char keys[128]; > @@ -16,16 +16,16 @@ static void check_auth() { > rc = read_all(STDIN_FILENO, buf, 29); > if (rc < 0) err(1, "read auth"); > buf[30] = '\0'; > - rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); > + rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) > key); if (rc < 0) err(1, "auth: %.*s", 29, buf); The patch is badly mangled, better use `git send-patch` or attach it as a file. > if (rc < 1) errx(1, "auth: %.*s", 29, buf); > home = getenv("HOME"); > if (!home) home = "."; > sz = read_file(keys, sizeof(keys), > "%s/.dillo/dpid_comm_keys", home); if (sz < 0) err(1, "read dillo comm > keys"); > - rc = sscanf(keys, "%*d %4x' '>", local_key); > - if (rc < 0) err(1, "comm key: %.*s", sz, keys); > - if (rc < 1) errx(1, "comm key: %.*s", sz, keys); > + rc = sscanf(keys, "%*d %4x' '>", (unsigned int *) local_key); > + if (rc < 0) err(1, "comm key: %.*s", (int) sz, keys); > + if (rc < 1) errx(1, "comm key: %.*s", (int) sz, keys); > if (memcmp(key, local_key, 4)) errx(1, "wrong dillo key"); > } > > @@ -38,7 +38,7 @@ static void get_url(char *url_buf, size_t url_len) { > rc = read_all(STDIN_FILENO, buf, sizeof(buf)); > if (rc < 0) err(1, "read open_url"); > if (strncmp(buf, "<cmd='open_url' url='", 21)) { > - err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); > + err(1, "bad open_url cmd: %.*s", (int) sizeof(buf), > buf); } > len = url_len; > rc = read_some(STDIN_FILENO, url_buf, &len); > @@ -48,7 +48,7 @@ static void get_url(char *url_buf, size_t url_len) { > if (url_buf[i] == '\'' && url_buf[i+1] == ' ') break; > } > if (i > len-3 || strncmp(url_buf + i, "' '>", 4)) { > - err(1, "bad url end: %.*s", len, url_buf); > + err(1, "bad url end: %.*s", (int) len, url_buf); > } > url_buf[i] = '\0'; > } > Thanks!, Rodrigo.

Oct. 30, 2025

Fw: Dillo gopher plugin on OpenBSD issue

by a1ex＠dismail.de

Forwarding to dillo-dev, since the list only accepts mails from subscribers. Begin forwarded message: Date: Thu, 30 Oct 2025 11:10:21 -0400 From: John McCue <jmccue(a)jmcunx.com> To: a1ex(a)dismail.de Cc: dillo-dev(a)mailman3.com Subject: Re: Dillo gopher plugin on OpenBSD issue [...] Somehow I missed it seeing there was a list. I found another issues with the gopher plugin on OpenBSD. The issue I am testing is with dpi.c. On OpenBSD, it has to do with how clang works on OpenBSD. The diffs are below. So far, with the changes to io.c and dpi.c, the plugin works fine on both OpenBSD and NetBSD. diff --git a/io.c b/io.c index 615f346..a10a0b3 100644 --- a/io.c +++ b/io.c @@ -1,3 +1,4 @@ +#include <sys/param.h> #include <string.h> #include <errno.h> #include <unistd.h> @@ -8,6 +9,12 @@ #include <netdb.h> #include <netinet/in.h> +#ifdef OpenBSD +#include <sys/socket.h> +#include <net/if.h> +#include <net/route.h> +#endif + #include "io.h" int read_all(int fd, unsigned char *buf, size_t len) { diff --git a/dpi.c b/dpi.c index 7b38800..52547f8 100644 --- a/dpi.c +++ b/dpi.c @@ -7,7 +7,7 @@ #include "io.h" static void check_auth() { - char buf[30]; + char buf[31]; int rc; char key[4], local_key[4]; char keys[128]; @@ -16,16 +16,16 @@ static void check_auth() { rc = read_all(STDIN_FILENO, buf, 29); if (rc < 0) err(1, "read auth"); buf[30] = '\0'; - rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", key); + rc = sscanf(buf, "<cmd='auth' msg='%4x' '>", (unsigned int *) key); if (rc < 0) err(1, "auth: %.*s", 29, buf); if (rc < 1) errx(1, "auth: %.*s", 29, buf); home = getenv("HOME"); if (!home) home = "."; sz = read_file(keys, sizeof(keys), "%s/.dillo/dpid_comm_keys", home); if (sz < 0) err(1, "read dillo comm keys"); - rc = sscanf(keys, "%*d %4x' '>", local_key); - if (rc < 0) err(1, "comm key: %.*s", sz, keys); - if (rc < 1) errx(1, "comm key: %.*s", sz, keys); + rc = sscanf(keys, "%*d %4x' '>", (unsigned int *) local_key); + if (rc < 0) err(1, "comm key: %.*s", (int) sz, keys); + if (rc < 1) errx(1, "comm key: %.*s", (int) sz, keys); if (memcmp(key, local_key, 4)) errx(1, "wrong dillo key"); } @@ -38,7 +38,7 @@ static void get_url(char *url_buf, size_t url_len) { rc = read_all(STDIN_FILENO, buf, sizeof(buf)); if (rc < 0) err(1, "read open_url"); if (strncmp(buf, "<cmd='open_url' url='", 21)) { - err(1, "bad open_url cmd: %.*s", sizeof(buf), buf); + err(1, "bad open_url cmd: %.*s", (int) sizeof(buf), buf); } len = url_len; rc = read_some(STDIN_FILENO, url_buf, &len); @@ -48,7 +48,7 @@ static void get_url(char *url_buf, size_t url_len) { if (url_buf[i] == '\'' && url_buf[i+1] == ' ') break; } if (i > len-3 || strncmp(url_buf + i, "' '>", 4)) { - err(1, "bad url end: %.*s", len, url_buf); + err(1, "bad url end: %.*s", (int) len, url_buf); } url_buf[i] = '\0'; }

Oct. 30, 2025

FWD - dillo gopher plugin issue (reddit)

by a1ex＠dismail.de

Hi, I saw this issue on Reddit today pertaining to the Gopher plugin not working correctly on OpenBSD. It includes a fix (I haven't tested it): https://eddrit.com/r/openbsd/comments/1oj3ljg/dillo_gopher_plugin_issue_wor… Regards, Alex

Oct. 30, 2025

Re: New website dillo-browser.org

by Rodrigo Arias

Hi, > There may be something we can tune in cgit or maybe in the git > repository to make it faster. I'll need to dive a bit more on how git > works under the hood to fix it. This seems to be caused by cgit not implementing the git protocol v2, which allows downloading only the needed objects. There is a patch available, but never got merged. I might try to add it to our cgit or configure the http server to send git requests directly to a git server. Tracked here: https://bug.dillo-browser.org/504/ Best, Rodrigo.

Oct. 10, 2025

Re: New website dillo-browser.org

by Kevin Koster

Rodrigo Arias wrote: > On Mon, Sep 29, 2025 at 09:22:13AM +1000, Kevin Koster wrote: >> This command works to change the Git repo URL if you've already >> cloned from GitHub: >> >> git remote set-url origin https://git.dillo-browser.org/dillo >> >> It did take quite a while to respond to "git pull" after that. > > I'm not sure if there is a problem on our end or is it expected to take > long. Here is what I see if I clone the repo from our cgit and github in > my old netbook: Same here, the total clone time seems similar to GitHub. "git pull" is now responding much quicker too: $ time git pull Fetching objects: 536, done. From https://git.dillo-browser.org/dillo * [new branch] ci -> origin/ci * [new branch] mouse-back-forward -> origin/mouse-back-forward Already up to date. real 0m 4.76s user 0m 0.20s sys 0m 0.26s But there were changes pulled in last time whereas now it's "already up to date". I know last time I was sure Git had hung and started writing a post warning about that, checking back just in case, and Git eventually finished while I was writing. At least a minute or two for an operation that's usually fairly immediate. It _could_ have coincidentally been a network issue or a problem reading/writing storage on my end (actually eMMC flash) causing the delay I suppose. Anyway so long as it works it's not really a problem for me. > Bonus: WIP bug tracker https://bug.dillo-browser.org/ Excellent! Although apparantly Dillo can't find a ← character in the font I'm using (which is probably my problem, I like lean font packages).

Oct. 5, 2025

Re: New website dillo-browser.org

by Rodrigo Arias

Hi, On Mon, Oct 06, 2025 at 09:08:49AM +1000, Kevin Koster wrote: > I know last time I was sure Git had hung and started writing a post > warning about that, checking back just in case, and Git eventually > finished while I was writing. At least a minute or two for an > operation that's usually fairly immediate. I think the problem is that it is downloading a single big 77MiB git object (pack) with all the contents and somehow this causes git to not print anything until the download finishes. On the GitHub side, it downloads multiple files and knows how many there are. I'm not sure what is causing this. If I use HTTP, this is what I see with -vv: % git clone -vv https://github.com/dillo-browser/dillo Cloning into 'dillo'... POST git-upload-pack (181 bytes) want 29a46a2da7e9350a1252e30aea3c8294097f63a4 (HEAD) want e14906ab1407f800e3a06d57c838a2887cf65a2f (refs/heads/3.0.5) ... want e637d2158a9ef1cb82273f54d9d68d0b05dbb6f6 (refs/tags/v3.2.0) want 5338882730f1098becb199fc629e0adf22e94461 (refs/tags/v3.2.0-rc1) POST git-upload-pack (gzip 1808 to 934 bytes) remote: Enumerating objects: 27353, done. remote: Counting objects: 100% (2266/2266), done. remote: Compressing objects: 100% (497/497), done. ^Cceiving objects: 1% (274/27353) But our server doesn't do that via HTTPS: % git clone -vv https://git.dillo-browser.org/dillo Cloning into 'dillo'... got f57e4fe95b2c0cfd2e966bcebdd6d21fd26e71bb walk f57e4fe95b2c0cfd2e966bcebdd6d21fd26e71bb Getting alternates list for https://git.dillo-browser.org/dillo got f48288b62f7e4d1e17cf06796d8738bd01de3746 Getting pack list for https://git.dillo-browser.org/dillo Getting index for pack dc484618e815fff3daa3971cb11b4b9457361592 got d5b3971fbd3b685d458d3e07061cfc5a01c31db7 got 8cd2d04fc6ed054b999744cedc0b29141d8fa747 got cb7820ed982df6e6dcac16ddd92eed8b8667f0d1 got 3a9d001498ca0c211431fd08bfce014c20f6a8f1 got e637d2158a9ef1cb82273f54d9d68d0b05dbb6f6 got db482d4c2b517270c7e1da03a090e6e293893139 got 5338882730f1098becb199fc629e0adf22e94461 Getting pack dc484618e815fff3daa3971cb11b4b9457361592 which contains 29a46a2da7e9350a1252e30aea3c8294097f63a4 ^here takes a lot of time However, via ssh I get immediate feedback: % git clone -vv XXXX@dillo-browser.org:dillo Cloning into 'dillo'... Server version is git/2.47.3 Server supports shallow Server supports multi_ack_detailed Server supports side-band-64k Server supports thin-pack Server supports no-progress Server supports include-tag Server supports ofs-delta Server supports deepen-since Server supports deepen-not Server supports deepen-relative want f57e4fe95b2c0cfd2e966bcebdd6d21fd26e71bb (HEAD) want f57e4fe95b2c0cfd2e966bcebdd6d21fd26e71bb (refs/heads/ci) want 29a46a2da7e9350a1252e30aea3c8294097f63a4 (refs/heads/master) want f48288b62f7e4d1e17cf06796d8738bd01de3746 (refs/heads/mouse-back-forward) want adb3d5c87fae7196dbae6c35828434cdcd6227a4 (refs/tags/2.1-noCss) want ce8e972a10c9340312f21511de053242dad3f5db (refs/tags/release-2_0) ... want e637d2158a9ef1cb82273f54d9d68d0b05dbb6f6 (refs/tags/v3.2.0) want 5338882730f1098becb199fc629e0adf22e94461 (refs/tags/v3.2.0-rc1) done remote: Enumerating objects: 27300, done. remote: Counting objects: 100% (27300/27300), done. remote: Compressing objects: 100% (6518/6518), done. ^Cceiving objects: 11% (3003/27300) There may be something we can tune in cgit or maybe in the git repository to make it faster. I'll need to dive a bit more on how git works under the hood to fix it. Best, Rodrigo.

Oct. 5, 2025

Re: New website dillo-browser.org

by Rodrigo Arias

Hi Kevin, On Mon, Sep 29, 2025 at 09:22:13AM +1000, Kevin Koster wrote: > Rodrigo Arias wrote: > > As well as a new git web frontend (cgit) that works well from Dillo > > (after some CSS fixes), so we can link to a given commit or source file: > > > > https://git.dillo-browser.org/ > > This command works to change the Git repo URL if you've already > cloned from GitHub: > > git remote set-url origin https://git.dillo-browser.org/dillo > > It did take quite a while to respond to "git pull" after that. I'm not sure if there is a problem on our end or is it expected to take long. Here is what I see if I clone the repo from our cgit and github in my old netbook: % time git clone https://git.dillo-browser.org/dillo/ /tmp/1 Cloning into '/tmp/1'... Fetching objects: 27292, done. git clone https://git.dillo-browser.org/dillo/ /tmp/1 29.28s user 4.30s system 104% cpu 32.080 total % time git clone https://github.com/dillo-browser/dillo /tmp/2 Cloning into '/tmp/2'... remote: Enumerating objects: 27353, done. remote: Counting objects: 100% (2266/2266), done. remote: Compressing objects: 100% (497/497), done. remote: Total 27353 (delta 2067), reused 1769 (delta 1769), pack-reused 25087 (from 3) Receiving objects: 100% (27353/27353), 83.77 MiB | 5.37 MiB/s, done. Resolving deltas: 100% (19766/19766), done. git clone https://github.com/dillo-browser/dillo /tmp/2 34.44s user 9.13s system 163% cpu 26.682 total In the cgit case, it takes a while to output the "Fetching objects: 27292, done". > > I'm also working on migrating the issues away from GitHub, so we can > > host them ourselves. Same for the CI infrastructure. > > Great to hear. "Not hosted on GitHub" is a rare feature for Web > browsers now and I'm glad Dillo is reimplementing it. :) I'm still thinking what to do with the CI runner, as before we used to build Dillo with Mac OS and Cygwin in Windows, but now I only have Linux/BSD machines available. I would imagine that we can lower the support level in those platforms to "was known to work", but I would like to avoid that. Not sure if someone has a better suggestion. Bonus: WIP bug tracker https://bug.dillo-browser.org/ Best, Rodrigo.

Oct. 1, 2025

Re: New website dillo-browser.org

by Kevin Koster

Rodrigo Arias wrote: > As well as a new git web frontend (cgit) that works well from Dillo > (after some CSS fixes), so we can link to a given commit or source file: > > https://git.dillo-browser.org/ This command works to change the Git repo URL if you've already cloned from GitHub: git remote set-url origin https://git.dillo-browser.org/dillo It did take quite a while to respond to "git pull" after that. > I'm also working on migrating the issues away from GitHub, so we can > host them ourselves. Same for the CI infrastructure. Great to hear. "Not hosted on GitHub" is a rare feature for Web browsers now and I'm glad Dillo is reimplementing it. :)

Sept. 28, 2025

Re: New website dillo-browser.org

by a1ex＠dismail.de

Bravo Rodrigo, it looks great! Long live Dillo! Cheers, Alex Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > I just wanted to announce that we now have a new website: > > https://dillo-browser.org/ > > As well as a new git web frontend (cgit) that works well from Dillo > (after some CSS fixes), so we can link to a given commit or source > file: > > https://git.dillo-browser.org/ > > I'm also working on migrating the issues away from GitHub, so we can > host them ourselves. Same for the CI infrastructure. > > The server is located on EU soil and the costs are fully covered by > the donations to the project. Thanks to all donors that made it > possible! > > I hope we can manage to keep it working for some more years, but I > still plan to make some backups in other forges so we don't end up > with the same single point of failure problem of the old server. > > Best, > Rodrigo.

Sept. 27, 2025

Re: New website dillo-browser.org

by Xavier Del Campo Romero

Hi, Congratulations for the new website! Leaving GitHub was a great idea, indeed. Thanks to all donors and developers who made it possible! Best regards, Xavi On 27 September 2025 16:03:40 CEST, Rodrigo Arias <rodarima(a)gmail.com> wrote: >Hi, > >I just wanted to announce that we now have a new website: > >https://dillo-browser.org/ > >As well as a new git web frontend (cgit) that works well from Dillo >(after some CSS fixes), so we can link to a given commit or source file: > >https://git.dillo-browser.org/ > >I'm also working on migrating the issues away from GitHub, so we can >host them ourselves. Same for the CI infrastructure. > >The server is located on EU soil and the costs are fully covered by the >donations to the project. Thanks to all donors that made it possible! > >I hope we can manage to keep it working for some more years, but I still >plan to make some backups in other forges so we don't end up with the >same single point of failure problem of the old server. > >Best, >Rodrigo. >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Sept. 27, 2025

Jump to page: