"Find File" dialog tab order

[curtis]

From the "Search for content" checkbox, when it's checked, pressing the down-arrow should move focus down to the "Regular expression" checkbox below it. Instead it moves left which is wrong.

GNU Midnight Commander 4.7.5
Built with GLib 2.24.1
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

[andrew_b]

Replying to curtis:

From the "Search for content" checkbox, when it's checked, pressing the down-arrow should move focus down to the "Regular expression" checkbox below it.

It's impossible. MC widgets system don't provide change of widgets order in runtime.

[curtis]

Then at the least, the static ordering should be changed to avoid all the jumping around.

Attached are two possible tab reordering solutions.

The first patch still keeps "Content:" input right after "File name:" input, but it also keeps all the content checkboxes together at the end of the dialog tab order.

The second patch is even more organized, all filename checkboxes are immediately after it. And all content checkboxes are immediately after it. The only caveat here is that you have to tab past all the filename checkboxes to input on the content search.

[curtis]

group all content checkboxes

[curtis]

both checkbox groups with their input

[andrew_b]

mc-find-dialog-tab-order1.patch

This patch introduces a long distance between 'Content' input field and 'Search for content' checkbox. This is uncomfortable for those people who often enables and disables search for file content.

mc-find-dialog-tab-order2.patch

This patch introduces a long distance between 'File name' input field and 'Content' one. We had such way in first redesign of this dialog. Users dislike it. Details see in #1375 and #1385.

We discussed a lot about this dialog design. Current layout is compromise decision between a lot of options in dialog at first side and easiness of usage and user's habits at second one.

[curtis]

Apologies, I missed the prior debate. But this looks like one of those cases where the compromise is worse than each of the alternatives. :-(

I guess it boils down to each individual user's workflow...

Even though I use it mostly, I don't mind that the 'Search for content' is disabled by default. Once I've enabled it, the setting is saved, and now I expect each successive find to streamline access into the 'Content' field *and* it's associated checkboxes. In my case, I'm constantly twiddling with case-sensitive and regular expression type searches below.

I only occasionally change the 'File name' from * to maybe *.py or *.c and then back again to just *.

The problem here is that every time I edit the 'Content' field, I have to tab past all the left/right jumping to the fields below it. I actually wouldn't mind the extra tabbing, if they behaved *consistently* moving downward instead if jumping left/right.

If there's interest, I can try and propose some rework of the entire dialog?

[zaytsev]

Of course you can think about it and suggest mockups patches etc. This would actually be great :-) Just don't be mad at us if we come up with hundred reasons for not integrating these changes. Unfortunately there are so many use cases, that it is really hard to please everyone.

[andrew_b]

Ticket #3451 has been marked as a duplicate of this ticket.