https://bugzilla.novell.com/show_bug.cgi?id=382755
shows that it might be useful to add a timeout to the ComboBox widget so it
holds back events when many (keyboard) events occur in a short time frame.
Our SelectionBox widget and (since some weeks) our tree widget behaves in that
way: When you go through multiple items in a short time, only the last event
gets delivered, not all the intermediate events. This can make cursor key
navigation (or dragging with the mouse) in such a SelectionBox or tree much
more useful: When expensive operations are performed at each such event and
only the last of those events is meaningful anyway, the intermediate events
are not delivered, so they don't have any impact on performance.
Example:
+-------------
| [Item 001] |
| Item 002 |
| Item 003 |
. ... ... .
. ... ... .
| Item 999 |
+------------+
Keeping "cursor down" pressed until "Item 999" is reached would not make
UI::UserInput() or UI::WaitForEvent() return for "Item 002", "Item 003",
etc.; only for "Item 999".
See also
http://svn.opensuse.org/svn/yast/trunk/libyui/examples/SelectionBox2.cc
for a UI example that allows experimenting with that (use the "notify"
and "immediate" check boxes and watch the "value" field as you keep cursor
keys pressed in the SelectionBox or drag the mouse there).
This behaviour usually useful, but it comes at a cost: An event is always only
delivered after the timeout is expired. The Qt UI uses 200 milliseconds (the
same as the mouse double click interval), so it's not too bad, but it can
make an application appear less responsive.
That's what `opt(`immediate) is for for SelectionBox and tree widgets. By
default, the 200 millisecond timeout is used (for those widgets, not for
everything), but with `opt(`immediate), the events are delivered immediately.
But in that case, you will also get events for each of "Item 002", "Item
003", etc. - that's the tradeoff.
Now here is the question: Can we safely add this to ComboBox widgets, too?
Right now, events are delivered immediately, i.e., it behaves as if
`opt(`immediate) were set, too.
Should we add the timeout, the default behaviour would change: There would be
the 200 millisecond timeout with `opt(`notify). Application developers (YCP
hackers) that don't want this behaviour for whatever reason would have to add
`opt(`immediate).
Another factor are editable ComboBox widgets. I am unsure how they should
behave. Remember, with `opt(`notify) you get individual key presses (just
like in InputField / TextEntry), and delaying them, too, might result in odd
application behaviour (or wouldn't it?). Would we want that timeout behaviour
there, too? Or would we just do it for non-editable ComboBox widgets?
Opinions?
Problems with such a change?
Anything I overlooked?
CU
--
Stefan Hundhammer