Re: [lmi] Input-sequence editor integration

[Greg Chicares]

On 2010-07-03 10:24Z, Vaclav Slavik wrote:
> In Sat, 2010-07-03 at 09:46 +0000, Greg Chicares wrote:
>> I'm not sure whether the small amount of extra information will be
>> useful in the GUI 
> 
> It is useful, and is already used:

Yes, and I'm adjusting and testing the whole patch in a local copy
at the same time as I'm committing layers of it piecemeal. But my
real goal is to understand everything. Your comments are helpful
to me (and, I believe, to our testing and support staff): I hadn't
yet seen that every possibility is covered, though now I do.

Here's the way I formulated it, with '*' marking possible cases:

* (1) keywords  forbidden, numbers acceptable
  (2) keywords acceptable, numbers acceptable, and [choose one]...
*     (2a) keywords     blocked
*     (2b) keywords not blocked
  (3) keywords acceptable, numbers  forbidden, and [choose one]...
      (3a) keywords     blocked [IMPOSSIBLE]
*     (3b) keywords not blocked
  (4) keywords  forbidden, numbers  forbidden [IMPOSSIBLE]

and that maps correctly to your formulation, which considers three
outcomes corresponding in order to my (1 or 2a), (2b), (3b):

> * If the keywords list is empty ("keywords forbidden"), a regular
>   wxTextCtrl is used.
> * If the keywords list is not empty, wxComboBox is used.
> * If keywords_only() ("numbers are forbidden"), the the combo box is
>   read-only, disallowing entry of text not in the list.

Thus, an end user might ask: "why can't I enter 'glp' as the payment
in some circumstances, when I can in others?" and the answer would
be that the behavior of (1) is used in circumstance (2) when condition
(2a) prevails. We wouldn't use quite those exact words, but we might
say "You can't choose 'glp' or any other payment strategy because you
elected to solve for payment, and the solve overrides any strategy".