files
files copied to clipboard
elementary
Display contents of folder if highlighted by arrow key (column mode)
In column mode, highlighting a folder by clicking always displays the contents of the folder. Highlighting it by up ↑ and down ↓ arrow key (e.g. by arrow-key-based navigation) does not. I am coming from macOS of course (where the paradigms may be slightly different), but this feels inconsistent.
If I have a folder full of folders, I can press up ↑ or down ↓ arrows and the contents are not displayed, even if the folder is highlighted. My options for displaying the contents include the right arrow →, or pressing ENTER. The right arrow → aspect matches my expectations from macOS (and ENTER/RETURN in that OS would rename the folder), but this is not what I want when I am exploring a number of folders with the keyboard. I wish ideally to be able to use the up ↑ and down ↓ arrows and still see the contents of the folder.
Thank you to the Files team for your hard work and your consideration of this modification.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This may be a separate issue, but a slight addition:
One other nice thing that the macOS finder does in column mode when navigating up and down by arrow key, is automatically expand the right column to be fully visible. That is to say, regardless of whether it is a file or a folder, the columns shift to the left to make room for the new display in full when navigating over them with the arrow keys. At the moment, because it doesn't actually show the folder contents, I need to press ENTER to make the columns move and show that. I suppose this goes together with the main concern.
Yes, best to create a separate report for issues that can be fixed independently.
Display contents of folders by cursor focus only sounds potentially cpu hungry (although probably feasible on recent machines). Presumably, there is a delay before loading the folder to avoid folder loading being started and cancelled rapidly when the cursor is only momentarily on the item.
I should certainly hope there is not a CPU bottleneck there. For what it's worth, the feature worked as described on NeXT machines from 1988, which featured (I believe) 25MHz Motorola 68040 processors. Also, if I understand the grey/white notification area in the lower-right corner, aren't you traversing the directories anyway to get the disk space calculation?
Your right that the properties overlay does traverse the folder (after a delay) but that is considerably less work than displaying a view, especially if the folder contains 10,000's of files. You will notice that overlay can take several seconds to show the properties for large, deep folders. I guess in 1988 folder sizes were not that large and the views were probably simpler. That said, there is scope to optimise the speed and efficiency of Files ...
Definitely needs UX team go ahead to do this (although I might play around with a test branch)
Two other thoughts:
-
I think it's possible that macOS Finder may cache some directory views in memory so that they don't have to be re-read if they are highlighted over again within a certain period of time. And as a user it seems clear that Finder does regular, lower-priority background "update checks" to displays any changes while the folder is being viewed, too. Maybe that kind of thinking could reduce your CPU spikes?
-
What about generating "anticipated" directory views when scanning fresh directories for e.g. the need for thumbnails (and the subsequent generation of them)? Despite the initial and manageable CPU + i/o hit, it would be faster reading from such a cache (especially if it is in RAM).
There is already a directory object cache (but not a directory view cache). It would easily be possible to delay unloading directories object once their reference count reaches zero. Complication with views is that there are three different kinds, potentially, for the same directory and you cannot use the same directory view object in two different containers. I guess this wish only appliers to Column Views, though.
Directory objects did used to load all the thumbnails in a separate thread but it was found faster for the view to just load the ones actually being displayed or possibly about to be displayed.
I do intend to have a go at optimising Files this winter so I will bear you suggestions in mind. At the moment Files uses a single core for most stuff. If some of the work could be offloaded to another core that would speed things up.
@jeremypw Off topic but not: I can attest that it was far from uncommon for NeXT users on those 33MHz/40MHz machines to be dealing with thousands of files in a directory, maybe even tens of thousands. Depends on the project. It remained speedy like a champ. I'd say that something is seriously wrong with the underlying technologies that Elementary is using if it truly has an issue with things like this. I'd definitely like to understand that better.
It is true that developing on a slow machine makes the coder take more trouble to optimise and also to leave out or simplify features that slow things down. I have found that the color-tag plug in is quite a burden and could be optimised. Also using a standard Gtk widgets rather than a custom views hand-coded in C has a performance penalty. Files deals with up to say 10,000 files OK. It is when it reaches 100,000's things really slow down.
I would say that if you are moving very large numbers of files around you probably are doing backup or archiving and are better off using a specialist app rather than Files (at the moment).
We are back to who the target user of Files is meant to be ... ;-)
