[haiku-development] Re: RFC: B_INVALID flag for BControlLook
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 7 Oct 2014 15:13:06 +0200
On Tue, Oct 07, 2014 at 02:43:21PM +0200, Axel Dörfler wrote:
> Hi Adrien,
>
> Am 01.10.2014 11:07, schrieb Axel Dörfler:
> >Having controls that only accept digits is pretty standard after all,
> >and is found pretty much everywhere else in such situations. You have a
> >cursor that blinks in that control. You hear a beep sound when you type
> >invalid characters. What more do you want? Of course, a tool tip could
> >be shown in that case, too, but I don't really think that would be
> >necessary.
> >I don't think a red text would be that much more helpful in any way either.
>
> You seem to have missed this argument, and went ahead with your
> implementation.
> Care to comment or discuss this?
Stippi already answered you: the beep may not be heard (because there is
no soundcard or the user is deaf, or because we still don't have a
default sound theme anyway).
He also mentionned that he had another use for the "invalid" flag and
red border, and I think I mentionned some possible uses myself. We may
want to validate complex expressions (eg. watchpoints in a debugger),
phone numbers, e-mail addresses, or other things, and in all these cases
simply rejecting characters isn't enough.
Even in the case of numbers, filtering the characters is not enough as I
already mentionned. If you allow "-0123456789." as keyboard input, the
user can still type "--0..0--9" which isn't a valid number. So, even if
we decide to restrict the allowed characters, we still need the extra
validation. You can't have a smarter validation only by rejecting input
without hindering user experience a lot. For example, let's imagine you
want to enter "-2" in the spinner. You start with an empty text input
and press the "-" key.
Two things can happen:
- We decide to allow the keystroke. At this point, you move the focus
elsewhere and the field is left with just "-". We can parse this as
"0", but it seems better to warn that you may have forgotten to enter
some digits
- We decide to reject the input because it would lead to an invalid
number. To enter "-2", you must press "2", then "-" (or left then
"-"). Does not sound like the right thing to do
Likewise, if a number is supposed to be between 0 and 255, and you enter
366, upfront filtering results in a confusing user experience (what should we
do? ignore the second 6 and beep?)
So I implemented the flag to show a red border in these various cases.
It doesn't prevent also restricting the user to some character ranges by
means of a filter function. I haven't implemented it yet because it
deserves some more discussion.
Should we limit it to char-by-char filtering? That may be enough if we
also have other means of marking the field invalid (now we do). Are
there cases where we want to allow a "smarter" filter function, which
would also take into account what's already in the field? How does the
filter function signal the problem to the window? (we need that if we
want something better than just a beep to happen)
--
Adrien.
Other related posts:
