RFE: implement an option to initially select a row (set cursor) in the list
Yet Another Dialog
Brought to you by:
v1c0nt
Menu
▾
▴
#330 RFE: implement an option to initially select a row (set cursor) in the list
Currently cursor either appears on the first row of the list filled by command line, or just missing in the list filled by stdin.
As itself, lists are a convenient alternative to the combo box for cases with a large number of values. However, the impossibility of setting the initial choice makes their use for these purposes difficult.
There is a workaround, using --add-on-top and splitting input to both stdin and cmdline.
Consider the case when you need to preselect 5th value in a list of 8 values. The solution is:
echo -e '444\n333\n222\n111' | yad --list --column=a --listen --add-on-top 888 777 666 555
but the selected row always appears at the top of the window, which might confuse users as to whether there is something above the top or not.
The proposed patch introduces two list options: --preselect-value=TEXT and --preselect-column=NUMBER .
Each row is checked on input, and if it has a column (default first, altered by --preselect-column) with the value specified (TEXT), cursor is pointed to this row and the list is scrolled properly. This selection is made only once, independedly of the type of input (stdin and/or cmdline).
It is a most convenient way just to use a column text matching, since users always know an exact value they want to select, rather than want to calculate something extra.
For some complex cases (identical rows etc.), users can utilise an additional hidden column.
A simple example:
Implementation details:
src/list.c:yad_list_add_row() now returns the row created (insted of void). It then used for set cursor and scrolling.
Scrolling is to the center of the list (ie. a factor of 0.5). There are some little issues here:
"stdin" + "add-on-top":
All works fine.
"stdin" + normal bottom add:
Due to gtk3 implementation details, at the time of set_cursor the correspond row is "last" and "bottom", and there is nothing below it. Gtk3 tries to avoid such a "nothing", and actually scrolls the row down (as for the factor of 1.0). Thus an additional scrolling is needed later, after the input read is end.
Gtk3 code, spoiles things, is two lines here .
It won't be good to leave row bottom, as it confuses users about presense of data below.
It is better to perform the first scrolling anyway, as it fixes the list and avoids extra changes on the visible area in a case of too big input.
"cmdline" cases:
All works fine, except the fact that at the time of the list filling, the actual window size is still unknown. Thus, scroll performs on a default sizes, which seem to be to provide about 3 rows in the visible area. As a result, the selected row is always one step below the top (instead of the center of the list).
OTOH it is an acceptable result, rather then to be completely on the top.
Chanes for manual included as well.