lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev non-sticky text inputs


From: Klaus Weide
Subject: Re: lynx-dev non-sticky text inputs
Date: Wed, 28 Jul 1999 15:45:26 -0500 (CDT)

On Wed, 28 Jul 1999, Heather Stern wrote:
> Klaus Weide wrote:
> > 
> >   links and fields become 'current' in the usual way (by "moving" to
> >   them, if not initially 'current' when page is first displayed),
> 
> I meant by "live" the present method, where they become 'current' and 
> 'activated' in the same action.

(I think you were also using 'live' for normal links, therfore the need
to differentiate.)

> > and
> >   currently:
> >     A 'current' popup field becomes 'current'+'activated' by ENTER;
> >     A 'current' textinput field becomes 'current'+'activated' automatically
> >     when it becomes 'current'.
> >   with Vlad's change, optionally:
> >     A 'current' popup field becomes 'current'+'activated' by ENTER (as 
> > before);
> >     A 'current' textinput field becomes 'current'+'activated' by ENTER.
> > 
> > Thinking of it this way, COLOR:6 for popups that are 'current' but not
> > 'activated' is consistent with the coloring of normal links.  'activated'
> > is an extra state that normal links don't have (or, if you will, they have
> > that state only while nobody is looking, i.e. while we are viewing the
> > page that was loaded as a result of activation, and possibly in the time
> > while new page is loading but the old page is still displayed [but we
> > don't keep track of that]).  The 'activated' state of popups is pretty
> > obvious (as you also noted somewhere), and there are some reasons for using
> > mostly COLOR:0 for it: (a) COLOR:0 is the default, nothing else is said for
> > popped-up popups, so... (b) COLOR:0 is presumably most adequate for larger
> > chunks of text, less "hard on the eyes" than styles used to emphasize text
> > in some way.
> 
> Hmm.  Put it that way, that makes sense.  But it doesn't explain why 
> statusline
> color is used instead of hotlink for the pickfield/current selection.

Well, I didn't endeavor to explain everything. :)

I don't know whether 'statusline color is used' is always true, even
for all non-color-style lynx.  It seems to be always the case with
slang, but with (n)curses 'wstart_reverse' is used which may or may
not translate into the same thing.

Keep in mind that you should not just think in terms of color, but for
non-color-capable terminals and -nocolor it should fall back to usable
mono attributes, via the correspondences given in lynx.cfg.  And some
setups may have only one usable attribute available, and afaik lynx still
tries to supports them as best as possible.

Another point is just that nobody so far seems to have bothered to change
it.  Apparently it hasn't been a big problem for anyone (not even you :)),
or those who want more color configurability are now happily using color-
style lynx...

> > > 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.)
> > 
> > It is consistent, if you agree to think of it in the terms above.  Both
> > (a) and (b) form my previous praragraph apply, IMO - re (b), it's useful
> > to have text that is being edited appear in the most "normal" and
> > comfortable style/color.
> 
> I disagree, I like to have the thing that I am working on bright and more
> vibrant than the standard text scattered around it, but haven't stressed 
> very hard about it.  I don't seem to have end-user means to seperate it.

A reasonable different view - but I don't remember ever having seen this
wish on the list before (since about when lynx first went 'color'ed).

( unnecessary remark: and 'vi' doesn't do it either :) )
([ Now I'm sure this will start a new sub-thread about vim coloring etc. ...])

> Did I see someone suggest bounding the field with curly braces when it was
> current + activated?  That would certainly show in -nocolor.

That happens already, but only if the text lenght exceeds the assigned field
space.

[ left unsnipped because it's a good summary: ]
> ok, diagram time:
>                    Not Current         Current Only     Also Activated    
> PICK LIST          [desl.hotlink]       [hotlink]       status/ normal + drawn
> TEXT 1-line        _desl.hotlink_          *            _normal_  
> TEXTAREA           _desl.hotlink(ea.)_     *            _normal_ (1 line only)
> RADIO              (desl.hotlink)       (hotlink)       changes state
> buttons             desl.hotlink         hotlink        invokes form
> 
> * being currently proposed.

> Um, anyways his patch would make the two starred entries possible, then we
> can argue over what color they should be (though I agree with you, they
> should be hotlink color while current-only).
> 
> I disagree with the direction I see Also-Activated going for textarea, it's
> barely normal that they look like a group but are treated as individual lines
> already.  Treating them even more individually would piss me off, every 
> single day.

It's not going into a different direction for textareas, it's just
continuing to treat them like a bunch of input fields except for some
specific exceptions.

> I disagree about form gadgets becoming normal color, I want to be able to 
> (for instance) have all my form parts in cyan:black as they become active.
> But your justification for the color is borne out, as "normal"
> it's bearable enough, that I hadn't bothered to complain, either.
> 
> I like pickfields becoming line-drawn when they pop open;  I'm kind of hoping
> I'll see that for textareas someday.  And it would be acceptable to me to see
> those upon opening 1-line text fields, if they were normally closed as I 
> travelled past them.

You are leaving the realm of the already implemented and the easily possible,
and entering the realm of far-away wishes...

Nobody's going to implement drawing boxes around input fields, in my opinion.
It's too complicated, unnecessary, and unreliable.

Nobody's going to implement drawing boxes around textareas, in my opinion.
It's too complicated, unnecessary, and unreliable, and there already is
external textarea editing.

What I mean with unreliable: It may always work for you, but it doesn't
for me.  It depends on the console font I am using (corresponding to
'display character set'), some of them have box drawing characters and
others don't, but you can't express both in a (the same) terminfo file.
(I suppose I could force lynx to always use ASCII replacements '-' '|' '+'
if I cared enough.)


    Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]