After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 572617 - Adding an option to never open files for determining icon
Adding an option to never open files for determining icon
Status: RESOLVED DUPLICATE of bug 491512
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.14.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2009-02-20 23:33 UTC by Jan Martinek
Modified: 2013-05-31 01:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Jan Martinek 2009-02-20 23:33:52 UTC
In GTK file chooser, if icons were assigned according to item attributes (type, name, extension), it would be very fast.

Other information:
Many people still have a slow computer, many files or simply want an immediate respond from user interface.
GTK file chooser is an example where huge performance gain could be achieved if icons were assigned according to attributes, not content. This is a main reason why file chooser is so slow and several seconds reads something from the disk. 

In previous versions of file chooser, some people complained that nothing is visible until all items are scanned. Now it is "better", because you can watch the progress of building list, but in the meantime it is unusable anyway.

I have just tried to make a file lister in PyGtk, which shows a fullscreen listing of filenames, extension, sizes, mtime, atime. Here is the speed:

3272 Items in /usr/bin 0.49587392807 seconds
Half a second. Now try opening /usr/bin in GTK file chooser. Please, would it be possible to add an option which would disable the MIME type checking according to content? Would it be too much *NIX violation?
Comment 1 Timothy Arceri 2013-05-31 01:43:24 UTC
As decribed in the bug 491512 the real issue is avoiding any unresponsiveness of the UI

*** This bug has been marked as a duplicate of bug 491512 ***