52 lines
1.8 KiB
Markdown
52 lines
1.8 KiB
Markdown
|
Architecture
|
||
|
============
|
||
|
|
||
|
This document is for people who want to get an overview of the Bebop code and
|
||
|
the way things work. These are high-level views, more details are given in the
|
||
|
respective modules' docstrings.
|
||
|
|
||
|
|
||
|
|
||
|
Events
|
||
|
------
|
||
|
|
||
|
There are no event loop dispatching actions asynchronously, everything runs in a
|
||
|
single thread. The UI waits for user input and reacts on them.
|
||
|
|
||
|
In the future we may decouple the UI from the core browser to allow background
|
||
|
downloads and streaming content.
|
||
|
|
||
|
|
||
|
|
||
|
Rendering
|
||
|
---------
|
||
|
|
||
|
A core element of Bebop is what I call "metalines", which are lines of text as
|
||
|
they are rendered on screen, along with specific line metadata. Metalines are
|
||
|
rendered directly on screen, so they are not wrapped, cut or whatever: they
|
||
|
already represent formatted text as it will be shown. They carry information
|
||
|
such as line type (i.e. is this line part of a link, a title, etc), and more
|
||
|
specific data such as target URLs for link lines.
|
||
|
|
||
|
Rendering from the server response to showing content in the curses UI takes
|
||
|
several steps:
|
||
|
|
||
|
1. Parse the response from the server. If it's successful and a text MIME type
|
||
|
is provided, use it to parse the response content.
|
||
|
2. Response parsing can directly produce metalines (e.g. from `text/plain`) or
|
||
|
have intermediate parsing steps: a `text/gemini` document is first parsed
|
||
|
into a list of gemtext "elements" (paragraphs, links, etc), and converting
|
||
|
those elements into metalines happen in a following step. This lets Bebop
|
||
|
separate gemtext semantics from the way it is rendered, thus using the
|
||
|
desired wrapping and margins.
|
||
|
3. Metalines are rendered on the screen, with the colors and attributes
|
||
|
matching the line type.
|
||
|
|
||
|
|
||
|
|
||
|
Plugins
|
||
|
-------
|
||
|
|
||
|
The plugin interface is improved only when there is demand for something; for
|
||
|
now it only supports plugins that can handle new schemes.
|