Re: [lmi] tasks 2007: bug 104480: input-sequence editor

[Greg Chicares]

On 2007-2-16 12:24 UTC, Evgeniy Tarassov wrote:
> Pop up alternative input-sequence editor
> http://savannah.nongnu.org/support/?104480
>    'Input sequences' are a 'little language' for data that vary by
>    year. A $5,000 yearly loan after retirement might be entered as
>    0 retirement; 5000
>    in a text control. Some users don't want to master that language,
>    and would prefer a pop-up dialog for each vector field like this:
> 
>    labels: value from-duration to-duration
> 
>    controls: textctrl spinctrl spinctrl
> 
>    with the 'controls' repeated for each of a variable number of
>    intervals. Alternatively, the 'controls' might be cells in a
>    grid control. The 'values' might be a floating-point number,
>    a constrained list of strings, or both: for example, a premium
>    field must accept 'minimum' as well as '12345.67'. Similarly,
>    a 'duration' could be an integer or a string like 'retirement'.
> 
> Please correct me if i'm wrong: this task is about designing and
> coding a standalone widget for editing 'input sequence' expressions.
> It should be an extended wxTextCtrl which allows ( to click on some
> additional little button near its text area, which will open a dialog
> box for) editing input sequence using a grid or a sequence of control
> groups.

That's correct. There's only one point that I'd like to see if we
can handle differently:

> It should be an extended wxTextCtrl which allows ( to click on some
> additional little button near its text area, which will open a dialog

I envision that idea as something like this page:
  http://validator.w3.org/
with its "Local File:" textcontrol and a "Browse..." button nearby.

Could the dialog be triggered by some other means instead? E.g.:
 - double-clicking, or
 - a right-click handler (I think msw calls that a "local menu"), or
 - a keyboard accelerator, e.g., alt-Z

Here are my reasons for seeking some such alternative:

(1) Even though it's one control object, end users perceive two:
a textcontrol, and a separate pushbutton whose purpose may not be
immediately obvious. If the controls are separate, then the GUI
may appear unnecessarily cluttered. Of course, my alternatives
above aren't obvious, either; but if there's no implementation
that's immediately obvious to an untutored user, then an option
that involves fewer GUI elements seems preferable, IMO.

(2) I have a perhaps-unreasonable prejudice against subclassing
standard controls. Extensions that are implemented in wx itself
will be maintained; local extensions are fragile and may break
when wx changes, and lmi already has too many fragile things
like that.

I see something like this in ms 'excel', in at least two places:
  Tools | Options | Custom Lists | Import list from cells
  Format | Conditional Formatting
where a button is embedded within the textcontrol, at its right end.
They use a bitmap button that seems somewhat "obvious" once you
understand what it does. And our users are typically familiar with
that spreadsheet already, so maybe that's the best solution. Would
a control like that be generally useful to the wx community?

> Plus an Xrc handler should be provided to be able to integrate this
> widget into existing dialogs via xml-resources.

These controls must be highly interdependent, and we already have a
framework to handle that, in 'mvc_*.?pp'; I'd prefer to reuse it.

Example: suppose you want to pay
  $10,000 for one year, then
    2,000 for three years, then
        0 thereafter.

We could depict that as

     Value          From           To
  [textcontrol] [spincontrol] [spincontrol]
     10000            0             1
      2000            1             4
         0            4          maturity

The second "From" duration mustn't be less than the first "To"
duration. (Maybe we should eliminate the "From" column: it's
superfluous as long as we require the intervals to constitute
a partition of the timeline.) And the second "To" duration
certainly can't be less than the first "To" duration.  We'll
encounter cases with various constraints: e.g., where "Value"
must be zero after the first duration, or where "Value" can
decrease over time but must not increase.

The most straightforward approach is to use the 'mvc_*.?pp'
framework with discrete controls, because that's the way that
framework works today. However, we may potentially have one
hundred subintervals, and that would require an awfully large
number of controls, so I guess a grid is the only solution that's
really suitable. In that case, I'd like to extend the 'mvc_*.?pp'
framework to handle cells in a grid as it now handles separate
controls.