Arvin suggested to add `opt(`immediate) to the tree widget, too.
This is now implemented.
`opt(`immediate) is an optimization for the NCurses UI: It makes a widget that
has `opt(`notify) set return immediately when its value changes. Normally,
the NCurses UI holds such changes back until a special key (typically
[Return]) is pressed. For the other UIs (Qt, Gtk) there is no difference
between `opt(`notify) and `opt(`immediate) (`opt(`immediate) implicitly also
sets `opt(`notify)).
Rationale:
item-01
*item-02*
item-03
item-04
item-05
"item-02" is selected. If you want to select "item-05", in the NCurses UI you
have to move the cursor down several times, selecting "item-03" and "item-04"
before you can get to "item-05".
When `opt(`notify) is set, that widget will make UI::UserInput() return for
every event, i.e. the YCP application will receive a ValueChanged event from
that widget for "item-03" and "item-04", too. If the YCP application performs
expensive operations (like exchanging the items in another list in the same
dialog), this can have a considerable performance impact.
With this changed behaviour, by default the NCurses UI will not make
UI::UserInput() return for "item-03" or "item-04", only when the user hits
the [Return] key after he moved the selection to "item-05".
With `opt(`immediate), the application will still receive the events
for "item-03" and "item-04".
For the Qt or the Gtk UI, the application will always receive all events since
the user can easily select "item-05" right away with the mouse without having
to go through "item-03" and "item-04".
Until now, the YSelectionBox and the YTable widgets behaved like this. Now,
also the YTree widget behaves like this.
Where this is not desired, please change `opt(`notify) for affected tree
widgets with `opt(`immediate). But in normal cases, NCurses users will
probably prefer better performance.
CU
--
Stefan Hundhammer