Re: lynx-dev patch that allows text inputs to be non-sticky

[Vlad Harchev]

On Wed, 28 Jul 1999, Klaus Weide wrote:

> On Mon, 26 Jul 1999, Vlad Harchev wrote:
> > 
> > * Added ability to make text inputs non-sticky (ie user will need to 
> > activate
> >   them explicitly via and LYK_ACTIVATE action) - seems useful for people
> >   navigating with alphanumeric keys. Default is 'sticky' - ie old behaviour.
> >   Behaviour controlled via commandline option '--sticky-inputs' and
> >   STICKY_INPUTS in lynx.cfg.
> 
> Comments:
> 
> 1. This seems to be useful.  People have occasionally asked for it.
> 
> 2. Please give this feature (and the option) a different name!
> 
>    To me at least, "non-sticky text input" doesn't mean anything.
>    I had no idea what the patch was about from reading your message's
>    subject line.
> 
>    better: "non-sticky text input *fields*"
>    still better: something that avoids "sticky" altogether.  Not sure
>    what, but "FLY_OVER_INPUT_FILEDS:YES" or "AUTO_ENTER_INPUT_FIELDS:NO"
>    or "AUTO_LINEEDIT_INPUT_FIELDS:NO" seem preferable to me, maybe someone
>    else has a better idea.

 We can vote for reasonable name for this functionality (I don't care what
the name would be). I like the following:
AUTO_ENTER_TEXTINPUTS
STICKY_TEXTINPUTS

> 3. You introduce variables 'textarea_drawn' and 'textarea_activated', but 
>    they seem to apply to text input fields in general, not just those for
>    TEXTAREA.  Please avoid creating confusion.  If these variables are
>    necessary, they should probably be 'inputfield_foo' or similar.
> 
>    Adding new global variables like 'textarea_drawn' should be avoided
>    if at all possible, we should have less of them instead of more...

 'textarea_drawn' is modified in LYUtils.c:highlight() - that's why it's
global (in general I needed the way to invoke some code when current link is
changed, so I placed it in highlight(OFF,....) and in the condition 
 (curdoc.line != Newline) in mainloop, see below for more info).
  Sorry for stupid prefix 'textarea_'.

> 4. Are the 'redraw_only' calls necessary at all?  Have you tried what
>    happens when the first change_form_link() (and surrounding block) is
>    just skipped completely?

 Yes, they are. Firstly I added this functionality without those calls. But
this has a very confusing visual effect. Since the text fields are highlighted
not in LYUtils.c:highlight, removind 'redraw_only' argument and the logic for
redrawing will make highlighted textinputs visually indentical to
unhighlighted, so on page where textinputs come in chain, user will lose
control on what the current link is (this looks very confusing, believe me).
Adding 'redraw_only' argument took my time, but it was worth it. And if text
in the input field is longer than input width, the input field will look like
it's active (ie curly braces will be added, and the text will be scrolled to
the end).
 
>    (That would have been my first go - just add ' && <some variable> '
>     to the condition in
> 
>             /*
>              *  Normal, non-traversal handling.
>              */
>             if (nlinks > 0 &&
>                 links[curdoc.link].type == WWW_FORM_LINK_TYPE &&
>                 .....
> 
>     If you tried that, I would be curious why it wasn't enough.  Apart
>     from use_last_tfpos not working, but then maybe it shouldn't if one
>     doesn't want to automatically edit input fields.  keeping state in
>     'textarea_activated' might not be necessary at all if this works.

 Please expain (or  <some variable> will be equivalent in semantics to
textarea_activated)?

> 5. This section:
> 
>         if (!(nlinks > 0 &&
>               links[curdoc.link].type == WWW_FORM_LINK_TYPE &&
>               (links[curdoc.link].form->type == F_TEXT_TYPE ||
>                links[curdoc.link].form->type == F_TEXTAREA_TYPE)))
>              /*
>               *  Highlight current link.
>               */
>             highlight(ON, curdoc.link, prev_target);
> 
>     from the original LYMainLoop.c (and you haven't really changed it,
>     except for adding braces) was inconsistent with other places where
>     the link type is tested - the other text-like types should probably
>     be added to the condition, I see now reason why there should be
>     a call here to highlight(ON) for e.g. F_TEXT_SUBMIT_TYPE when it isn't
>     done for F_TEXT_TYPE.  It doesn't seem to have done any harm.  But
>     in case your 'textarea_drawn' was just introduce to deal with this
>     inconsistency, you should get rid of 'textarea_drawn' and fix the
>     inconsistency instead.

 Yes, I was surprised by that inconsistency, but seems the things work ok even
with it (without my patch, seems certain types of textinputs were highlighted
2 times). IMO let it be so (may be this is what was intended)?
 See below of 'textarea_drawn' semantics.

>     It is my understanding that highlight() should never be called with
>     ON for text input fields, only with OFF.  And this is already done

 But seems that the 'highlight' implementaion supports drawing any text input
field for both highlighting and unhighlighting.
 
>     in display_page for those fields.  Therefore my suspicion that your
>     'redraw_only' call and keeping track of the displayed state with a
>     'textarea_drawn' variable are only necessary with the effects of a
>     highlight(ON) that should have been avoided in the first place.

 Keeping state in 'textarea_drawn' is necessary for the following reason:
the highlighted text input must be highlighted once,
after that any keystrokes should be interpreted as usual lynx keystrokes, not
textinput keystrokes.
 This can be achieved with help of 'textarea_drawn':
   when it's off, the textinput is drawn (and it becomes ON)
   when it's on, entire condition

             /*
              *  Normal, non-traversal handling.
              */
             if (nlinks > 0 &&
                 links[curdoc.link].type == WWW_FORM_LINK_TYPE &&
                 .....
  must be false in order the flow of control to be passed to the 'else' of
that condition (or 'else' part should be replaced by 'if not-handled'
operator, this will also require introducing some variable, but it can be
local).
 
> 6. This code could interact in some strange way with various mouse actions
>    (clicking double-clicking if different, actions from ncurses-mouse
>    menus, may act differently for F_TEXT_SUBMIT_TYPE than for other
>    input fields), someone should test it...

 Yes, I understood this when was writing.. Somebody should.

> 7. Historical note, if anyone cares:
>[...]
 
> 8. Some intermediate setting could also be useful: with that setting,
>    once you have entered any input field for (line-)editing, lynx could
>    assume you want to fill in forms and enter fields automatically as
>    long as the same document is viewed.  (Just an idea, maybe not a useful
>    one.  Of course this *would* require keeping more state, which I question
>    for the current code.)

 May be (but that also should be configurable, otherwise we will go MS way) -
program thinks that it's cleverer than a user.
 I thought on adding another switch:

 when in any textinput, pressing Arrow Left arbitrary number of times
won't make previous document active (this annoys me too sometimes). What do
you think? What the option name do you suggest?
 
>  Klaus
 
 And what those type of textinputs mean, can anyone explain:

 F_TEXT_TYPE         seems only 1 line of text
 F_TEXT_SUBMIT_TYPE  ?
 F_PASSWORD_TYPE     content will be substitued with strars.

 F_TEXTAREA_TYPE     seems the same as TEXT_TYPE, but growable

 Did I understand those types correctly?

PS: I'll rename global variables, and remove 'textarea_drawn' completely (as I
explained above), hold on for 2 hours, but Klaus, please reply ASAP (or new
version of the patch will be released before I see you reply).

 Best regards,
  -Vlad