[elinks-dev] New HID support for ELinks

Jonas Fonseca fonseca at diku.dk
Fri Mar 24 06:42:57 PST 2006


Yannick PLASSIARD <yan at mistigri.org> wrote Fri, Mar 24, 2006:
> Hi there,

Hello,

> I'm new to this list, and I'm posting a message to know where should
> my ideas take place...

I will try to answer you questions ...

> The Elinks web browser is, as far as I know, the most complete
> browser, and my goal is to make it better accessible for blind users ,
> which use some specific hardware (Braille Displays, and Speech
> Synthetizers). We (blind users), use a software called BRLTTY
> (http://www.mielke.cc/brltty/), to navigate through the Linux console
> and this software exports an API called BrlAPI, which allows another
> application to write messages to the Braille display, and get Braille
> displays' key presses.
>
> So, I would like to write a new "driver" for ELinks, which would no
> longer use the screen/keyboard pair, but the BrlAPI interface to get
> IO operations. This would be an additionnal driver which would run at
> the same time as the screen/keybeard interface (indeed, a
> dual-viewing). 

Sounds interesting, but this will require a lot of work to integrate
with some parts of the ELinks code.

> Does anyone know where my code should take place into the ELinks
> architecture,

Most of the current terminal 'driver' code resides in src/terminal/.
However, the directory also contains more high level parts such as window and tab
handling. A short list with 'places' of interest:

 Handling of keyboard inputs happen in src/terminal/event.c and
 src/terminal/kbd.c, this is generally done by installing a handler
 for reading stuff emitted by the terminal emulator. Note however that
 interleaved with this is code for handling interlinking between ELinks
 instances.

 Updating of the terminal screen is in src/terminal/screen.c, stuff like
 erasing the screen and beeping. (don't know if that is relevant)

 Finally there is the general terminal interface in
 src/terminal/terminal.c, that controls redrawing, execution in
 subshells, and the life cycle of struct terminal.

> and can you also give me some issues about how to acces
> the Document Object-Model, after it is created bythe HTML parser (or
> other if it is FTP / SMB / ... protocol). 

The parser in src/document/html does not provide much of an object
model. It generally caches (or renderers) most of the page content
in a form that allows it to easily be drawn on the terminal screen using
draw_line. Among the meta-data that is available are:

 Link info such as title, URL, and position in the document, that is
 where in the document view to draw the link.

 Form info such as default value, where to post to and so on.

Getting access to a decent representation of the document after it has
been parsed is probably the biggest problem. I don't think there is much
point in decoding the information from the pre-renderered document
lines. So you end up having either the choice of trying to change the
parsing/rendering code (which is quite messy) to fit the view of the
document you want or you could (if you are brave) try to build on top of
the limited and work-in-progress DOM engine. Choosing the latter could
be quite interesting, but you will have to start almost from scratch
when it comes to HTML rendering and write code for building the
whole structure of document, links, and forms used by the ELinks viewer.

> And last, do dialogboxes functions are dependent of the driver, or are
> they global and send to the backend just a "draw me a line", "Place at
> 0,0, the text 'hello'" ... ?

The lowlevel part of the dialog code works like you describe, by calling
functions defined in the file src/terminal/draw.c such as draw_box
(colorize area on the screen) and draw_text (put a character string).
However, the dialog code has a nice object oriented structure that could
be extended to support what you want. For example there are functions
for handling mouse events, for handling keyboard event, and for
displaying the widgets.  The last one does the actual drawing to the
terminal screen and could be extended to output to brltty based on
information in the terminal struct which is referenced by the dialog
box.

-- 
Jonas Fonseca



More information about the elinks-dev mailing list