lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Would an Outline View be feasible?


From: Klaus Weide
Subject: Re: lynx-dev Would an Outline View be feasible?
Date: Sat, 13 Nov 1999 19:42:59 -0600 (CST)

On Fri, 12 Nov 1999, G Browne wrote:

> In-Reply-To: <address@hidden>
> 
> Klaus Weide wrote:
> 
> >Maybe you should give a fuller description of
> >what you intend. Regarding the user interface:
> >how should that mode be invoked -
> >a toggle key? a special URL scheme? a special link?
> 
> Outline View should be available for any web page, so a toggle key would
> work best to enter/exit this new mode. Is CTRL-O available?

Debating which key to use is one of the favorite pastimes here. :) But
this is really premature - even if there is no default binding for
some key action, one could still assign a key with KEYMAP in lynx.cfg.

> >Regarding the function: What should be displayed?
> >Should it be "active" in some way?
> 
> Each heading should be prefixed with a single character to mark and control
> its "collapsed" or "expanded" state: I'd suggest "+" and "-" respectively.
> This marker would be active and work somewhat like a hyperlink: it would
> appear highlighted, and the user could navigate the cursor to each marker.
> 
> When a heading marker is selected, two dedicated keys would perform Collapse
> or Expand for that heading, one level at a time. Since + and - keys are in
> use, could CTRL-Plus and CTRL-Minus work? Else some mnemonic keys, perhaps C
> and E?

Something like CTRL-Plus or CTRL-Minus isn't portable.  But again, this is
premature...  users interested in the functionality could override some other
keys if needed.

But I don't see why extra keys should be needed - some kind of marker has to
be "selected"==current anyway (acting like a special kind of link or button),
so ACTIVATE (Enter key) should be enough.

> >I think such a feature would be feasible, without too many changes.
> 
> Does that still hold true in light of my detailed description?

Unfortunately, no...  probably still possible, but not without some
significant investment of time.

I was thinking you just wanted two different views of the document as a
whole (full vs. some-stuff-collapsed).  In that case, just making a different
rendering of the input (basically by skipping stuff) in HTML.c would be
a reasonable approach.

But for having items that are individually expandable, this doesn't make
sense.  You would have to have an internal representation of the document
that includes everything, but doesn't always show everything.

"The" representation of a rendered document in Lynx is the struct _HText
implemented in GridText.c.  Basically (very simplified) a list of HTLines.

I can think of two basic approaches to your idea:

(a) Invent some other representation of a document, that would hold all
the contents and structure, but wouldn't be the final stage of rendering.
Something that sits between HTML.c and GridText.c functions.  Something
like this would probably be inevitable for implementing something like a
DOM (object model, as for giving access to document components to
scripting langages)...

(b) Tweak HText implementation in GridText.c.  I assume it's enough to
do the collapsing/expanding in a line oriented way (not affecting parts
of lines, but only lines as a whole.  The required basis for this could
be adding a 'visible' flag to each HTLine, which would be set/unset in
some way by user actions.  All functions that produce output from a HText
structure (display_page/display_line etc.) would have to be modified to
look at that flag (and skip lines marked as currently 'invisible').
But that's just part of it - all functions that count lines in some way,
as for going to the previous/next page (screen) need changing, how should
anchors within the invisible part be handled?, and of course how to
display somthing in place of the now-invisible lines.  This would be
just the basis to build upon, creating this basis would be the most
difficult part (I think it would take significant time, and the code
isn't easy to understand in this area...YMMV).  After this, things would
get easier.

> >regarding MS Word, that doesn't have
> >much to do with HTML...
> 
> Word97 and 2000 support HTML as a native file format. [...]

Well, I know about it (not from any personal experience...) but is it
really HTML?  Or is it HTML-with-all-kinds-of-weird-extensions?  (This
is getting off-topic though.)

> >the way output is suppressed if LYMapsOnly is set
> >may serve as a template for what you want.
> 
> Browsing the HTML_ functions in html.c begins to give me an idea of how lynx
> controls its output. Is there any overview available of how the parsing and
> display processes interact?

Unfortunately, no...

For some of the big picture, the documentation of the current W3C libwww,
may still be helpful:
   Linkname: Libwww - the W3C Sample Code Library
        URL: http://www.w3.org/Library/
(Or it may be confusing - there are significant differences.  But at least
for some of the structures that are common between the code under Lynx's
WWW/Library directory and the current W3C libwww - things like HTAnchor,
HTStream, HTStructures - the descriptions on the w3c site still apply,
with modifications.)

But that's mostly at a lower level (protocols, streams) than what you
are (or should be) interested in - it's not really about interaction
of parsing and display processes.

Here's a very summary schematic how some things fit together (example only,
for loading a typical http document)

(user) -> mainloop()  -> getfile()   ->HTLoadDocument() ->   
         HTMainLoop.c    LYGetFIle.c    HTAccess.c        |     (network)
           |                                              v
           |(request paging/display)                    HTLoadHTTP()
           |                                             HTTP.c
(display)  v                                              |
   <-- HText_..() <- HTML_..() <-SGML_..() <-HTMIME..() <-/
       GridText.c <-  HTML.c     SGML.c      HTMIME.c

Arrows pointing left represent a request.  Arrows pointing right represent
flow of resulting data.

Your functonality would have to be implemented mostly in the leftmost
part.

Still interested?  Then try to make sense of GridText.c...  It may be
helpful to consult older Lynx source (say 2-5 or 2-6'ish) for trying to
understand (as long as you are in read-only mode).  It's less cluttered
up.  The basic mechanisms are still the same.  (For actually messing with
the code, you should start with the most recent dev.N code set.)

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]