- Dillo-dev - lists.mailman3.com

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