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

[Heather Stern]

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

I have brighter ideas this time around than to turn lynx into an AI.  Read
further and enjoy...

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

I'm not sure - I find less frames sites nowadays (at least that have interest
for me) - so I hadn't stressed over it, but I felt I had something to 
contribute to the discussion.

Not being sure is why I'm a fan of options, and why I tried to suggest
something that would make it still offer the NOFRAMES space.  You and I
clearly agree that some folk do make the right effort with noframe content
(good thing too - for those Older Browsers, who unlike lynx don't have
a partial solution).  Er, I'd been kinda hoping that some graphic browser
would offer me the option to see the noframes side instead; I know that's
a tangent but if anyone knows of one that does, platform Linux, lemme know.

I was being chatty with a friend last night, he's another lynx user but 
not a power user type.  He thought lynx' frame support was rather different 
than it is, in fact maybe his assumption is something we should consider.
I had to search my preferred haunts quite a bit before we found a site that 
really *was* using frames rather than empty tables for *very* effective 
graphic layout.  He thought lynx just saw the frames, and rendered each as 
they were seen.  Not that he could tell where he thought the divide in the 
frames was...

Unfortunately to render each as seen would require briefly memorizing what
to fetch, then (while frames-in-mind do: draw frame header, fetch, render).
This would be a pain if NOFRAMES was cool and you turned out not to need it
anyway, that it would go fetch - exactly the "feature" that causes graphically
oriented folk to despise the things too.  (Which would make it a rather 
faithful rendering!) I guess first frame could be the noframe sector, esp.
as that can be displayed before you go into fetch mode.  And of course this
is the threading that we don't have!

So, I have a new vision, but it needs a little illustration. Visit a 
frameset page and get:
        FRAME 200 pixels to right: nav
        FRAME: content

        Welcome, bearer of an older browser, to the text based site of Fu 
        Bar and Grill.  We have lots of links cooking for you. (etc.)

If I choose the (as yet unprogrammed option) render-frames action, it would:
  * reread page from cached source/local proxy/net
  * this time memorizing the FRAME hotlinks
  * loop and draw something more like:

        ------------------ FRAME 200 pix to right: nav --------------------
        FU BAR AND GRILL MAP  indent indent Breakfast Griddle Have a Soup
        or Salad! Summer Barbq Midnite Snack indent visit our sponsor du jour
        ------------------ FRAME: content ---------------------------------
        FU BAR AND GRILL 
        (et cetera, probably much longer and "sales"ier.)

For example's sake I assumed that FUB&G are using Alt tags for their tooltip 
qualities, not to support us particularly, and that their webdude upon being
ordered to use Alt tags, went overboard and tagged his invisibles, cuz he
doesn't know how to Alt them as invisible.  :)

Of course said action bound would toggle state, as I already am used to with
\.  In fact if I were to code it I might offer it as suboption in \, if and
only if site bears frames, to either switch to source or to framefetch.  Some
buried option for PREFER_FETCH_FRAMES that lets people request the faithful
rendering style and suck up their local bandwidth if they want to. (Ok, I
suppose it would really show method two and let them \ to pick the other one
or source.)  

On second thought maybe it would be better to show NOFRAMES as hotlink number 
1 in the framefetch version, and RENDER ALL FRAMES as hotlink number 1 in the 
noframes version, moving the function to a consistent place and dodging the 
chance of breaking a current action key. (I can hit Home, Enter to get to
this in either mode.)  With the current style of listing frames still shown
in noframes mode, giving additional data to help us with the decision.

Rathole class questions to be asked if attempting to implement: 
  * rendercache holds what - 
        frameheader1 + nav (body only) + frameheader2 + content (body) etc?  
  * best way to turn previously non-prompting \ into i18n safe prompting 
    (but only for frame sets).  Or, whatever to put in RENDER ALL FRAMES
    link to clue lynx into the new function call.
  * allocating the frames-to-fetch buffer without generating an overflow
    opportunity.
  * frames within frames do... what?  make your framefetch routine know
    how to expand the frame requests and not leave til it's done?  Or 
    render them the noframes way instead?  (ouch, my brain hurts.)
  * what else could this break?

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

Ok here's weird but I've really used:  graphic archives, in order to do
their little fashion show without downloading at you all 600+, maybe 
thousands of small images, use frames and nav categories.  They really
that way show some 6 to 12 at once.  If I know what category I want 
something in, the fact lynx doesn't deal graphics can speed my trip
down into the showroom floor considerably.  If the image filenames
aren't good enough I can hit = and steal the buried URL for my graphical
session after all.

In such cases I more often drill down the nav, not the content side.

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

In my newer vision we don't calculate nothin', just report what was requested
whether it was by pixels or percent.  Well, we're deciding left or right, top
or bottom, but I think that's a frame attribute too.  If they requested "*" 
(use the rest of the space) don't waste text on it, just print the : already. 

> > stream of consciousness style of loading.
> 
> It's not doable with a simple modification.  Currently there is no 
> mechanism ... [*] ...
> Lynx isn't multi-threaded, and network modules are not re-entrant.
> [*] Except if you count HTTP redirection and authentication.

In other words, it's still not re-entrant, it's just not leaving quite yet?

> > The point being, we'd act as if we do support frames ...
> > 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).

I like my new vision rather better than trying to train lynx into an AI 
that wants to figure out what the heck these webmasters *preferred* to show.

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

That sort of thing is why I said I don't think we're ready for windowing
plans yet.  Screen is also GPL (I just looked at its manpage in another 
virtual console to check) so if some brave souls want to try it, I'd say
try starting with screen's framework, then make it a custom version that
does its own thing with its subwindwos instead of offering their control
to user shells -- with lots of parts from the lynx code, a hell of a
design plan, more skill in C and especially at grafting other people's
code together than me, plus more time to burn than me too.  (But heck,
if one or more of you try to create it, I'll help test the sucker.)
Heh - "leen" - lynx+screen :) 

> I don't supposed you want to let the user wait until 10 mostly useless
> frame documents are prefetched.

You would surely leave the PREFER_FETCH_FRAMES option I suggested off,
I don't know which I'd stick with.  But hey, if someone wants to turn it on 
then it's between them and their netadmin.  Bet that proxy server they use
gets a lot more exercise :P

>> 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)
  [...snipped...]
> How about keyboard macros?
> Maybe your environment already provides them.

Duh, now that I thought of it, Home to get to the top of screen, Frames are
always the early links right now.  Ok, answered my own question, and much
better than that / trick of yours too.  Home, Down, Enter still isn't 
that hard.   

I think my new vision much more closely approaches a windowed look without
actually doing it.

> 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

I have *no idea* what site was in mind that started this thread.  I just 
piped in after the discussion got rolling.  

Comments from the peanut gallery welcomed.  Thanks for reading the whole
thing.

* Heather Stern * address@hidden * Starshine Technical Services *