[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev "sticky" things
From: |
Vlad Harchev |
Subject: |
Re: lynx-dev "sticky" things |
Date: |
Sat, 16 Oct 1999 18:13:35 +0500 (SAMST) |
On Sat, 16 Oct 1999, Klaus Weide wrote:
> On Sat, 16 Oct 1999, Vlad Harchev wrote:
> > On Sat, 16 Oct 1999, Klaus Weide wrote:
> > > I suggest to change some details:
> > > On Sat, 16 Oct 1999, Vlad Harchev wrote:
> > >
> > > > CONFIRM_TEXTFIELD_PREV_DOC:NEVER|IFEDITED|ALWAYS
> > > >
> > > > If value is NEVER, PREV_DOC_QUERY will be never asked,
> > > > IFEDITED - old behaviour
> > > > ALWAYS - ask always.
>
> I have an addition to propose: IF_NOT_EMPTY.
> If the field is completely empty, the Left Arrow keystroke was most likely
> not meant for moving around within the field. (It wouldn't make sense.)
> Most fields in pages are not pre-filled with anything (in my experience),
> so they wouldn't "trap" unless one had started to edit.
> If the field is empty, there is no edited data to lose (in this field anyway).
> It seems to be a better heuristic than the one used now (IFCHANGED /
> IFEDITED). It protects against more cases of accidental leaving.
>
> Does it make sense?
Yes, I like it.
> > > PREV_DOC instead of LEAVE_DOC - well, it's already the name of the key
> > > action
> >
> > IMO such name collision is unimportant and shouldn't scare. And I find the
> > name I suggested - CONFIRM_LEAVE_DOC_IN_TEXTFIELD - to be more descriptive
> > to
> > russian-speaking users at least :)
>
> I strongly prefer *_PREV_DOC_* over *_LEAVE_DOC_*. Or propose to
> rename the PREV_DOC key to the LEAVE_DOC key, too.
I think your preference of _PREV_DOC_ over _LEAVE_DOC_ just because there is
a key action with the same name. IMO when user tries to guess the option
meaning, the names of key actions belong to different domain:) I prefer
_LEAVE_DOC just because LEAVE is a verb and a noun, while PREV is neither of
them (subjunctive?) and make less sense. This is a thing the lynx-devers can
vote for (ie voting for name).
> Ignore all my other changes as you prefer, but consistency should have
> some value.
We both try to be consistent, but we have different POVs/understandings.
> > > no IFFORMCHANGED - that would seem to indicate that we check whether
> > > the form as a whole (any field) changed.
> >
> > I have a feeling that you don't wish to write the function that checks
> > whether the form has changed - am I right? Seems such function is already
> > present: GridText.c:HText_HaveUserChangedForms. What do you think about it?
>
> Hmm, feature "bloat"? or "feature creep"? :)
I hope you don't critize its existance :)
> I don't know whether it would be useful. Maybe it is.
>
> But that function checks *all* form fields in the current page. So
> it should be IFFORM*S*CHANGED.
This is exactly what is required. Yes, name should be IFFORMSCHANGED
But I don't know, may be we should substitute the strings with numeric
codes?
> > > 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.
> >
> > I don't understand your comment about IFEDITED.
>
> I was thinking about a Reset action for example, which does a
> "change" that consist of changing back to the "unchanged" value.
This doesn't make things clear to me, but seems it's idealization again...
> But nevermind.
>
> Klasu
>
PS: I will write the code tomorow (ie 12 hours later - I try to sleep at
nights - unlike you). Sorry. You can write the code if you wish.
Best regards,
-Vlad
- Re: lynx-dev "sticky" things, and a half-serious proposal, (continued)
- 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, 1999/10/16
- 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 <=
- 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
- Re: lynx-dev Siberian soldiers' time, Juan-Carlos Lerman, 1999/10/24
- Re: lynx-dev Siberian soldiers' time, Vlad Harchev, 1999/10/24
- lynx-dev coding style, ifdefs, Klaus Weide, 1999/10/16