Opened 11 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
Component: Applications Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #8883
Has a Patch: no Platform: All


# 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 (6)

comment:1 Changed 11 years ago by stippi

Component: User InterfaceApplications
Status: newassigned

This is a Playground problem though, not something general with the BTextControl. Though a few apps make this mistake.

comment:2 Changed 11 years ago by nutela

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 Changed 11 years ago by stippi

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 Changed 11 years ago by nutela

Summary: improve text entry boxes/fields refocus = update mechanismPlayground: 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 Changed 4 years ago by pulkomandy

Blocking: 8883 added

(In #8883) A list of other affected apps would be appreciated. Adding #3123 as a first "blocker" for this ticket.

comment:6 Changed 4 years ago by pulkomandy

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?

Note: See TracTickets for help on using tickets.