Re: lynx-dev frame and table rendering (was: "display partial" implementation in 'links')

[rjp]

In message <address@hidden>, 
           Vlad Harchev writes:
>  As for possible layout of links inside frames in the future 'lynx', IMO we

My idea was to have a seperate curses panel for each frame.  Keeps the
displaying simple and requires only (relatively) minor modifications
to the existing display code.  Rendering them as a table, like w3m does
would probably be fine though.

>  As for rendering tables, I think inventing another representation of htext

I think the best thing we can do to make progress towards tables and
frames is to junk GridText completely and use something like a linked
list of screen objects which can be redrawn dynamically.  I've done 
some experimentation with this kind of thing already -- the housekeeping
is a pain, but the benefits are, IMO, worth it.  Things like colour-styles
become trivial to implement nicely, rather than the hacky kludge they
are at present.

Why does this make drawing tables easier?  Because it gives us a fake 
two pass parser.  While we're adding things to our list of display 
objects, we can be recording how wide each table cell is, how many
cells each row has, etc.  Then, when we come to draw them, we have
additional information that we can't have when we're sticking things
into GridText mid-parse as happens at present.  

The downside is that rendering the page becomes less efficient because
we're effectively creating the GridText multiple times, instead of just
the once as before.  I think it's worth the trade-off.

I had already come up with a hack to implement tables without
changing the parser or GridText -- when you get to <table>, divert
anything that would be rendered onto the GridText to a holding
place (like another GridText), inserting special characters (like
BOLD_START_CHAR or a new style) onto the GridText instead.  When
you get to the end of the table, you have full information about
cell widths and numbers of cells per row, so you can go back and
insert the relevant fragments into the primary GridText, formatting
the table as needs be.

Laying out the table is the tricky part.

>    Have anybody looked at the rendering engine used by w3m and 'links'? I
> think they use similar algorithms.

I was considering looking at links, but I'm looking at my display object
experiments again, to see if they are as feasible as I think they are.

I'm considering looking at Gecko, to see if that could be made to fit
with Lynx, somehow.  From what I've read, it sounds like Lynx would
appear to Gecko as a browser which only had access to monospaced fonts,
and everything would fall into place from there.  But I haven't tried it.
-- 
rob partington % address@hidden % http://lynx.browser.org/