This would be extremely useful when browsing for images, for example in the GIMP.

Such an icon view could use the mime-type icons that are already used in the
list view. There should however be the possibility for the application to
provide alternative icons. GIMP could then provide thumbnails and the file
selector would become the image browser that people frequently ask for.

Wouldn't this be a nice feature for next stable gtk+? I'm asking just to check 
that this hasn't been forgotten.

*** Bug 349209 has been marked as a duplicate of this bug. ***

*** Bug 331158 has been marked as a duplicate of this bug. ***

*** Bug 340657 has been marked as a duplicate of this bug. ***

*** Bug 333972 has been marked as a duplicate of this bug. ***

*** Bug 352896 has been marked as a duplicate of this bug. ***

I totally want this. The way the file chooser works right now is so unhelpful (for anything media related) that it forces you to use drag and drop everywhere - effectively rendering the file chooser dialog "irrelevant" on your desktop, which is kinda sad. I wish I could fix this myself :|

*** Bug 344363 has been marked as a duplicate of this bug. ***

I want it too! :-)

I support this too. But this bug is too old! I think it doesn't have the interest of the developers... But I hope that someone will fix it, as happened for the fileroller dran&drop to nautilus :D

I'm bothering with this problem for a long time... 

This would be really, really great. I hope to see it in next version.

those little details that make the difference! =)

*** Bug 511850 has been marked as a duplicate of this bug. ***

KDE folks did it long time ago...

I'll be not surprised if I switch back to KDE in near future...

Version should be changed to 2.12.x or newer.

*** Bug 556614 has been marked as a duplicate of this bug. ***

Please, make this enhangment for GNOME 2.28! It is very useful!

This bug is 5 years old :(

Any news?

No, no news.  Nobody has stepped up to implement this.

@Federico: you are a gtk/gnome developer, is it?
Then, can you start to make this enhancement? 
Thank you in advance.

(In reply to comment #22)
> @Federico: you are a gtk/gnome developer, is it?
> Then, can you start to make this enhancement? 

I am, but I don't have time to work on this.  It's not a simple feature.

I'll gladly mentor someone who wants to implement it, though.

Oops, I didn't mean to mark this as fixed.

*** Bug 586240 has been marked as a duplicate of this bug. ***

Why not adding a way of choosing between multiple views (list, icon, thumbnail, etc.) in the file system ?

For an exemple, see MS Windows File Selector's screenshots at the bottom of this article http://libre-et-ouvert.blogspot.com/2009/06/5-ans-devolution-du-selecteur-de.html
The button at the upper right of the window all to switch between 5 views including thumbnails

(In reply to comment #26)
> Why not adding a way of choosing between multiple views (list, icon, thumbnail,
> etc.) in the file system ?

why not.

we all look forward to reviewing your patches, then.

Maybe the problem is that nautilus and gtkfilechoorse should share the same part of the code that is about displaying the filesystem.

I suspect lots of code duplication, which is a bad thing for us: nautilus developers maybe should port their views into gtk+ (and create new widgets, for instance gtkfilesystemview and derivates for icon, list and compact view).

At some point, there has to be a realization that a file chooser is something different than a full-blown file manager.

yes, but the part of viewing the files is exactly equal

I don't know how to GNOME project works, but I think this issue is very important for usability. 
So I hope a main developer will consider to write a patch.
I'm not a C/C++ developer, so I can't help, but as user I'll be grateful.
Please, make me happy.

> Please, make me happy.

Me too = stop spamming bugs. Got patch? Share. Gotn't? Just CC and be silent. Please.

*** Bug 605279 has been marked as a duplicate of this bug. ***

*** Bug 632508 has been marked as a duplicate of this bug. ***

Hint for how to implement this:

Go through gtk+/gtk/gtkfilechooserdefault.c and look for all occurrences of "gtk_tree_view".  Those are the functions that should get replaced with gtk_icon_view equivalents.  Just doing that cleanly will get you 90% of the way there.

GTK+ currently doesn't implement any thumbnailing service. Little research reveals many options which could be ported to the GTK+:

* GnomeThumbnail in libgnomeui
http://library.gnome.org/devel/libgnomeui/stable/libgnomeui-GnomeThumbnail.html

* Tumbler in xfce
http://pvanhoof.be/blog/index.php/2009/10/28/tumbler
http://live.gnome.org/ThumbnailerSpec

* pixbufthumbnail in libegg
http://live.gnome.org/ProjectRidley/EggIconChooser

* Nautilus has its own implementation also?

Someone should decide the best way to proceed. There is also discussion about there issues in https://bugzilla.gnome.org/show_bug.cgi?id=314423.

Any suggestions?

(In reply to comment #36)
> GTK+ currently doesn't implement any thumbnailing service.

The standard "give me the thumbnail for a file" API is to request for G_FILE_ATTRIBUTE_THUMBNAIL_PATH when asking for a file's attributes with GIO.

This is what GTK+ already uses to draw thumbnails for files in the file chooser.  They are there; they are just shown very small next to each filename.  

Also, GTK+ won't cause new thumbnails to be created for files that don't have them.  That is the job of Nautilus when you visit a folder, or more properly, the job of the application that created the original file in the first place.

(If you use the file chooser to go to a folder with image files and they have no thumbnails, then visit the folder in Nautilus first and then with the file chooser again - the file should have thumbnails now.)

In other words, GTK+ doesn't need anything extra to generate thumbnails.  We just need someone to get off his ass and implement an icon view using GtkIconView and the existing GtkFileSystemModel, as described in comment #35.

> In other words, GTK+ doesn't need anything extra to generate thumbnails.  We
> just need someone to get off his ass and implement an icon view using
> GtkIconView and the existing GtkFileSystemModel, as described in comment #35.

I have been preparing a patch which implements alternative icon view in the GtkFileChooserDefault. I try submit it in the near future.

In my opinion (as an end user), icon view is quite useless if GTK+ does not generate the missing thumbnails. In many cases there is no thumbnails generated by Nautilus or other software. Currently my patch uses pixbufthumbnail (copied/ported from libegg) to generate the thumbnails in g_idle callbacks.

Federico, is my approach acceptable? Anyway, I need to contact the devel mailing list and ask about some issues about how efficiently populate the file system model. Or could I contact you directly?

(In reply to comment #38)

> I have been preparing a patch which implements alternative icon view in the
> GtkFileChooserDefault. I try submit it in the near future.

This is great to know!  If you want, please publish your code on Github or Gitorious (or any such service), or post a "git format-patch" series in this bug, and I'll be very happy to review your work.

> In my opinion (as an end user), icon view is quite useless if GTK+ does not
> generate the missing thumbnails. In many cases there is no thumbnails generated
> by Nautilus or other software. Currently my patch uses pixbufthumbnail
> (copied/ported from libegg) to generate the thumbnails in g_idle callbacks.

Honestly I would feel more comfortable in letting an external process handle this, rather than potentially having all apps do random thumbnailing by themselves.  But this is general infrastructural work for GTK+ and Gnome, so let's discuss this.  I think someone proposed a thumbnailing service over D-bus at some point.

> Federico, is my approach acceptable? Anyway, I need to contact the devel
> mailing list and ask about some issues about how efficiently populate the file
> system model. Or could I contact you directly?

Sure, please contact me directly, either by mail or through this bug :)

Good luck, and thanks for working on this!

Simo, unless I'm imagining things, I'm pretty sure that you sent me a patch for the icon view in the file chooser.  I don't know if I screwed up my inbox or something, but I can't find it.  If you did, could you please send it again, or attach your patch to this bug?  I'm terribly sorry for losing it :(

(In reply to comment #40)
> Simo, unless I'm imagining things, I'm pretty sure that you sent me a patch for
> the icon view in the file chooser.  I don't know if I screwed up my inbox or
> something, but I can't find it.  If you did, could you please send it again, or
> attach your patch to this bug?  I'm terribly sorry for losing it :(

No problem. I made a new patch against the latest master branch. I'll resend the email soon.

This works very well!  Thanks for the work, Simo!

I've put your patch in gitorious:

http://gitorious.org/~federicomenaquintero/gtk3/federicomenaquinteros-gtk

Look for the "bgo141154-filechooser-icon-view" branch in there.

I split your patch into two commits, one to add gtkpixbufthumbnail.[ch], and another for the actual patch to the file chooser.

First I'll give you some general comments; and then replies to the questions from your mail.

* Let's remove gtkpixbufthumbnail.[ch] for now.  I'd rather just use the mechanism that GIO has to fetch thumbnails.

* Is it possible to split your patch into several commits?  Say, one to add the functions to abstract away the differences between treeview/iconview, another to add the new icon mode, another to add the widgets, etc.?

From your mail, you said:

> 1) Initially icons in the icon view are blank and small. Meaning that there is many visible icons and the get_visible_range is unnecessary large. How to _first_ load all G_FILE_ATTRIBUTE_STANDARD_ICON icons and then try to load the real thumbnails? Or could the standard icon fetching generate the thumbnail if not available... The patch includes some debug prints so it is easy to follow the flow.

Look in gtkfilechooserdefault.c:file_system_model_set() where it handles the case for MODEL_COL_PIXBUF; that's how the list view does it.

> 2) Is loading thumbnails in g_idle callbacks efficient enough? Should there be a worker thread of some other async service?

See the code above.  It launches an async g_file_query_info_async() for the thumbnail info (which GIO will do in a worker thread), and finally the file_system_model_got_thumbnail() callback will be called.

> 3) Memory management. When the view is changed, the content of container is changed and thus by default widget would be destroyed. That is why I call e.g. g_object_ref_sink (impl->browse_files_tree_view). Should these views be unreffed in somewhere? I tried this in the dispose function but got assert about nil pointer.

Rather than doing ref_sink and then container_remove when you are about to add the new view, just do gtk_widget_destroy() without ref/sink.  That should be enough.

By the way, I've filed bug #644430 about making GtkIconView use GtkTreeSelection instead of its own little API for selections.

(In reply to comment #42)
> This works very well!  Thanks for the work, Simo!
> 
> I've put your patch in gitorious:
> 
> http://gitorious.org/~federicomenaquintero/gtk3/federicomenaquinteros-gtk
> 
> Look for the "bgo141154-filechooser-icon-view" branch in there.

Ok, thanks. If necessary, can other people push commits to that branch?

> * Let's remove gtkpixbufthumbnail.[ch] for now.  I'd rather just use the
> mechanism that GIO has to fetch thumbnails.

I'm not happy with the current thumbnail creating mechanism, so probably this is a good idea for now. But it means that missing thumbnails won't be created.

> 
> * Is it possible to split your patch into several commits?  Say, one to add the
> functions to abstract away the differences between treeview/iconview, another
> to add the new icon mode, another to add the widgets, etc.?

Sure it's possible but needs some manual work because I don't have clean local commits. Is it worth of it?

> > 2) Is loading thumbnails in g_idle callbacks efficient enough? Should there be a worker thread of some other async service?
> 
> See the code above.  It launches an async g_file_query_info_async() for the
> thumbnail info (which GIO will do in a worker thread), and finally the
> file_system_model_got_thumbnail() callback will be called.

Yes, but GIO does not create the missing thumbnails. And probably never will? There could be a separate worker thread for creating missing thumbnails but how to coordinate this process with GIO's thumbnail fetching?

GIO thumbnail is either generic icon or real thumbnail if it exists already.

> 
> > 3) Memory management. When the view is changed, the content of container is changed and thus by default widget would be destroyed. That is why I call e.g. g_object_ref_sink (impl->browse_files_tree_view). Should these views be unreffed in somewhere? I tried this in the dispose function but got assert about nil pointer.
> 
> Rather than doing ref_sink and then container_remove when you are about to add
> the new view, just do gtk_widget_destroy() without ref/sink.  That should be
> enough.

Then I need to recreate the view again before adding it to the container? Note that user may choose between icon and list view any time.

(In reply to comment #43)
> Ok, thanks. If necessary, can other people push commits to that branch?

I can certainly give them commit access.  However, the usual workflow in Gitorious is to ask for a "merge request" from your own cloned repository.  I'm happy doing things either way.

> I'm not happy with the current thumbnail creating mechanism, so probably this
> is a good idea for now. But it means that missing thumbnails won't be created.

That is suboptimal, but I don't think it's the file chooser's job to generate thumbnails just like that.  If we end up having a helper daemon to create them, it should be GIO who launches those requests when asked for one of the G_FILE_ATTRIBUTE_THUMBNAIL_* attributes.

> Sure it's possible but needs some manual work because I don't have clean local
> commits. Is it worth of it?

Do you only have a single mega-commit now, or multiple messy commits?  I can help you clean up either version into small commits.

I'd prefer to have small commits to be able to understand the changes better.

> Then I need to recreate the view again before adding it to the container? Note
> that user may choose between icon and list view any time.

Yes, that's fine - create views only when needed.  That will save us a bit of memory and some startup time.

(Switching views shouldn't be expensive - after all, it's just creating a widget, reusing the same GtkFileSystemModel that you had, and reusing the hopefully-already-loaded thumbnail data.  But we can profile this after it is done.)

(In reply to comment #44)
> I can certainly give them commit access.  However, the usual workflow in
> Gitorious is to ask for a "merge request" from your own cloned repository.  I'm
> happy doing things either way.

I already had a github account, so there it is for now. Branched from a fresh gtk+ master.

https://github.com/simokivimaki/gtk/commits/bgo141154-filechooser-icon-view-only-gio

> That is suboptimal, but I don't think it's the file chooser's job to generate
> thumbnails just like that.  If we end up having a helper daemon to create them,
> it should be GIO who launches those requests when asked for one of the
> G_FILE_ATTRIBUTE_THUMBNAIL_* attributes.

gtkpixbufthumbnail is now removed, only GIO is used.

When current version of the patch is ready enough, lets think about the daemon.

> Do you only have a single mega-commit now, or multiple messy commits?  I can
> help you clean up either version into small commits.
> 
> I'd prefer to have small commits to be able to understand the changes better.

There is now five separate commits. Better than one at least...

> Yes, that's fine - create views only when needed.  That will save us a bit of
> memory and some startup time.

Widgets are now destroyed/created when changing views.


In which release this could be applied, if everything works fine or can be fixed soon? What else needs to be done? At least the translations (List/Icon)?

(In reply to comment #45)

> https://github.com/simokivimaki/gtk/commits/bgo141154-filechooser-icon-view-only-gio

Beautiful; thanks for splitting up the commits.

> gtkpixbufthumbnail is now removed, only GIO is used.

Thanks!

> When current version of the patch is ready enough, lets think about the daemon.

Yeah.  I don't really know the status of the thumbnail service that was proposed (in freedesktop.org?).

> In which release this could be applied, if everything works fine or can be
> fixed soon? What else needs to be done? At least the translations (List/Icon)?

Let me finish reviewing your split-up commits; so far everything looks great.

I *think* we can have this for GTK+ 3.2.  By that point I'd like to have GtkIconView fixed to also use GtkTreeSelection instead of its own API - then we can patch your code, which by then should already be merged, to use that single API rather than all you had to do.

One last thing - should we save the view mode in the file chooser's settings?

(In reply to comment #47)
> One last thing - should we save the view mode in the file chooser's settings?

Probably yes. I'm not familiar with the settings API and I need to find some time to implement this. Or could you or someone else look for it?

(In reply to comment #48)
> (In reply to comment #47)
> > One last thing - should we save the view mode in the file chooser's settings?
> 
> Probably yes. I'm not familiar with the settings API and I need to find some
> time to implement this. Or could you or someone else look for it?

Sure, I'll do it.

Federico, thanks for the review! I pulled your changes. I had to fix 2c53dbdb2ce3b942f0a7 because it broke copy_old_selection_to_current_view by setting view NULL too early.

> Some things are broken:
> * Switching from OPEN to SAVE mode in testfilechooser, makes it crash.

This was fixed in your commits.

> * new_folder_button_clicked() looks like it will fail.

Assert added.

> Can you please look systematically for where impl->browse_files_tree_view is
> used, and see if those code paths can be reached when the icon view is active?
> If so, they'll need changes.

These are used only in the list view, should be okay:
 * new_folder_button_clicked
 * file_list_query_tooltip_cb

I fixed these:
 * change_icon_theme
 * update_cell_renderer_attributes

Other impl->browse_files_tree_view usage is conditional.

OK, thanks for the fixes :)

Being able to use the icon view in SAVE mode would be useful, too; think of saving an image in the GIMP and wanting to see the other images around.  Could you please fix that?  I guess the main thing will be to have the icon view show an editable cell renderer for the folder's name, but that wasn't too hard in the treeview.

(I also pushed a small patch to make the file chooser save the view mode; it will be preserved by GSettings.)

We still need to do something about the initial "empty" icons that later get filled in.  Can we start with generic, fixed-size icons that get replaced later?

(In reply to comment #51)
> Being able to use the icon view in SAVE mode would be useful, too; think of
> saving an image in the GIMP and wanting to see the other images around.  Could
> you please fix that?  I guess the main thing will be to have the icon view show
> an editable cell renderer for the folder's name, but that wasn't too hard in
> the treeview.

I tried to add GtkCellRendererText also for the icon view but for some reason it does not allow editing currently. Anyway, I pushed to changes to the branch. Any ideas?

> (I also pushed a small patch to make the file chooser save the view mode; it
> will be preserved by GSettings.)

I pulled your commit but couldn't find your GSettings changes. Could you push them again?

> We still need to do something about the initial "empty" icons that later get
> filled in.  Can we start with generic, fixed-size icons that get replaced
> later?

Now the model loads icons with some delay. How to set initial empty icon without the async delay?

(In reply to comment #52)
> I tried to add GtkCellRendererText also for the icon view but for some reason
> it does not allow editing currently. Anyway, I pushed to changes to the branch.
> Any ideas?

Huh...  I ran this in gdb for a while, and everything seems to be called correctly.  Even GtkEntry's blink_cb() runs!  I have absolutely no idea of why the entry doesn't appear.

(Didn't set a breakpoint in gtk_entry_draw(), though...)

> I pulled your commit but couldn't find your GSettings changes. Could you push
> them again?

They are there in github... did you pick the right branch?

Okay, it turns out that GtkIconView has a bug where it will not size-allocate the editable entry correctly until it has had a chance to run its layout cycle.  We need to add the editable item, and *then* start the editing from an idle handler.

Simo, I just took the liberty of rebasing your branch on top of gtk-3-0, to keep it updated.  You can find it here:

https://github.com/federicomenaquintero/gtk/tree/bgo141154-filechooser-icon-view

It seems to work correctly.

The only remaining problem, as far as I can tell, is that the "Type name of new folder" text persists below the actual editable entry when you are editing... I don't know what's causing that, yet.  Could you take a look, please?  If you don't have time to work on this anymore, just tell me and I'll finish it.

Thanks again for all your work, Simo.  This is a great addition for GTK+ 3.2 :)

*** Bug 630558 has been marked as a duplicate of this bug. ***

Me and Federico wrote:

>> I pulled your commit but couldn't find your GSettings changes. Could you push
>> them again?

> They are there in github... did you pick the right branch?

I looked pull request https://github.com/simokivimaki/gtk/pull/2. Anyway, view_mode_set is included in the new gtk-3-0 branch so it's OK now.

But, please check line 4586. Looks like the view_mode is loaded but not used correctly.

https://github.com/federicomenaquintero/gtk/blob/aa2e85cc0961b6bf4ff66784e9e76cd2075f46ff/gtk/gtkfilechooserdefault.c#L4586

> The only remaining problem, as far as I can tell, is that the "Type name of new
> folder" text persists below the actual editable entry when you are editing... I
> don't know what's causing that, yet.  Could you take a look, please?  If you
> don't have time to work on this anymore, just tell me and I'll finish it.

I should have more time in the following weeks, so I may try to look that. Of course, I would be also happy if you could finish this :).

(In reply to comment #54)
> https://github.com/federicomenaquintero/gtk/tree/bgo141154-filechooser-icon-view

I sent a pull request which fixes the problem related to view mode loading from the settings.

> The only remaining problem, as far as I can tell, is that the "Type name of new
> folder" text persists below the actual editable entry when you are editing... I
> don't know what's causing that, yet.  Could you take a look, please?  If you
> don't have time to work on this anymore, just tell me and I'll finish it.

Unfortunately I have no clue how to fix this.

Please, could you try to backport this patch for gtk+2.0 ?
Thank you very much.

(In reply to comment #58)
> Please, could you try to backport this patch for gtk+2.0 ?

I wish that the known problems could be solved before any backporting to prevent useless work. I mean the comment #54. Secondly there should be some plan for actually generating missing thumbnails in some service.

Someone from the GTK team should look at these issues. I don't have enough knowledge.

*** Bug 315207 has been marked as a duplicate of this bug. ***

Federico, at this point I doubt Simo will rework the patch further as he indicated he was stuck. Would you like to "JFDI" finish that patch and put this bug to rest?



> Please, could you try to backport this patch for gtk+2.0 ?

No, that does not make sense anymore. GTK3 is the future and GTK2 is not having any new releases AFAICT.

Okay!  I just did a quickie rebase against master, fixed the obvious things that didn't mesh, and pushed a bgo141154-filechooser-icon-view branch.  This is no longer just in github; it's in git.gnome.org proper.

Pending things, as far as I can tell:

* The "Create folder" function's editable icon caption still looks weird - run it and you'll see.

* There are some warnings when exiting testfilechooser.

* No thumbnails are read; it just uses generic icons.

* The combo box to select between icon or list view is ugly.  I think the designers had some mockups for a pretty toggle.

Simo's work is an *excellent* starting point for the upcoming rework of the file chooser for Gnome OS's "libview" - a generic content selector which needs to plug into the file chooser.  It's exactly the kind of first-pass refactoring that the file chooser needed.

*** Bug 572066 has been marked as a duplicate of this bug. ***

Now that I think of it, this is likely to depend on bug #692348 when it comes to performance with the iconview.

Please? (https://plus.google.com/115735029147378885166/posts/J1CZRbHZ5uU ;-)

Ah and now, these days, I would expect this to be using the GTK FlowBox widget in 3.11+ rather than iconview, possibly making bug #692348 a non-issue (if FlowBox is fast enough)

When I have to open a picture in gimp, libreoffice or other apps, if I have plenty of pictures in the same folder, I have to click on all pictures until I found the  good one. What is more convenient and fast for users? Select the picture file for this name, if he knows it, or select the picture because it sees it? The second case of course! This feature really lacks in Gnome, all other shells purpose it, even Windows 98 had this feature. Gnome devs should put this bug/feature in a more high priority.

Hi. I don't use Gnome at all (or even any Gnome based DE), but I've noticed that this seems to be one of the main complaints I hear about from new Linux users. You should know that whenever I encounter someone who complains about this, I direct them to KDE. KDE uses Kdialog which DOES allow for thumbnails. So, not only does this missing feature prevent a lot of people from switching to Linux, but of the people who do switch, many of them are opting for KDE rather than Gnome because of this

Considering the number of people who have taken the time to comment here and the fact that this report was originally opened 10 YEARS AGO, I'd expect that you guys would make this a higher priority than you have.

Also, I hear people frequently complain about not being able to rename or open files from the same file picker. Those might be worth adding as well.

(In reply to comment #68)
> Hi. I don't use Gnome at all (or even any Gnome based DE), but I've noticed
> that this seems to be one of the main complaints I hear about from new Linux
> users. You should know that whenever I encounter someone who complains about
> this, I direct them to KDE. KDE uses Kdialog which DOES allow for thumbnails.
> So, not only does this missing feature prevent a lot of people from switching
> to Linux, but of the people who do switch, many of them are opting for KDE
> rather than Gnome because of this

that's perfectly fine: everyone chooses the preferred environment, the preferred operating system, or the preferred architecture based on their needs and requirements. we are not looking for souls to convert, and we don't have a quota to fulfil.

> Considering the number of people who have taken the time to comment here and
> the fact that this report was originally opened 10 YEARS AGO, I'd expect that
> you guys would make this a higher priority than you have.

that's not how open source development works. if you want to make this feature happen, then I humbly suggest you write a patch for it, instead of leaving comments on Bugzilla. all we can do is help you (or whoever else wants to tackle this) in writing the patch, getting it reviewed, and accepted.

> Also, I hear people frequently complain about not being able to rename or open
> files from the same file picker. Those might be worth adding as well.

there are other bugs filed for those, and they all need patches and attention from volunteers. feel free to help.

(removing the ASSIGNED state, given the lack of development in the area)

Telling users to write their own patches hardly seems like a sane suggestion to me, but whatever. GTK devs have a proven track record of not caring what their users want. I don't know why I expected this would ever change.

(In reply to comment #70)
> Telling users to write their own patches hardly seems like a sane suggestion to
> me, but whatever.

this is how a volunteer-driven, open source project works: patches get written because volunteers contribute them.

right now, every other volunteer in the GTK project is working on other priorities, and I'm sorry that you feel that you can come here and tell everybody else what to work on in their time; all I can tell you is that the only way to make the things *you* personally care happen is to contribute to the project. that's how every feature happened. if you are a user and you're unable to contribute code there is the option of finding somebody to work on this, and potentially paying this person.

to stay on focus, there is a branch that provides some of the code already, and it's available here:

  https://git.gnome.org/browse/gtk+/log/?h=bgo141154-filechooser-icon-view

the code needs to be rebased against the current master branch, and there is an outline of requirements in comment 62.

any further comment on this bug report that does not relate to the implementation of the feature is pointless, and just a waste of time for the 34 people that are subscribed to this bug and receive bug mail about it. please, try not to waste the time of those 34 users.

So you're saying that GTK devs would rather wait another 10 years and cross their fingers hoping someone else fixes their file picker for them rather than actually adding useful features to their products. Okay. I can live with that. I just hope you realize that this isn't very likely since Gnome is generally considered to be targeting inexperienced users (most of whom have no idea how to write a single line of code).

As far as wasting the time of those 34 users goes... I think they'd be interested to see the type of attitude the GTK devs take on issues like this.

"If you want a feature than add it yourself" isn't a good way to keep your community when there are so many other open source projects (with smaller teams even) who are much more responsive to bug reports and feature requests. While you guys are "busy" making everything flashy and "consistent", everyone else is focused on making things usable.

nethackpro: ebassi spent time explaining to you how development in volunteer-driven free software projects works.
Your last comment does not add anything new. 
Again: Please refrain from creating further bugmail for everybody here. 
Feel free to continue on your blog or in a forum if you are passionate about this issue but don't want to or cannot help getting it fixed. Thanks.

Holy mother of god, 10 years and you still haven't fixed it. I am having a good laugh here. This is exactly why Loonix will never catch up with Windows.

Ok so who wants money in exchange of making a patch? Devs doesn't care about this, but maybe with money in hand we can get another point of view.

Note that after all these years there IS a plan to redesign the file picker on that line from a designer deeply involved with gnome:
http://afaikblog.wordpress.com/2013/12/11/nautilus-next/

(yes this plan does cover the file picker, read it thoroughly). That said, plan and implementation are different things.

I think what people have trouble to understand is that nautilus is part of gnome and the file picker of gtk. Developers don't want to put that much code from nautilus blindly in gtk, besides gtk has portability concerns that gnome does not have.

is this fixed?

(In reply to comment #77)
> is this fixed?

What makes you think so, in which GTK+ version?

finally fixed!!
thnx guys

@nedarata: Oh? By which commit / version? I can't find anything relating to this, though I may have not been thorough enough.

this issue has not been fixed, and it won't until somebody actually works on it.

*** Bug 622133 has been marked as a duplicate of this bug. ***

*** Bug 741507 has been marked as a duplicate of this bug. ***

(In reply to Federico Mena Quintero from comment #39)
> Honestly I would feel more comfortable in letting an external process handle
> this, rather than potentially having all apps do random thumbnailing by
> themselves.  But this is general infrastructural work for GTK+ and Gnome, so
> let's discuss this.  I think someone proposed a thumbnailing service over
> D-bus at some point.

Freedesktop specifies a D-Bus thumbnailer service.
https://wiki.gnome.org/DraftSpecs/ThumbnailerSpec
http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html

I have added support for the Freedesktop Thumbnailer to GIO::get_thumbnail_attributes.
https://github.com/wfr/glib/commits/bgo141154-glib-thumbnailer
Diff against current master: http://paste.debian.net/162643/
TODO:
- It's still single-threaded, locked by a static mutex. Multi-threading is causing problems with the D-Bus signals.

As for a D-Bus service implementation to test it with:
The XFCE desktop environment provides a lightweight implementation of the Freedesktop Thumbnailer.
http://docs.xfce.org/xfce/thunar/tumbler

There is one temporary issue:
The current stable version of tumbler stores thumbnails in ~/.thumbnails/ whereas GIO::get_thumbnail_attributes() searches  $XDG_CACHE_HOME/thumbnails.
This has been fixed in tumbler's master brawnch and should be part of the next release.
http://git.xfce.org/xfce/tumbler/commit/?id=69122ab380c7f4fc5cf69d5b1d597f588ea39bc4
Until then, use this workaround: rm -r ~/.thumbnails/; ln -s ~/.cache/thumbnails ~/.thumbnails

You can test thumbnail creation with this simple program:
https://github.com/wfr/gio-thumbnail-test

updated freedesktop thumbnailer support for glib/gio:
+ thread-safety
+ coding style
diff against current glib master:
https://paste.debian.net/165244/

Here's my patch for gtk+2 (because of Firefox and GIMP) 
https://gist.github.com/ahodesuka/a6da728404cdf0e6f157

This is mostly based off of what was done in
https://git.gnome.org/browse/gtk+/log/?h=bgo141154-filechooser-icon-view

I fixed the issue with the "Create folder" text issue, and added a slider to 
adjust the size of the thumbnails in the icon view.

The differences between gtk+2 and gtk+3 for this code is quite minimal and
it could probably be ported to gtk+3 in about an hour of work.

(In reply to ahoka from comment #86)

Thanks for the patch!

> Here's my patch for gtk+2 (because of Firefox and GIMP) 
> https://gist.github.com/ahodesuka/a6da728404cdf0e6f157

I very much doubt this will be integrated in GTK+ 2.x, at this point. Both Firefox and GTK+ are actively working on a GTK+ 3 port, and we're trying to keep the GTK+ 2.x branch to a zero churn policy after some of the changes in GTK+ 3 were backported.

> This is mostly based off of what was done in
> https://git.gnome.org/browse/gtk+/log/?h=bgo141154-filechooser-icon-view

I haven't looked at your code yet, but did you address the issues outlined in comment #62?

You also stripped everything down to a patch, and thus removed attributions and history; we definitely want to preserve both.

> The differences between gtk+2 and gtk+3 for this code is quite minimal and
> it could probably be ported to gtk+3 in about an hour of work.

It would be helpful to have a patchset against GTK+ 3.x first, and then we can decide whether or not it can be backported to GTK+ 2.x.

Thanks again for your work!

(In reply to Emmanuele Bassi (:ebassi) from comment #87)

> I haven't looked at your code yet, but did you address the issues outlined
> in comment #62?

I fixed the issue with the editable label when creating a new folder.
I didn't get any warnings while running testfilechooser, as mentioned in comment #62.
The third issue is solved with comment #86, and the last issue doesn't really 
apply to GTK+ 2 since you can't readily do anything fancier.


> You also stripped everything down to a patch, and thus removed attributions
> and history; we definitely want to preserve both.

https://github.com/ahodesuka/gtk/tree/bgo141154-filechooser-icon-view-gtk2

> It would be helpful to have a patchset against GTK+ 3.x first, and then we
> can decide whether or not it can be backported to GTK+ 2.x.

I'll be working on the GTK+ 3.x version from now on.
Rebasing master onto the current GTK+ 3.x version (bgo141154-filechooser-icon-view) 
is probably a waste of time - so I hope that isn't a problem.

I have been working on porting Simo Kivimäki's patch from 2011 to the current gtk3/master Branch for the last weeks, alongside of adding thumbnailer support to GIO (see above).

Current state:
https://github.com/wfr/gtk/tree/bgo141154-glib-thumbnailer-rework
https://i.imgur.com/PNOO0nE.png
https://gist.github.com/wfr/55d99f680fea8f815d17
https://paste.debian.net/166056/

Changes over the 2011 patch:
[+] Thumbnail generation using the aforementioned glib patch
[+] Fix drag & drop to work with the Glade UI
[+] Add the new right-click popup menu
[+] Disable "show size column" option in icon view mode
[+] Add tooltips to icon view

To do:
[ ] GtkIconView editing still broken


Development diary, for completeness' sake:

Proper rebasing proved to be very elaborate because the file chooser has seen quite a bit of refactoring work since 2011. 
First I ported Simo Kivimäki's "bgo141154-filechooser-icon-view" to gtk-3.8.9
https://gist.github.com/wfr/c8e431a61d300b4f3d15

3.10 saw one major change in the file chooser, namely replacing hard coded widgets with a Glade UI. The whole widget is now fully editable in Glade. At the time when Sumi wrote his original patch, the TreeView and IconView widgets were created programmatically. Switching between views destroyed the old view and recreated the new view from scratch. I decided to use a GtkNotebook as the view container to keep the whole widget editable in Glade.
https://i.imgur.com/zlmVH7d.png

Should the designers choose a different control mechanism for the view mode, the GtkNotebook can have its tabs hidden with gtk_notebook_set_show_tabs().

I have then ported the patch forward to 3.12, 3.14 and finally the master Branch. The individual commits are not clean but I can provide them if it helps.

This bug got public interest recently

http://www.reddit.com/r/linuxmasterrace/comments/32pmlg/one_thing_always_bothered_me_about_gtk_file_picker/

You can also join and put some bounty on it to get this 10 year old problem fixed :)

https://www.bountysource.com/issues/3554613-add-an-icon-view-with-thumbnails-mode-like-nautilus

id add another the bug report:
Bug 750067 - importing paths shows no thumbnail in the file chooser

Re Comment 91: That bug is unrelated.

(In reply to Michael Natterer from comment #92)
> Re Comment 91: That bug is unrelated.

i see it differently. A file chooser is a tool to display and choose files. Its only one file type for paths: svg. Probably very few people use extensively paths in Gimp, so that users dont know they can also import paths.
 
If the file chooser shows one extension more shouldnt be that big problem. Gimp is useful, because it handles lots of files. Why not extending an already supported file format also to the file chooser?

Jo, this bug is a GTK+ bug about adding an icon view mode to the general
GTK+ file chooser. The GIMP bug you pasted is about a missing preview
pane in a specific GIMP dialog. Unrelated.

(In reply to Michael Natterer from comment #94)
> Jo, this bug is a GTK+ bug about adding an icon view mode to the general
> GTK+ file chooser. The GIMP bug you pasted is about a missing preview
> pane in a specific GIMP dialog. Unrelated.

Therefore, should i add reply 91 in another bug report?

No, if this bug and bug 750067 are fixed, then all you ask for should
be implemented.