237
votes
|
|
284
14
47
|
|
|
|
|
186
votes
|
|
190
2
4
|
|
|
|
|
|
43
votes
|
|
51
15
8
|
|
|
|
|
|
-23
votes
|
|
4
5
27
|
|
|
|
|
|
Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
|
+1
Nautilus becomes unusable when directories start getting several thousand files.
Anyway, maybe the status bar would help in this.
|
|
Hymyly
wrote on the 6 Jan 09 at 18:58
|
|
|
|
It would be better if it could show the contents as it goes along, like Windows Explorer in Vista and the Mac OS X browser both do, but a status bar is certainly a start.
|
|
marvo
wrote on the 6 Jan 09 at 19:32
|
|
|
|
-1 because a status bar is just prettyfying the symptoms of a bad design. Nautilus should display the sorted file list immediately (in fractions of a second) and then start to build the thumbnails and retrieve the meta information.
|
|
|
|
I've never seen how OSX handles it, but I really like that oozy green bar on Vista's Windows Explorer. marvo's got a point, a good file manager should rarely need such a feature (Win Exp does it all the time), but I believe Nautilus should have this feature anyway, because we can never be sure when it's going to have to face a folder too big for the CPU to handle.
|
|
|
|
it's not the cpu, it's the drive that's slow
|
|
|
|
You mean, because of ext3 or is it really Nautilus' fault?
|
|
|
Better goto the root of the problem.
Solve the real problem.
Make Nautilus faster.
|
|
|
I totally agree that the solution would be to make nautilus faster, but then why make a splash screen? Why not just make ubuntu boot within a couple seconds so that the splash screen is not needed anymore?
Although I am not a programmer I guess an easier to implement feature for now would be the statusbar which is why I suggested it..
One last note. When I was on ubuntu 6.06, and 7.10 I never had problems with the size of these folders. The problem only appeared when I got to 8.04...
|
|
|
+1
Even if a immediate list of files is displayed one would still like to know when ALL the files will be displayed and give an idea of how long it will take.
Also making nautilus faster will be great but it will hit a situation where the amount of files it needs to display will be too great and cause the user to wait without progress.
The progress/status will be very useful when displaying a list of files over a network (where the bottle neck isn't nautilus.)
|
|
|
+1 indeed display only the first file doesn't solve the problem, it make it worse if you're finding a file that's not displayed on start.
It will be nice to have a file browser faster, I think the bar is a good start to make the slowness of nautilus evident.
|
|
edm1
wrote on the 7 Jan 09 at 14:38
|
|
|
|
Do other file managers perform better on ext3? Im wondering whether it is an underlying problem brought about by a substandard filesystem.
|
|
|
I don't think so ... if you do a "ls" command in the terminal it lists the files pretty quickly.
If you pipe the ls output to a file, its almost instant.
I think the performance bottle neck is in nautilus.
|
sayakb
(Brainstorm admin)
wrote on the 7 Jan 09 at 15:09
|
|
|
"Do other file managers perform better on ext3? Im wondering whether it is an underlying problem brought about by a substandard filesystem."
On a 1 yr old laptop with config: T7700, 3GB DDR2 RAM, 320GB SATA-II HDD and a 512MB GPU, dolphin works faster (much faster rather) while opening my music folder which has exactly 834 folders.
A first look at the comment from braaivleis would make me think "ls simply lists them. Nautilus or any GUI file manager would show the previews and stuff", but all what I have is folders in my music folder. And anyway, dolphin is faster on my laptop(s) than nautilus.
Also, dolphin shows "Loading folder" bar below as the idea proposes.
+1
|
|
|
I think people have a different idea of what a *LOT* of files in one directory is...for example, I have one directory containing 60,676 files. You do *NOT* want to open that with Nautilus (or Thunar for that matter)
Things works just fine from the CLI there, though - maybe a half second delay for ls to start producing output. It's not a problem with the filesystem/CPU/disk.
|
|
andruk
(Idea reviewer)
wrote on the 8 Jan 09 at 06:45
|
|
|
Agreed with Eldmannen: Optimize/enhance Nautilus instead of working around a known problem.
Honestly, why didn't the Nautilus devs do this to begin with?
+1
|
|
Seph_VII
wrote on the 11 Jan 09 at 21:39
|
|
|
|
Why not do both? Even though I have a lightning-fast internet connection, I still appreciate Firefox having a progress bar.
|
|
|
Nautilus is really very slow when opening a directory containing many items, so this should be improved by first. Also working progess like in the solution #3 should be used - load directory's content subsequently.
However, whole process' speed may be also affected by other factors like the device's speed. It is even more appreciable when loading content of a remote directory, e.g. from an FTP server and everything you can see then, is cursor, saing there's some progress in the background. But there may be also a status bar, saing in which state the progress is and the content should be updated in more steps subsequently, if it's needed. Not just print whole directory's content at once after a long time, when it's ready.
|
|
|
Please file Wishlist Bug report against Nautilus for this issue or direct your suggestion to the Nautilus developers at http://live.gnome.org or on IRC at irc.gnome.org #nautilus.
Closing in Brainstorm.
|
Post your comment
|
