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

[rjp]

In message <address@hidden>, 
           Vlad Harchev writes:
> 
>   I agree that two-pass renderer should be used (at least for tables). I

Seperating the rendering from the parsing also gives us support for things
like Dynamic HTML.

> 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 

So parse->internal objects->renderer->HText->curses|slang->screen?
Then for simple things like scrolling the screen, just redisplay the HText;
for more difficult things, adjust the internal objects, re-render, then
redisplay the HText.  Makes sense to me, because we don't have to bother
reimplementing things like the partial display and screen display routines.

> 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

You can already support document.write (my Javascript patches do), but it
works by inserting tokens into the incoming SGML stream (not a nice hack),
and it breaks horribly if you try doing it after the parse has finished.
Not really worth it at the moment.

> implementing regular-expressions search will make sense.

I've already tried regular expression search.  It works, but I've broken
the highlighting somehow.  I'll have another look, see if I can figure
out what I broke.  I'll post it here, too, so someone else can fix it,
erm, check it out.  (Not that I can think of any use for regexp searching.)
  
>  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

I've already nicked the Javascript module for using with Lynx.  I've posted
here about the problems with integrating Javascript with Lynx, though, and
they're mainly to do with the lack of internal document structure which we
need to sort out for tables anyway.  Things like getting values from form
values aren't much fun at the moment.

> 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 Mozill a?

The problem is that Mozilla is huge, much much larger than Lynx, although
it is much more powerful.  Not that Lynx is the smallest browser anymore.
-- 
rob partington % address@hidden % http://lynx.browser.org/