Re: lynx-dev frames, frames (was: longer.)

[Klaus Weide]

On Sat, 10 Jul 1999, Heather Stern wrote:

> Eduardo Chappa L. wrote:
> > *** brian j pardy (address@hidden) wrote Today:
> > 
> > :) I'm highly considering making a patch for my personal use that will
> > :) cause Lynx, whenever finding a frame titled "content", will jump
> > :) directly into that frame, bypassing the previous page.
> > 
> >   I proposed in last march this feature, however I was answered the same
> > way they answered you. How do you know that this is the frame you want to
> > open? I would support something like this. Actually, if you do some kind of
> > traversal and open all frames, nobody could complain, you would just make
> > things slower, nothing more (ok, sounds crazy, but still doable if you
> > display one page under another and make them easy to separate/distinguish).
> 
> It occurs to me that what I'd really prefer to see is the "obvious" frame 
> (to me, that'd either be the one named aptly, or in absence of that, the one 
> with the greatest percentage of screen estate assigned to it) to be displayed
> instead of the lamer "your browser doesn't do frames" stuff (NOFRAMES) 
> which used to commonly point to "get a newer browser" stuff.  This sounds 
> similar to what Eduardo said, but I think it'd be easier to implement.

What would you rather trust,
(1) a manual procedure that allows correcting false assumption in a
    simple way (trial and error), or
(2) an automatic procedure to "guess" the "obvious" frame which will be
    sometimes wrong (and then probably harder to correct)?
For me, the answer is (1). 
(Actually more likely (3): leave the site and don't come back if lynx is
obviously not wanted.  And the required manual intermediate step gives me
the chance to make that decision earlier, without wasting more loading
time.)

The most useful (and least complicated) part of your ideas seems to me
the 'percentage of screen estate' part.  Perhaps this could be
just shown as additional info.  But even this requires adding HTML parsing
and calculation logic (thnk of nested framesets) that currently isn't
there.

> (To me, it sounds like Eduardo is requesting window-layout support, which
> we seem not ready for quite yet.)  This would still be doable with the
> stream of consciousness style of loading.

It's not doable with a simple modification.  Currently there is no 
mechanism to start a new request from the middle of an active request.[*]
Lynx isn't multi-threaded, and network modules are not re-entrant.

[*] Except if you count HTTP redirection and authentication.  For these,
sending a new request is triggered in the HTTP module, right after the
response status line from the server has been processed.

> The point being, we'd act as if we do support frames (just like I've been
> telling my buds for awhile -- it does, it does!  just more weirdly than
> you had in mind.) so we should prefer content to the noframes content.

It's kind of inconsistent.  But some site put very useful, lynx-usable
content in NOFRAMES (no, not just links).

> It's just, I'd kinda still like the option to see the NOFRAMES instead, 
> in case that's where they decided to stash the better looking text-only 
> links.  And it'd be fine by me if the other frames hotlinks were still 
> there at the top.

That's what you get with the well-designed sites using NOFRAMES. 

> Y'know, if we start doing this, then there are some sites, not that many
> but a few, where the frames have frames inside of them.  Haven't looked
> too closely at how the frame hotlink is wired.  But I could envision:
> 
> FRAME 10% to left: _nav_
> FRAME (now displaying - see _NOFRAMES_): main 
> 
>  FRAME 10% to top: sponsor
>  FRAME (now displaying - see _NOFRAMES_): main 
> 
>     [company logo}
> 
>       {picture of box} brand x is the best fubar making widget
>       since sliced bread.  Now for our extensive line of toasters...
>       ...bla bla ad nusea...
>   
> 
> > Also if you gave a list (say under the title line) of the non-opened
> > frames, it would be equivalent to the behavior that lynx has now, with the
> > advantage of having at least one of the frames opened.

Lynx already shows one frame opened, in a way: it's the 'frame' called
NOFRAME.  It's just that most people don't put anything useful there.
(But then that's true for most other frames too...)

It also happens that the NOFRAMES 'frame' is already contained within
the same HTTP (or FTP, ...) message/file that has the frameset.  So
we get it for free.  Any other frames mean additional network requests.

> Another interesting possibility would be to preload each frame into the cache,
> then offer a frame-fast-fetch on some keystroke+framenum key pair.

At the level of complexity you're getting into here, it seems more
reasonable to put this burdon in an external proxy(-like gateway)
(or script) (or use w3m?).  Lynx isn't equipped to do stuff like
this 'in the background', there isn't a real eventloop etc., and
I don't supposed you want to let the user wait until 10 mostly useless
frame documents are prefetched.

> If we
> know there are three frames, and we can use only one or two keys to switch
> quickly among them, it would "feel" more like real frames support, even 
> without complex windowing support.

You already can use 'one or two keys': as long as there are no more than
9 frames, number + ENTER is two keys. (If links are numbered, of course)

Or if the frme link with the really important content is really named
"content" (or contains the string):
First time:   '/', 'content', ENTER
Next time:    'n', ENTER            (<-- two keys)

> (otherwise we have to cursor link to
> them.  Ooo, do they count into the numbers on numbered links?  I never thought
> of that before.  The frames as done right now are alsways the top few links
> anyway.)  Err, tell me what you think, maybe all we need to do is make
> it a little more obvious what keys already exist for fast frame access, and
> the road to loading those a little more smooth.

How about keyboard macros?

Maybe your environment already provides them.

I would also like to see if and how any of this would help in the concrete
case of the page or site that triggered this thread.  (No, I don't know
which of the many frame links had the "obvious" content.)


   Klaus