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

[Vlad Harchev]

On Sat, 4 Dec 1999 address@hidden wrote:

> 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.

   Yes, seems panels could be easily used too (and it's more preferable to the
use of tables for rendering frames IMO since per-frame scrolling would be
unavailable).
 
> >  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.

  I agree that two-pass renderer should be used (at least for tables). I
also think that HText could be used for final internal representation of text
(it's not that bad, and allows fast drawing), and I think that intermediate 
representation should be preserved in memory for all life of the document in 
the lynx cache. Holding intermediate representation will allow us to support 
document.write concept and (probably) resizing frames, also wiser search (so
that searching, say for "lynx browser", would find (and highlight) that phrase
even line was splitted at space between those words), probably
implementing regular-expressions search will make sense.
  
> >    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.

 IMO this approach is better (but IMO it's better to look wider - at Mozilla
as a whole - may be some other parts of it could be reused - say javascript
support). But as I know, Gecko (and Mozilla) are written in C++ - so there
could be a big portability problem with this (but I hate programming in C, I'm
a C++ wizard). As I said, may be it would be better to hack Mozilla directly
(may be by adding console-ui module to it), ie not using its code in the lynx 
(we will need to convert it to C then), but providing console-mode for Mozilla?

> -- 
> rob partington % address@hidden % http://lynx.browser.org/
> 

 Best regards,
  -Vlad