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

[Greg Chicares]

On 2007-2-23 13:08 UTC, Evgeniy Tarassov wrote:
> 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
[...]
>> > 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.

The part I dislike is that it's only "nearby", but not
contiguous.

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

Okay. My thinking evolved as I wrote that message, and I'd tend
to favor a pushbutton embedded in a textcontrol.

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

And, OTOH, wxSpinCtrl is perceived as a single control. What we're
talking about here can be, too, as long as we keep its parts as
close together as wxSpinCtrl's textcontrol and spinbutton are.

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

Few if any of our end users use the keyboard, though I prefer it.
(A few years ago, I unplugged the mouse from the computer in my
office; this confounded the tech-support staff.) I guess you're
saying that ms 'excel' has an 'untutored' interface for mouse
users that differs from its keyboard interface; I was never even
aware of that, though I've used that application extensively.

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

Clever, but perhaps a little too complicated. We might find
that we have some "untutored" users who generally avoid the
keyboard but do use the Tab key. The more I think of ideas
like this (or the ones I suggested initially), the more I
favor a pushbutton embedded in a textcontrol. (We could
still provide a keyboard alternative for those whose mice
are unplugged.)

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

All right--then we're talking about two somewhat different things.

I've seen applications that never use any standard widget from
their GUI library. They have a MyTextControl, a MyComboBox, and
so on, all with altered behaviors that range from the exotic to
the downright funky, and implementations that are often dubious,
poorly tested, inscrutable, and unmaintainable. That's the
outcome I want to avoid; and one way to avoid it is to harbor an
extreme prejudice against subclassing any library control in the
application itself.

But I'd entertain the idea of doing it here, in this one case,
if I can't persuade the wx maintainers that such a control
belongs in the library itself.

> 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'm not at all concerned about lmi's GUI depending on wx: I made
that decision years ago, and have never regretted it.

If wx wants a textcontrol-with-dialog-button in wx, then it makes
no difference to me how it's implemented: I'd just use its
published API.

If we do it in lmi, then I'd want to participate in the design;
for instance, I don't think this:

> putting the
> code into every dialog window which contains input sequence editor
> field

would work: lmi doesn't use a "RAD" paradigm where each dialog
would be associated with some code specific to that dialog. But
we can cross that bridge when we come to it.

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

In ms 'excel', the button is actually inside the textcontrol.
But contiguous is as good as inside: that's the way wxSpinCtrl
does it.

> Personally I doubt that it is a basic type of a widget and
> that it should go into official WX distribution.

I can't make a better case for it than I already have by noting
that a popular spreadsheet program uses it in more than one
place--and that it could be beneficial in other cases like

>>   http://validator.w3.org/
>> with its "Local File:" textcontrol and a "Browse..." button nearby.

which also arise, for instance, in Mahogany:

 - "Message Composition":
    - "To"  field has an "Expand the address" button
    - "Fcc" field has a "Browse for folder" button

 - "Properties" has several textcontrols with ">>" browse buttons
     in its "Access", "Identity", "New Mail", "Compose", "Folders",
     and "Helpers" topics, and ">>" font- and color-selection
     buttons in its "Message View" and "Folder View" topics

so this might be more generally useful than it at first seems.
But that is for the wx maintainers to decide.