Platform-specific UI affordances?
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-0... 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-c... 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'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.
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@mailman3.com To unsubscribe send an email to dillo-dev-leave@mailman3.com
Rodrigo Arias <rodarima@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
a1ex-J7K0XVabL0iELgA04lAiVw@public.gmane.org wrote:
Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w@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.
Hi, On Sun, Nov 09, 2025 at 08:45:23AM +1100, Kevin Koster wrote:
a1ex-J7K0XVabL0iELgA04lAiVw@public.gmane.org wrote:
Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w@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.
participants (5)
-
a1ex＠dismail.de -
Kevin Koster -
Rodrigo Arias -
Steve Landey -
steve＠stevelandey.com