Text inputs don't follow Haiku "live update" UI paradigm.
|Reported by:||jstressman||Owned by:||stippi|
|Has a Patch:||no||Platform:||All|
This appears to be related to the same issue being discussed in #3123 but I'm opening this as a new ticket because that one is 4 years old, denies the problem, and says it's just Playground specific when I don't believe it is. This seems to be a fundamental design problem that is affecting multiple applications and parts of the OS.
An easy way to reproduce this is to open the Backgrounds preferences and choose to manually place your background.
Change one of the X Y coordinate numbers and nothing will happen until you change focus to somewhere else (by hitting TAB or clicking in another input box etc). Only then will the Apply button become available. In fact, using ENTER to make your change "live" is even worse, as for me it applies the first change to by making the Apply button active for a split second and then activating it... when it wasn't active... and then subsequent changes DON'T work with ENTER... or even tabbing to change focus... so you end up having to click around and type different numbers in etc to get it working again... it's a mess.
This is a systematic problem that affects other applications as well. Icon-O-Matic for instance is doubly affected by this in the color switcher... when entering a hex color the color isn't changed until you change focus... and if you're changing to one of the RGB numbers to get the HEX color to register, the RGB number you switched focus to ALSO won't change until you change focus from THAT one as well... so it takes 2 focus changes to actually have everything display correctly.
The correct behavior would apparently be to announce the change as soon as it happens and make the appropriate updates per keystroke or whatever. So as soon as you change the number, the option to Apply it becomes available (and the location in the preview image changes etc), or in the Color Picker the updated color and correct related numeric value fields would be shown, etc... perhaps after a tiny time out so that unnecessary processing isn't done that jams things up.
Is there some reason why the default behavior should be this unintuitive across the board, leading to further problems in many places like this? It would seem like the default behavior should be a "live update", and only in special cases would you want to manually force an update by making the user do extra work.
The only cases where I can see a user NOT wanting to see a live update of their changes is something where it would be very CPU intensive to recalculate something based on those changes. And for something like that it would seem better to make that the case where the programmer would need to say "DON'T live update this" rather than a default live update behavior.
All this seems even more the case considering that the rest of the OS UI seems focused on a paradigm of live updating without requiring extra work to apply changes etc. Correct? That makes this behavior really unintuitive from my perspective and in conflict with the rest of expected UI function of the OS.
BUT... I'm not a programmer, so take that as you will... but having to do all this focus changing throughout Haiku to work around this problem is unintuitive and unpleasant from a user perspective, and apparently is just as unintuitive for other programmers because it seems so overlooked and problematic at the moment.