Yannick PLASSIARD <[EMAIL PROTECTED]> 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 > 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 ?
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 link. 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? -- Jonas Fonseca _______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
