Ticket #2488 (closed defect: wontfix)

Opened 6 years ago

Last modified 20 months ago

"Find File" dialog tab order

Reported by: curtis Owned by:
Priority: minor Milestone:
Component: mc-core Version: 4.7.5
Keywords: Cc: zaytsev, gotar@…
Blocked By: Blocking:
Branch state: Votes for changeset:

Description

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;

Attachments

mc-find-dialog-tab-order1.patch (1.3 KB) - added by curtis 6 years ago.
group all content checkboxes
mc-find-dialog-tab-order2.patch (2.1 KB) - added by curtis 6 years ago.
both checkbox groups with their input

Change History

comment:1 in reply to: ↑ description Changed 6 years ago by andrew_b

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:2 Changed 6 years ago by andrew_b

  • Version 4.7.5 deleted
  • Milestone 4.8 deleted

comment:3 Changed 6 years ago by curtis

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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.

Changed 6 years ago by curtis

group all content checkboxes

Changed 6 years ago by curtis

both checkbox groups with their input

comment:4 Changed 6 years ago by andrew_b

  • Cc zaytsev added
  • Version set to 4.7.5

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.

comment:5 Changed 6 years ago by gotar

  • Cc gotar@… added

comment:6 Changed 6 years ago by 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?

comment:7 Changed 6 years ago by andrew_b

  • Status changed from reopened to closed
  • Resolution set to wontfix

comment:8 Changed 6 years ago by 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.

Last edited 6 years ago by zaytsev (previous) (diff)

comment:9 Changed 20 months ago by andrew_b

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

Note: See TracTickets for help on using tickets.