[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev "sticky" things
From: |
Klaus Weide |
Subject: |
Re: lynx-dev "sticky" things |
Date: |
Sat, 16 Oct 1999 07:54:05 -0500 (CDT) |
On Sat, 16 Oct 1999, Vlad Harchev wrote:
> On Sat, 16 Oct 1999, Klaus Weide wrote:
> > On Fri, 15 Oct 1999, Vlad Harchev wrote:
> > > its default value... And I finally wonder, why the name
> > > 'textfield_stop_at_left_edge' didn't inspired you about its destiny :)
> >
> > It is not as descriptive as you think. Just 'stop' doesn't say much.
> > Does it mean 'stop_at_left_edge_and_ignore_key_completely'? Or
> > 'stop_at_left_edge_and_ask_the_user'? Or stop_and_something_else?
>
> Sorry for such bad name.
It's not a "bad name", as variable names go. I was responding to your
implication that it should be obvious from the name what it all means.
> English is not my native language, and I know it
(nor mine; I'm sure the "natives" notice.)
> very bad (as all noted) - at least I don't know a lot of russian->english
> mappings. Please check the variable names and configuration
> settings' names I introduce in posted patches and provide better alternatives.
> This won't hurt me. All lynx-devers should remember this (Tom especially).
> >[...]
> > Philip Webb: "i don't want this change, let alone need it"
>
> This was said about making this change unconditional (ie dropping old
> behaviour).
I didn't read it that way, but ummh okay.
> > Ok, I dare you to find *one* user (other than you) who finds the
> > current STICKY_FIELDS:FALSE is an improvement over STICKY_FIELDS:TRUE
> > and would actually use it.
>
> IMO it's useful for former Windows users (that don't know traditional unix
> keybindings). If the keyboard repeat rate is slow, and user whishes to get to
> the begining of the text input, the user will press arrow-left for some time,
> that (depending on the keyboard rate) will get him to the main page (in worst
> case) if the textinput was not edited. I can imagine how badly the user will
> characterise lynx - I did this before the sticky* patches too. The fact that
> few or none lynx-devers said they wished that feature can mean that there are
> no unix-newbies here. IMO, as long as this feature can be turned off (and is
> by default now), it can be in the code (it's only 3 line-patch).
I don't object to a configurable option for this in general. If you got that
impression you got me wrong. It is the "gives no feedback or choice" part
of the previous patch I object to, combined with that it was the default,
combined with hard-to-understand logic and the ignoring of the already
existing prompt possibility...
> Yes, I consider always asking to be better behaviour than my patch provided
> (I don't prefer to change the definition of "just now edited"). I'll
> attach a patch to this message . But now I think that to be fully constistent,
> we should have something like setting
>
> CONFIRM_LEAVE_DOC_IN_TEXTFIELD:NEVER|IFCHANGED|ALWAYS
>
> If value is NEVER, PERV_DOC_QUERY will be never asked,
> IFCHANGED - old behaviour
> ALWAYS - ask always.
> For competness, IFFORMCHANGED should be added as accepted setting too.
> What do you think?
I think it is fine. It is what I would have expected your patch to do
from the beginning, and I was confused because it was doing something
different. :)
But it seems mattack wants something different now...
I suggest to change some details:
> CONFIRM_TEXTFIELD_PREV_DOC:NEVER|IFEDITED|ALWAYS
>
> If value is NEVER, PREV_DOC_QUERY will be never asked,
> IFEDITED - old behaviour
> ALWAYS - ask always.
PREV_DOC instead of LEAVE_DOC - well, it's already the name of the key
action
no _IN_ - to make it a bit shorter (but if you disagree, fine)
no IFFORMCHANGED - that would seem to indicate that we check whether
the form as a whole (any field) changed.
IFEDITED (or IF_EDITED?) - maybe. to not give the impression that
a different kind of change has something to
do with it? Or leave as IF(_)CHANGED.
> > It would be so trivial to just always issue the prompt. The code
> > for the prompt is already there. But no, instead we got something
> > more useless AND more complex. A "patch that will *prevent* returning
> > to the previous[...]" (my emphasis), rather than a patch that would
> > help avoiding *accidentally* returning.
>
> IMO it's not so useless and it's not complex. It doesn't prevent returning
> completely, it "prevents from returning to the previous document from the text
> field by pressing arrow-left" - there is a difference.
It was your subject line. (but maybe it was snipped...)
Yes, in no case is anything completely prevented.
> > (Of course, if the purpose of all this is to avoid accidental leaving
> > of all pages that have any modified form fields, then doing something
> > only on text input fields is not enough. You'd have to check for
> > modified form fields within the whole document at any PREV_DOC,
> > probably in mainloop.)
>
> No, this was not mentioned as a mean to prevent returning from filled forms.
> The problems it's designed to solve are described above by me.
Ok, so IFFORMCHANGED shouldn't be used (or be "reserved", if anyone ever
wants to do something like the above).
> > #STICKY_INPUTS:TRUE
> >
> > # STICKY_FIELDS - Input
> > # This option controls whether pressing an extra key-left in a text field
> > will
> > # activate the previous document.
> > #
> > #STICKY_FIELDS:TRUE
> >
> > The choice of option names make no sense whatsoever. Both are about
> > _text input fields_. Calling one STICKY_"INPUTS" and the other
> > STICKY_"FIELDS" is without any logic I can discover. It looks
> > completely arbitrary, you could just as well exchange them.
>
> If you read the thread carefully, I released the patch with unconditional
> behaviour. Then I asked Tom to invent the name for setting and add a line in
> LYReadCFG.c to make it configurable. I don't find the name of the setting
> very descriptive, but the description is good (I would have written
> exactly the same), thou' it should be reversed (will -> won't) to be correct.
Will -> won't doesn't make it any more (or less) correct, in my understanding
of English (which might be wrong). It doesn't say which of TRUE/FALSE has
one effect and whcih the other, either way. If you want it to say that
(and I think you should), it should be spelled out. As in many of the
good old options, "If XX is set TRUE, ...".
> >[terminology and options' names analysis skipped]
> As for terminology, it doesn't matter for me what words to use (I can use
> "trapping" or anything else - provided the definition is publically available
> and is clear). I don't know English good to invent synonims/terms - so I leave
> this task to lynx-devers and you in particluar. It doesn't matter for that the
> names of configration settings, C variables should be changed - Klaus, do it
> if you find this useful.
I really want to get rid of "sticky", problem is I don't have a really
good different name. Some were proposed
<http://www.flora.org/lynx-dev/html/month0799/msg00771.html>
(maybe more in other messages). (That's for sticky-the-1st, s-the-2nd
is going to get renamed anyway it seems.)
Below you eliminated the 'goto again' branch. That was another source
of confusion: was that meant to act differently from falling through
to 'default:' ?
> Here is a patch (mostly to point my idea on how this should be done):
[ leaving only the new lines in: ]
> @@ -640,17 +640,14 @@
> if (MyEdit.pos == 0 && repeat == -1) {
> int c = YES; /* Go back immediately if no changes */
> #ifndef NO_NONSTICKY_INPUTS
> + if (textfield_stop_at_left_edge) {
> + c = HTConfirmDefault(PREV_DOC_QUERY, NO);
>
> + } else
> #endif
> if (strcmp(MyEdit.buffer, value)) {
> c = HTConfirmDefault(PREV_DOC_QUERY, NO);
> }
> if (c == YES) {
> return(ch);
> } else {
> if (form->disabled == YES)
... and then we can get rid of the NO_NONSTICKY_INPUTS symbol completely...
> The behaviour the patch introduces:
> if textfield_stop_at_left_edge is true (controlled via STICKY_FIELDS), then
> for each extra keypress lynx will ask PREV_DOC_QUERY text
> ('Do you want to go back to the previous document?' in English) with default
> answer NO. The fact that default answer is NO means that any key other than
> corresponding to YES will mean NO (arrow-left will mean NO too).
Yes, just like before *when* it issued the prompt.
> While writing the patch, I found an incorrectness of the name INPUT_FIELDS
> and it's description. The value TRUE of INPUT_FIELDS turns on new behaviour,
> while it shouldn't according to the description, and viceversa.
YM STICKY_FIELDS(?)
> But I feel that you'll welcome the more general
> CONFIRM_LEAVE_DOC_IN_TEXTFIELD described in the middle of the message, so that
> the textfield_stop_at_left_edge will be removed, and some variable like
> confirm_leave_doc_in_textfield will be introduced.
Yes, please. :)
Except for mattack...
Klaus
- Re: lynx-dev "sticky" things, and a half-serious proposal, (continued)
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Leonid Pauzner, 1999/10/18
- Re: lynx-dev "sticky" things, Leonid Pauzner, 1999/10/16
- Re: lynx-dev "sticky" things, mattack, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- Re: lynx-dev "sticky" things,
Klaus Weide <=
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things), Klaus Weide, 1999/10/17
- Re: lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things), Vlad Harchev, 1999/10/17
- Re: lynx-dev "sticky" things, Philip Webb, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/17
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/17
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/17
- lynx-dev Siberian soldiers' time, Philip Webb, 1999/10/24