Opened 16 years ago
Last modified 4 years ago
#3123 in-progress enhancement
Playground: improve text entry boxes/fields refocus
Reported by: | nutela | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1.1 |
Component: | Applications | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #8883 | |
Platform: | All |
Description (last modified by )
# how to reproduce
Start Playground, change colour of object by entering a new value in Red, Green or Blue, click and drag onto the drawing field to make a new object
# experienced behavior
Colour is not changed unless we refocus on something else. No new object can be made because input text field blocks refocussing but this might be due to Playground itself
# expected behavior
When changing values in text entry boxes, they should take the values and update in a short time out when there is no keyboard input in a short period of time or any other more 'elegant' sollution.
Change History (8)
comment:1 by , 16 years ago
Component: | User Interface → Applications |
---|---|
Status: | new → assigned |
comment:2 by , 16 years ago
Still I find this unintuitive and I might add that I've had this problem at work as well. We develop GUI's in Java and there too happens something similar that you have to go out of the text entry box to let the newly entered text to be taken into account. Usually this is not a problem because there is an 'action' button which when clicked upon activates the required action.
In BeOS and Haiku however we don't have such buttons because we think they are not necessary but I can point to a few places where this 'design philosophy' doesn't really work right. One example is the BTextControl mentioned. A similar example is the slider control in Appearance, I could imagine that someone doesn't let go the mouse button and by this no update will take place. In this case it is really a minor problem but it is different behaviour then that from say Gobe Productive where you can manipulate sliders and after short timeouts the screen redrawing updates without the user having to let go of the slider control. Of course the redrawing is interupted after a certain short interval when ever a new change is made by moving the slider control.
So I think the current Haiku behaviour goes a little bit against the philosphy that the UI is 'live'.
comment:3 by , 16 years ago
As I have tried to explain, those are problems of the respective applications, not Haiku's system libraries. If you still don't believe me, BSlider and BTextControl have a method SetModificationMessage(). If the application does not set it, the controls will deliver the normal "value changed" message when the user confirms his changes (pressing Enter in a BTextControl, releasing the mouse in a BSlider). Focus changes are another way, at least for BTextControls, to trigger the final value changed message, since it's impossible for the user to still modify the text.
If a modification message is set, both the BSlider and the BTextControl *will* send a message for every small live change. For most applications, they wouldn't not make sense to generate and process. In the example of Appearance, it *could* process the last modification message after a timeout. The reason is that the app_server has to discard the complete font cache for every font visible on screen when the filter level changes. So this operation is something *very* heavy under the hood.
In the case of Playground, it simply uses the wrong controls. For colors, we have BColorControl, but at the time this part of Playground was written, I was happy it worked at all, and right now there is still more important stuff to worry about. That's why I simply changed the component of your bug report, because I agree it's a problem (in Playground). As I have previously written, there are quite a few applications that make such GUI mistakes, and you have provided more examples.
However, please believe me that it's not a problem of the libraries or the controls.
comment:4 by , 16 years ago
Summary: | improve text entry boxes/fields refocus = update mechanism → Playground: improve text entry boxes/fields refocus |
---|
OK point taken. Thanks for the explanation. I am happy that it already works so well but I didn't see the code, if I saw it I wouldn't understand and therefore I assumed the wrong things. Maybe Playground will really inspire people (I already am) what Haiku is capable of therefore I changed the Summary. From now on this is a Playground enhancement request, I hope you agree.
comment:5 by , 10 years ago
Blocking: | 8883 added |
---|
comment:6 by , 10 years ago
I think there is an actual OS problem here after all.
- Start playground
- Draw a (mostly blue) object
- Select the green text control and type 255. Existing object is not changed.
- Click "new object"
- Draw another object
The click on "new object" should invoke the textcontrol, but doesn't, because it keeps keyboard focus (the button can't be focused it seems). So, the second object is still blue. This can be solved in Playground, but it sounds like it should be the default behavior to invoke the text control as soon as another item in the window is closed, at least?
comment:7 by , 4 years ago
Description: | modified (diff) |
---|
comment:8 by , 4 years ago
Milestone: | R1 → R1.1 |
---|
This is a Playground problem though, not something general with the BTextControl. Though a few apps make this mistake.