[elinks-dev] New HID support for ELinks
fonseca at diku.dk
Tue Mar 28 02:51:28 PST 2006
Yannick PLASSIARD <yan at mistigri.org> wrote Mon, Mar 27, 2006:
> I took time investigating on the Rlinks's structures and saw a "struct
> document" in src/document/document.h, which stores the entire
> This structure seems to be a good place to get all document specs and
> content. I have several questions about that: I saw a 'struct line *'
> in it, which, I guess, correspond to each line of the document. My
> question is, does a line include all text, even if at the middle of
> it, there is a link ?
Yes, a line include all text even link text. It also contains stuff like
table border characters and form "underlays" such as sequences of
underscore characters for input form fields. Mostly to point out that
there are probably stuff you don't want to render on you special device
or which needs special handling.
> Example : Lets suppose a line "This <is> a text" and the '<is>' is a
> link. How it would be in a struct line, and how a struct link will be
> set appropriately ?
Basically a struct line does not know anything about links. The only
thing there to hint at links might be character attributes such as
underlining, different color, but that of course depends on whether the
document specified that links should have special attributes to
stand-out. Note, if you need to know if something is a link it would be
trivial to add a new special link character attribute to encode this
information in struct line.
So how do you get struct link? Links are really optimized to be accessed
in sequence like when you push the down key it will jump to the "next"
link. It is of course possible to derive a link based on a position in
the document. This is currently used by the mouse code. The function for
doing this is get_link_at_coordinates().
One thing to be aware of here is that there are two "metrics": positions
on the whole screen and positions on the document view (or canvas). This
particular function takes document screen positions and translates them
to document view coordinates which can then be used to search for a
I hope that sort of answers your question.
> Secnnd, my implementation "only" consists of reformatting output text.
> For example, instead of "colorized links" I would put "<Ln>text<ln>"
> insdead. I mean I would rewrite a lowlevel "pseudo terminal driver",
> to be transparent with tab handling for example (don't care about
> dialogboxes for now).
> But I'm quite comfuse with the way the 'terminal driver' gets events
> from the document, for example an Autoreload or something like that,
> and also about the module structure and working.
> Can you explain me how it work and how I should use it correctly ?
I am not entirely sure if our idea of 'terminal driver' are the same.
The current terminal driver is quite dump when it comes to drawing
document text. You have this draw_line() which basically gets the
content of struct line and puts them to the screen buffer. This
is however a bit too lowlevel for what you want. You probably want
to at a draw_brltty_line() or something but do some 'preformatting'
in the viewer, for example in viewer/text/draw.c, where you examine
the line you want to output to BRLTTY and enhance it.
I am not complete sure that I understand you correctly when you talk
about "getting event from the document". Autoreload or document refresh
are handled on a level higher than the terminal driver. When a tab wants
to render a document the session code (tabs and sessions are deeply tied
together) checks if the HTML renderer put a struct document_refresh in
struct document. If it did it starts a timer with the interval recorded
in the document refresh struct and this will then reload or jump to
another page based on the recorded URL when the timer fires. I don't
think your you need or want to worry about this.
Maybe if you can give some more specific example and a description of
why you think it is a problem for your terminal driver.
The module structure was mostly invented to move the hooks for subsystem
startup and shutdown away from init() and terminate_all_subsystems() in
main/main.c. Modules are hierarchic, so for example there is a mime
module which has submodules such as mailcap and mimetypes. Oh, and then
modules makes it easier to print the string about what features was
compiled into an ELinks version. Later support for defining options and
event hooks related to a module was added. There is really not more to
it. Does that answer you question?
More information about the elinks-dev