Re: lynx-dev non-sticky text inputs

[Vlad Harchev]

On Wed, 28 Jul 1999, Heather wrote:

>[...] 
> In my present use of color lynx (2.8.1rel2), form input fields "feel" much 
> like hotlinks, in terms of moving to them.
> 
> In terms of color they're kinda crazy.
> 
> Picklist fields that aren't open seem to be the same color as live hotlinks 
> (in my case br.yellow on brown, color 6), but when they are open, they're a 
> different color (br.white on black, color 2 for the selection, lt.grey on
> blue, color 0 for deselected others). (why statusline color for a pick
> field, I have no idea.)
> 
> Textfields which I'm not at are lit (br.yellow on blue, color 1), while those
> which I am at, active for input, turn yet another color (lt.grey on blue,
> color 0).  (why it should color like plaintext when it just became live, I 
> have no idea.)
> 
> If I understand the new feature I could be on the field, but not yet active
> for input.  Oh no!  Not another color!

  No, no new color will be added - the 'not entered' text fields will be of
the same color as are 'active' text fields in lynxes before the patch.
  If you'd like to have much more control over text coloring, try compiling
 lynx with lss code ( --enable-color-style switch to configure, you must be
using 'curses' for this) - the color can be bound to each html tag. See
'samples/*.lss' for examples of files that control colors per tag for
lss-enabled lynx.
 
> Given these, anything that stabilizes what all form fields look like would
> be an improvement.
> 
> I'd kind of rather that the live/active "you are here" color remain that 
> assigned to the current-hyperlink (6), and the inactive color be that of 
> unselected hyperlinks (1)  while if these fields are being skipped, normal
> color (0 or per modifiers) would be right.  Pickfields can be "entered" --
> Text fields that could be entered, should have similar color characteristics
> to the pickfields in similar state.

 Seems that all text fields can be entered...

 Seems that if 'non-entered' text fields were colored as 'currenly unselected
hyperlinks' then the user will be unable to guess which text field will be
activated if some of the activating key was pressed. On earlier stages of that
patch development, I had exact that look, and that looked confusing, so that
was rejected - now 'not entered' text fields have color of 'entered' text
fields.
 As for implementing 'skip form inputs' mode, IMO it's not very useful (at
least we can discuss it when it will be implemented :)

> If it isn't too much extra, perhaps lynx.cfg color entries could be created 
> for form fields so that I could color them uniquely from hyperlinks entirely.
> But, that's a different subject.

 Yes, may be more color categories for nonlss-lynxes will be desireable in
order to have more control over colors.

>[...] 
> The desire I described above would involve lynx knowing when it was on a live
> field.  Can you not steal the logic presently used for pickfields to determine
> when it is popped up or closed, and apply it to text fields now?

 Do you mean drawing border for text entries? (or what logic)

> > Except if we can use a different way to distinguish looks - see below.
> > sent expeditiously...
> >    Klaus
> 
> Come to think of it a pop-open box would make it pretty clear you had 
> "entered"
> the field.  Why, full textareas could almost look like they're really seperate
> somehow.

 IMO drawing boxes around text entries will take a lot of screen space (it
will hide part of the line upper text field and part of the line on the bottom
of it) and will require a lot of work.
 IMO the time can be spent on providing better support for tables.

> * Heather
> 

 Best regards,
  -Vlad