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