Re: lynx-dev nothing changes/no way to save changes on O)ption page

[Klaus Weide]

On Sat, 30 Oct 1999, Henry Nelson wrote:

[ other points not repeated ]
> Okay.  So can someone give me a straight answer, what does "Please note that
> a few users with broken curses may have problems with popup forms fields."
> refer to?  I would be glad to submit a patch to remove it from one or the
> other of the descriptions (which one?), or from both descriptions (probably
> the best since it seems to be just confusing the issue at hand -- the choice
> between old or new).

It should be removed.  It isn't a useful criterium to help decide
which of the two one wants: both kinds of Options Menu/Page can
use popups for some fields, and for both it can be disabled with
-popup/USE_SELECT_POPUPS.  So the sentence should go.  Something
like this might belong in PROBLEMS or the UG.

> > Btw. "menu" (as the alternative to "forms") is also quite confusing
> > (that's not new) - after all the Forms Options Page calls itself
> > "Options Menu" in the title and header!  Some better terminology would
> > be, umm, better, any ideas?
> 
> Very true.  A little brainstorming is in order perhaps.  One idea:
> 
>       forms-based-options     "Options Page"
>       fixed-menu-options      "Options Menu"
> 
> and then make it consistent throughout.

That's good, but we should have one term that encompasses both
(for your right columns).  Otherwise we'd always have to say
"Go to the Options Page or Options Menu" instead of "Go to the
Options Whatsit".

Maybe the "Options Jar"...

Also running: "Options Screen".

But actually deciding on one of "Options Page" or "Options Menu"
for the general term and using a qualification when a specific
one is meant may be most reasonable:

       (generic)               "Options Menu" (or "Options Page")
       forms-based-options     "Forms-based Options Menu" (or "F-b O P"?)
       fixed-menu-options      "Fixed-Fields Options Menu" (or "F-F O P")

"Fixed-Fields" is imperfect but I don't have anything better -
for lynx-dev use "old-style" is fine, but news users shouldn't need to
know which came historically first.

Brainstorm on...

> > Btw going back to the origin of this thread (subject line) thanks
> > for confirming that the disabling worked - since you couldn't find
> 
> So, as you originally pointed out, total disabling doesn't make a lot
> of sense (although paranoid anonymous guys might like it -- gives me
> ideas :) :), so this needs to be fixed (or if intended, needs to be
> described properly).

That state would not normally occur (the error was that it did occur
in a normal access to the Options Page).  It should only occur when
the Options *Page* is somehow reached, but shouldn't because the
Options "fixed Menu* is supposed to be used.  The situation happens
(only, afaik) with: (both compiled in, and)
    lynx -forms_options=off LYNXOPTIONS:
(or equivalents).

It's a bit unexpected that this can happen at all; when I found it,
I decided it was probably an oversight but might nevertheless be useful
(cf. your "gives me ideas"), so I disabled it only as I felt necessary
and not completely.  Why not allow the possibility to initially view
options in one (more verbose) mode but then change them in the more
concise "fixed" mode.  The changes were not big, jsut making use of
lynx's already implemented DISABLED attribute for form fields and
omitting some "buttons".

   Klaus