#8883: Text inputs don't follow Haiku "live update" UI paradigm.
------------------------------+----------------------------
Reporter: jstressman | Owner: stippi
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: User Interface | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
------------------------------+----------------------------
Comment (by stippi):
There is a short version and a long version of my reply...
The short version is this: This cannot be fixed on a system-level (i.e.
inside BTextControl or BTextView), and the problems you mention need to be
fixed at the application level, in each individual application. Really.
The long version: Consider the examples you gave: Inputting the placement
of the desktop background, changing the color in Icon-O-Matic...
BTextControl has no idea what makes valid input. Suppose your background
is currently located at 510 pixels to the right. You want to change that
to 515 pixels. Suppose you do that by deleting the last number, so the
input now reads "51". Your computer is most likely fast enough to quickly
render the preview at 51 pixel horizontal offset. Shortly after that, you
enter the 5, and now the background is showing at 515. Suppose you enter
"515" by clicking into the text field, focusing all text and overwriting
the selection with 5, 51, and finally 515. So your background would jump
from 5, then 51 to finally 515 pixels offset. I consider that visually
irritating, especially since your attention should be on the text input.
Consider Icon-O-Matic. The same problems apply there. Should the color
preview go almost black, since you entered "2", then a dark grey, since
you entered "23", then switch to almost white since you finally entered
"230"?
Both of these apps *should* register for text modifications, and adopt the
changed input *after a short delay*. Probably an application specific
delay, even.
Why can't the BTextControl send the value changed message after a short
delay in all apps? Consider the following use case: You rename a file in
Tracker. Renaming can be a destructive operation. If you enter a name
already taken by another file, Tracker asks you if you want to overwrite
that file. Imagine you enter a new file name, where the first part of the
name matches the name of another file. During entering the name, you make
a short pause to think. But that's already enough to trigger the universal
delay. Tracker wants to apply a live preview, but that results into asking
you whether you want to overwrite the other file... Maybe this is an
exception to the "rule" of when to apply changes live, but BTextView or
BTextControl cannot know the context in which they are used, so they
cannot send the same message which normally means "input finished" shortly
after the last keypress.
BTW, I have recently worked with SWT, which uses native platform widgets
on all platforms. There, too, text inputs work the exact same way as in
Haiku. The programmer can register for "modified" events, sent after each
key press, and input is usually considered done, when the focus changes
outside the text input, or the user pressed enter.
That being said, I think we could reduce the problem by adding optional
functionality to BTextView where it can send a "text changed" event after
a short delay after the user last pressed a key. That would be in addition
to the "text modified" event that applications can already register for
(sent for every key press) and the "value changed" message of
BTextControl, sent after "enter" or "focus out".
Obviously this still means each individual application needs to be changed
to make use of this new feature. And all it saves is implementing the
"delay after last key press" in each app. It would certainly be worthwhile
to do that and to fix the problems that you mention.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8883#comment:2>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
