[elinks-dev] New HID support for ELinks
yan at mistigri.org
Mon Mar 27 02:03:43 PST 2006
First, I would like to thank you for your long and complete answer.
I took time investigating on the Rlinks's structures and saw a "struct document" in src/document/document.h, which stores the entire document.
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 ?
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 ?
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 ?
On Fri, Mar 24, 2006 at 03:42:57PM +0100, Jonas Fonseca wrote:
> Yannick PLASSIARD <yan at mistigri.org> wrote Fri, Mar 24, 2006:
> > Hi there,
> > 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
> 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
> Jonas Fonseca
> elinks-dev mailing list
> elinks-dev at linuxfromscratch.org
More information about the elinks-dev