Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.infosystems > #117 > unrolled thread

Dillo (the browser) is back

Started byyeti <yeti@tilde.institute>
First post2024-04-02 10:44 +0042
Last post2024-04-02 20:33 +0042
Articles 4 — 3 participants

Back to article view | Back to comp.infosystems


Contents

  Dillo (the browser) is back yeti <yeti@tilde.institute> - 2024-04-02 10:44 +0042
    Re: Dillo (the browser) is back Matto Fransen <mattof@sdf.org> - 2024-04-02 12:41 +0200
    Re: Dillo (the browser) is back news@zzo38computer.org.invalid - 2024-04-02 12:23 -0700
      Re: Dillo (the browser) is back yeti <yeti@tilde.institute> - 2024-04-02 20:33 +0042

#117 — Dillo (the browser) is back

Fromyeti <yeti@tilde.institute>
Date2024-04-02 10:44 +0042
SubjectDillo (the browser) is back
Message-ID<875xx084lm.fsf@tilde.institute>
Dillo (the browser) is back.
============================

Links.
------

Welcome to the Dillo Website
<https://dillo-browser.github.io/>


Some of the backstory.
----------------------

What happened to dillo.org?
<https://dillo-browser.github.io/dillo.org.html>


Why does that matter here?
--------------------------

Dillo is not just another implementation of today's wide spread broken
by design single protocol network file viewers.  Out of the box Dillo
supports HTTP, HTTPS and FTP.  Optional plugins for lots of other
protocols exist.

Some nearby plugins:

<https://dillo-browser.github.io/#plugins>
<https://github.com/dillo-browser/dillo/issues/50>

Additionally writing plugins is easy.  I could nail together a NEX
plugin in a short time and I'm planning to play with more ideas for
plugins.

Being an opponent of single protocol browsers even in the smallnet
context and favouring a diverse net instead, Dillo now has a place on my
favourite multi protocol browsers list, which already includes Elinks,
Emacs and W3m.


Screenshots or it didn't happen!
--------------------------------

I cannot directly attach them here and I do not maintain a permanently
stable static web site, so every published link sure will break soon.

Currently <https://yeti.tilde.institute/dillo-screenshots/> has some
images but may change soon.

Maybe I'll dare to let <https://web.archive.org> conserve them?


Happy End.
----------

.

-- 
I do not bite, I just want to play.

[toc] | [next] | [standalone]


#118

FromMatto Fransen <mattof@sdf.org>
Date2024-04-02 12:41 +0200
Message-ID<86zfucf3mk.fsf@x201.tradesystem.nl>
In reply to#117
On  2 April 2024 10:44 yeti, wrote:

> Dillo (the browser) is back.
> 

Wonderful!

Best regards,

Matto

[toc] | [prev] | [next] | [standalone]


#126

Fromnews@zzo38computer.org.invalid
Date2024-04-02 12:23 -0700
Message-ID<1712085318.bystand@zzo38computer.org>
In reply to#117
yeti <yeti@tilde.institute> wrote:
> 
> <https://dillo-browser.github.io/#plugins>
> <https://github.com/dillo-browser/dillo/issues/50>
> 
> Additionally writing plugins is easy.  I could nail together a NEX
> plugin in a short time and I'm planning to play with more ideas for
> plugins.

The plugins though are plugins by schemes, and only implement the file
formats as a part of the schemes implementations.

Is it possible to implement file format plugins independently from
scheme plugins? It seem to me that it would be better to do so; e.g.
a Gemini protocol plugin can access filesby Gemini protocol and tell
the browser whatever file format it is, e.g. "text/gemini"; another
file can interpret the "text/gemini" file format regardless of the
protocol (so it can also work with local files, Spartan, etc).

And then, for some file formats and protocols might be useful for some
other kind of features, which might be separate from these plugins, e.g.
table of contents menu is useful with many file formats, including HTML,
Gemini, Scorpion, man pages, Wikipedia, etc. (For implementing Scorpion,
also would be useful to implement mixed character codes, including TRON
character code.)

-- 
Don't laugh at the moon when it is day time in France.

[toc] | [prev] | [next] | [standalone]


#128

Fromyeti <yeti@tilde.institute>
Date2024-04-02 20:33 +0042
Message-ID<87o7ar7dbc.fsf@tilde.institute>
In reply to#126
news@zzo38computer.org.invalid writes:

> yeti <yeti@tilde.institute> wrote:
>> 
>> <https://dillo-browser.github.io/#plugins>
>> <https://github.com/dillo-browser/dillo/issues/50>
>> 
>> Additionally writing plugins is easy.  I could nail together a NEX
>> plugin in a short time and I'm planning to play with more ideas for
>> plugins.
>
> The plugins though are plugins by schemes, and only implement the file
> formats as a part of the schemes implementations.

Based on my exchange via Mastodon, I have the impression that they know
that thinking about file format plugins will be useful.  Maybe the
browser currently only renders text/html and text/plain.  Enough to do a
lot but sure far from universal.  Jump into their chat or ask via GitHub
issue or in their mailinglist?  I'm still hoping that they make their ML
accessible via NNTP.

<ircs://irc.libera.chat/#dillo>

The Gopher- and Nex-plugins happily let the browser handle everything
they cannot transform to HTML on their own.  Additional to the plugins'
"native" text formats I only tested HTML and plain text with both of
them.

> (For implementing Scorpion, also would be useful to implement mixed
> character codes, including TRON character code.)

I've near to no idea about TRON.

But yes: I'd like to see "fetchers" and "renderers" as separate plugins
too and it might help to let them know what you think about this too.

-- 
I do not bite, I just want to play.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.infosystems


csiph-web