Re: lynx-dev Options again

[Al Gilman]

to follow up on what Mike Castle said:

> In analyzing the options screen layout to determine what the equivalent
> html would be, I've come across a stumbling block.
> 
> The option "^A)ssume charset if unknown" is controlled by the user mode.
> It's only available in Advanced mode, and the option actually disappears
> dynamically if the mode is changed.

Does changing the user mode disable the effect of what you have previously
set?  This may be a screen design convenience, not a functionality 
requirement.

> Now, I know C, not HTML, but I don't think there is a way to achieve the
> same effect in a form.  Correct?

I believe you will find in HTML 4 that a form control can be in a
"greyed out" state -- that is to say not accepting user input.
Setting some controls in this state as a function of other control
settings is a job for a script, as I understand it.  Lynx doesn't
give you ECMASCRIPT services so if you want to preserve this 
conditional sub-options functionality, you would have to emulate
the script in the HTML-form-processing C you write, but that is
not such a big deal.

In this case I see no reason to restrict the "assume charset"
settability based on the "user level" setting.  But there are
instances of sub-options such as the multibookmark setup as you
say.

> Similarly, the way the Advanced bookmarks is going to be a bit tricky.
> 
> So, I guess the question is:
> 
> If the options section is to be enhanced (and I believe it should be),
> should it be done using html/forms?  Or should it be done by expanding the
> current method of using multiple screens?

Using HTML Forms and using multiple screens are not mutually exclusive.

In fact, the simplest way to handle sub-options is a multi-page form
where the generation of the next form depends on the parameters submitted
in the last form.

> Would replacing the special code for a separate UI in the options section
> with special code for handling HTML really be worth it?
> 
> I like the idea of going with HTML.  The current option UI has lots of
> stuff dealing with curses/slang differences, and all the SelectPop up
> stuff.
>  
> So, I guess the question comes down to, if I want to contribute to lynx by
> trying to enhance the options section (eventually I want to expand the
> whole thing to having lots more things user configurable at run time), what
> would be the best way to do it:   HTML based forms, or special UI code?

Making the option setting work like HTML forms simplifies user training
and reduces user confusion, it is claimed.

On the other hand, you might want to push the design-level dialog like
the above questions a little further before diving in to code something.

Al