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

[Evgeniy Tarassov]

On 2/21/07, Greg Chicares <address@hidden> wrote:
> 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'.
[...]
> > 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

Yes, any of those could be used to popup the helper dialog.

> 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.

Definitly one is better than two.

We could even follow the excel developers logic and suppose that those
who use keyboard are 'tutored' (or better 'advanced') users and that
they prefer entering input sequence by hand. And those who use mouse
are 'untutored' (by default) and (by default) should be provided with
a rich interface for entering input sequence. Something like:
* if user navigates into the sequence editor with keyboard (TAB,
shift-TAB, etc.)
 => [keyboard/advanced user] => act like normal text string editor
* if user click the sequence editor with mouse pointer
 => [mouse/untutored user] => bring the rich interface (popup the dialog box)
* to allow keyboard/advanced user to access the rich interface we
could add a key-accelerator (alt-Z as you have written above)
* to allow mouse/untutored user to enter the input sequnce manually we
could "let him into" the wxTextCtrl by double-clicking the control, or
by pressing 'escape' once inside the rich-interface dialog box.

I'm sorry for a clumsy description. The only new idea is to bring the
rich-interface by a mouse-click and to use double-click to access the
underlying text control directly.

> (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.

Oh, by subclassing i ment: grouping the additional logic inside a new
class, which has wxTextCtrl as its base and could be used in places
where wxTextCtrl is needed. The idea is decouple the existing code
dealing with the data itself, plus the code rendering the dialog
containing such a field  from  the new helper control which will allow
users more effectivly enter required data. IMHO subclassing wxTextCtrl
and putting all those features into the new class does not introduce
more dependancies on wx than if we "scatter" the feature accross the
code. But maybe it could be as effectivly done by writing a custom
wxControl which will act as a container for wxTextCtrl and as a
manager for the new rich dialog window, or maybe even by putting the
code into every dialog window which contains input sequence editor
field. I think all these choices need almost the same set of wx API
methods. What i wanted to say is that weither we do one way or
another, the dependancy on wx interface is the same.

> 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?

I will ask Vadim (by phone) about that, because he is really the right
person to ask about such things, but ATM he is not easilly reachable.
IMHO such a widget could be easilly implemented by groupping a text
control and a bitmap button plus some visual sugar to glue them
together. Personally I doubt that it is a basic type of a widget and
that it should go into official WX distribution.

> These controls must be highly interdependent, and we already have a
> framework to handle that, in 'mvc_*.?pp'; I'd prefer to reuse it.
[...]
> 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.