[lmi] Textcontrol with browse button [Was: tasks 2007: bug 104480: input-sequence editor]

[Greg Chicares]

On 2007-3-6 0:09 UTC, Vadim Zeitlin wrote:
> On Fri, 23 Feb 2007 14:59:07 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> >> I envision that idea as something like this page:
> GC> >>   http://validator.w3.org/
> GC> >> with its "Local File:" textcontrol and a "Browse..." button nearby.
> GC> 
> GC> The part I dislike is that it's only "nearby", but not
> GC> contiguous.
> 
>  Actually the problem is that visually this button is too big and not
> grouped together with the text field.

You are quite right. In the 'validator.w3.org' example, the textcontrol
and the "Browse..." button actually are contiguous: there is at most one
single pixel between them. But I *perceived* them as noncontiguous. The
three-dimensional highlighting on the top and left sides of the button
is white, the same color as the background, and maybe that contributed
to my perception, even though at worst that makes it look like two pixels
of separation.

I agree that the "Browse..." button is too big. And the "Check" button
next to it is too close. Maybe both those factors contribute to our
both experiencing it as not "grouped together with the text field".

> I think that the important thing is
> that the button and the text field should be seen as a single control, not
> that they should necessarily be superimposed. For example, look at the
> picker controls in the wxWidgets widgets sample: IMHO they provide a
> relatively clear and familiar UI for the tasks similar to the one at hand,

I'm looking at the "FilePicker" example there, under "Pickers", and
to me it looks much like the 'validator.w3.org' example, except that
the textcontrol and "Browse" button are farther apart in the wx sample:
I measure it as five pixels. Unlike you, I perceive them as two separate
and distinct UI elements. Making the button smaller, as in the color-
picker example, doesn't change my perception of it as two elements.

[I'm still using a wxWidgets-2006-12-04 snapshot, but I would guess
that the final release doesn't differ in this respect.]

What I'd really like is a paired control that can only be seen as one
indivisible unit. I think the wx date picker achieves that in the best
way because of the way its shading works: it's shaded as one unit.

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

Permit me to disagree with myself in light of the foregoing discussion.

Look closely at the way shading works:
  wxSpinCtrl:        textcontrol  and spin buttons are shaded separately
  wxDatePickerCtrl: "textcontrol" and spin buttons are shaded as a unit

[The main part of wxDatePickerCtrl isn't really a textcontrol: it looks
like one, but doesn't behave like one.]

[I don't see a wxSpinCtrl in the wx 'widgets' sample, so I'm looking at
these two particular controls in lmi. I don't think that makes any
difference, though.]

I have a new theory--that I perceive wxSpinCtrl as an indivisible unit
not because of its visual appearance, but merely because of convention:
my perception is guided by my familiarity with paired spin controls in
other situations.

But wxSpinCtrl, I would now say, doesn't have a native appearance on
msw, because it's not shaded as an indivisible unit. In this respect,
it differs from the native spincontrol that the same application's
"Print" dialog uses for "Number of copies"--that particular dialog
being provided by the OS, IIRC.

> GC> If wx wants a textcontrol-with-dialog-button in wx, then it makes
> GC> no difference to me how it's implemented: I'd just use its published
> GC> API.
> 
>  Currently wx has wxPickerBase which can be used to easily implement a
> control containing (separate) wxTextCtrl and wxButton. If we really want to
> have a button embedded in text control, we'd need to do it ourselves. This
> could be interesting/useful but it will definitely be more time consuming
> too.

Here, we're using several terms for what might be the same concept.
I'm beginning to see "shaded as an indivisible unit" as the crucial
thing; do "embedded", "superimposed", and "inside the textcontrol"
mean precisely the same as that?

> GC> In ms 'excel', the button is actually inside the textcontrol.
> 
>  FWIW, the control used by Excel is not a text control at all (quick way to
> see it: press the right mouse button in the control, you won't see the
> familiar text control popup menu), but a custom control which draws the
> button (which is not a standard button neither) itself.

Okay. I'm interested only in its "shaded as an indivisible unit"
behavior, and not the ways in which its components are customized.

> GC> so this might be more generally useful than it at first seems.
> GC> But that is for the wx maintainers to decide.
> 
>  I definitely agree that functionally speaking such control is useful and
> so we could add some wxCustomPicker class deriving from wxPickerBase to wx
> to make it possible to create such controls even easier. But I'm not sure
> if it's worth the hassle to try to put the button inside the text control
> at any price.
> 
>  Please let us know what do you think about this, thanks,

If "inside the text control" and "shaded as an indivisible unit" mean
exactly the same thing, then I'd like to persuade you that it might
actually be worth doing--not just for the extended textcontrol we're
talking about, but also for wxSpinCtrl, which I would now suggest does
not achieve a pure native appearance on msw.

I guess I should first ask whether you agree with my observations above.