Re: lynx-dev Form based options menu

[Mike Castle]

Amazingly enough Leonid Pauzner said:
> > Basically, there's a BIG if statement that checks to see if any of the
> > items that got changed affect the current page.  Personally, I'm not
> > certain *why* that needs to be the case.  After all, if you continue to pop
> > pages with the new settings, you're most likely not going to be reloading
> > those from the server.  So why treat the current page special?
> 
> Why not to leave BIG if as is for the moment? It *works*.
> 
> You speak about mainloop in LYMainLoop.c, just after the options() call.
> As far as I understand, settings beeng altered should be activated
> on "current" page (which was before you went to Options menu).
> So, changing of some settings may need to force the repaint of display only,
> some may need to force the retriving from the remote server with nocache,
> some may need no action for "current document" (like changing editor's path).

The thing is, with my idea for the change, things no longer work the same.

In the old method, when options() returned, you knew that right then and
there, you could check to see if things have changed.

With my design, at that point, only a FORM has been generated, nothing else
has happened.

So now, mainloop() goes back up to the top, and all you have at this point
is an active form.

You don't know anything has been changed until the form is either posted or
the user goes backwards.  If backwards, don't need to worry.

If posted, getfile() gets called, and special handles the form posting by
calling a routing similar to what happens for LYNXPRINT: urls.

So, when getfile() returns, if the url posted to was LYNXOPTIONS:, then we
know we need to check to see if things got changed.

The problem is, some of those flags in the BIG IF STATEMENT, if set too
soon right after getfile() returns, things kind of act funny (for one, if
too early, the newdoc hasn't yet been invalidated, so when it checks to see
if the changes will cause a form to be reposted, it ends up reposting
itself).

The thing is, I'm not yet certain if there is one magic spot to check
everything and set all the various items, like there was with the old
options() style, or if things need to be spread out some throughout the
loop.

At anyrate, for *most* things, at this point in time, not handling
refreshing the current doc is not important.  Getting the options modified
is.   One step at a time.  :->

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  address@hidden  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen