Ticket #2088 (accepted defect)

Opened 8 years ago

Last modified 6 years ago

"Show directory sizes" usability regression versus 4.6.x

Reported by: alex_sh Owned by: zaytsev
Priority: major Milestone: Future Releases
Component: mc-core Version: master
Keywords: Cc: gotar@…, zaytsev
Blocked By: Blocking:
Branch state: no branch Votes for changeset:


I upgraded to 4.7.1 from 4.6.2, and I noticed this huge (for me) usability regression regarding "Show directory sizes" feature.

It seems that it was changed to show only the current directory size (like if you selected it in previous versions), and to show the sizes of all directories you have to scroll all the way to the top and do it on the ".." entry.

This presents a huge usability regression. Consider the following:

I want to traverse a huge directory, one screenful of directories at a time, selecting the large ones (for example), and copying them to some other directory.

Previously, I would just f9-c-i, then select some directories, copy them, then f9-c-i again (because any action clears the sizes), select some more directories, etc...

Now I have to f9-c-i, select them, copy them, remember where I was (and I can't even select the directory I was on because it screws up the f9-c-i feature), scroll all the way to the top, press f9-c-i, then find the directory I was looking at (in a huge list of directories), and do the same each time mc clears the size fields. This clearly breaks the whole workflow.

This is especially a big pain when working with different mc versions on different servers (the alt-o change was already bad enough). So please, instead of changing the behavior of existing features, consider adding new shortcuts for the new ones and/or configuration options for them.

Change History

comment:1 Changed 8 years ago by gotar

  • Cc gotar@… added

comment:2 Changed 7 years ago by zaytsev

  • Cc zaytsev added
  • Version changed from 4.7.1 to master

So what you want is to compute the directory sizes of ALL directories unconditionally using a different hotkey?

Right now, the behavior is consistent with FAR, with the exception that "Compute directory sizes" is triggered by CTRL+SPACE instead of F3. I think this is quite logical.

Why you can't just select folders then press CTRL+SPACE, copy, select next batch and press CTRL+SPACE etc. ?

By the way, in #7 I'm pushing to change the behavior such that CTRL+SPACE on a file is equivalent to CTRL+SPACE on ".." and actually rename the option to reflect it's new meaning.

comment:3 Changed 7 years ago by alex_sh


So what you want is to compute the directory sizes of ALL directories unconditionally using a different hotkey?

Yes, this would be ok. Even better would be to leave the "F9-c-i" combination as it was in the old mc (compute ALL sizes), and make some other menu entry (with its own key combination and CTRL-SPACE shortcut) for the current behavior (Compute selected / current sizes).
I'm not sure about the benefit of consistency with FAR, since I would think the old mc users would expect the old mc-compatible behavior, not the FAR-compatible one. So the consistency with old mc is more important, IMHO.

The reason for not selecting a random amount of folders and pressing CTRL-SPACE is that it's, again, more effort than it was before. For example, from 2 pages of directories only one could have a large size - that would mean I have to unselect all the others first, and it's, well, a lot more actions than needed. More actions to perform a simple task means less usability.

The #7 change is nice (wasn't that the old mc behavior, anyway?), but it's still not applicable in this usage case scenario (it's no different than going up to "..").


comment:4 Changed 7 years ago by zaytsev

Yes, #7 is a partial roll-back to the old behavior that I liked, without breaking the new behavior, which is why I will hopefully get it through.

In what concerns your explanation, I am not entirely convinced how useful is this. However, your opinion has right for existence. So what can we do now?

1) Add another menu entry to compute dir sizes unconditionally

2) Decouple new keyboard shortcut CTRL+SPACE from the menu entry and revert menu entry behavior to the one from 4.6.2

3) Add a new keyboard shortcut without adding menu entry to do unconditional computation

I think both 1 & 2 suck. 1 sucks because we will have two almost identical menu entries. 3 sucks because nobody will be using it, because nobody gonna find it.

Which leaves us with 2) ? What do the others think? I actually newer call it from the menu, so it will not affect me, but will fix the situation for old-timers and weird use cases.

comment:5 Changed 7 years ago by alex_sh

Any of those would be fine by me, but I like the second one the most.
A behavioral change like that (which changes the existing behavior) will most certainly cause some problems with the users (especially those who administer lots of machines with different versions, and have to remember each time which version they're working with). So I guess my preference would be to leave the old behavior and add the new functionality without changing the old one, and that would be 2) here.
Another option would be to leave a single menu item with CTRL-SPACE, but make it configurable (old / new behavior).

comment:6 Changed 7 years ago by zaytsev

The problem with configurable options is that they are hard to find old and also each of them adds bloat that you will never able to get rid of.

Let's see if we can reach the consensus on 2) within the dev team. Any other brilliant ideas other that those that I already suggested are welcome.

comment:7 Changed 7 years ago by zaytsev

  • Owner set to zaytsev
  • Keywords stable-candidate added
  • Status changed from new to accepted

comment:8 Changed 6 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:9 Changed 6 years ago by andrew_b

  • Keywords stable-candidate removed
Note: See TracTickets for help on using tickets.