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

[Vlad Harchev]

On Sun, 5 Dec 1999 address@hidden wrote:

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

  What is Dynamic HTML? Do big two support them?
 
> > 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.

 Yes, this is a main reason.
 
> > 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.

  Support for document.write is very good (but of course tables are more
important). 
 
> > 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.)

  Good. Does rx search wraps arround line breaks, or it searches in each line
without wrapping to the next (ie does it call regexec for each line or it
reconstructs paragraph as a big string and searches in that string)?
  It's a pity that rx search is unavailable for unicode (at least I haven't
heard about this).

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

  I don't see any problems with forms (solution is ugly, but straightforward
even if not changing any lynx structures dedicated to form fields) IMO. Only 
some additional functions.

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

 IMO it's enough to provide console display for navigator, other tools like 
mail reader could be left unported.
 There is another browser - mnemonic (www.mnemonic.org) that is highly
modularized. It's main mode is GUI, but there exists ncurses-rendering module
for it (I haven't seen neither it nor screenshots) - I don't know whether
tables and frames are supported in console variant (GUI supports tables at
least, may be frames). 


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

 Best regards,
  -Vlad