GNOME Bugzilla – Bug 141154
Add an "icon view with thumbnails" mode (like Nautilus)
Last modified: 2021-02-27 10:05:40 UTC
The file-chooser should be able to share the "icon view" feature used in Nautilus, so that you can choose between list view and icon view (with thumbnails). I believe the Windows file selector already does this. Now how to do this I have no clue about, because I am not a developer. I guess either Nautilus should allow other applications to share this function (which could also be useful to file-roller e.g.), or it should be lifted out from Nautilus, making it a gtk widget or something?
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.
This bug is still unfixed. The GtkFileChooser widget does create preview icons for image files, but they're illegibly tiny. Remaining issues, from a user perspective: 1. Create a grid view with 64x64 or larger icons/thumbnails. 2. Enable switching between grid view and the default, compact view at run time. 3. Create a setting in settings.ini to store the preference. 4. Create a graphical way of switching this preference.
calm down. this is very young bug that soon will be fixed maybe even in this decade
nedarata: Please refrain from posting unhelpful comments. See https://wiki.gnome.org/Foundation/CodeOfConduct - thank you.
What's stopping us from rewriting the gtk file chooser widget? If funding is necessary to sponsor the fix/rewrite we users can arrange. If I knew programming (If I knew C) I would rewrite the widget, but I am just an end-user. With due respect I sincerely urge the developer to invest in this particular issue. I would also like to remind that not only GNOME uses GTK+, many, many more free and open source software uses it and all of them have this same issue. Please do not let the users down. Thank you.
It seems to me that the best way to make everyone happy here would be to make this component of GTK modular. This way GTK could continue to provide a bare bones default file picker and people who desire more features like thumbnail views, the ability to rename or delete files, etc... could configure GTK to use third party file pickers with more features if they desire.
(In reply to Anony_ from comment #100) > What's stopping us from rewriting the gtk file chooser widget? What's stopping us is the fact that we don't have a widget capable enough to do so. GtkIconView can be terribly slow during start-up if the thumbnails need to be generated. GtkFlowBox is nicer but isn't able to deal with thousands of items. > I would also like to remind that not only GNOME uses GTK+, many, many > more free and open source software uses it and all of them have this same > issue. Please do not let the users down. Maybe somebody from one of those "many, many more free and open software projects" will step up to contribute this feature.
> Maybe somebody from one of those "many, many more free and open software projects" will step up to contribute this feature. It's a lot harder for someone who isn't familiar with the Gtk+ code or even the C programming language to contribute code for this. But some people have already stated that they would like to contribute money or testing time instead.
> some people have already stated that they would like to contribute money > or testing time instead. Money or testing time is not the issue. Skilled developer time is. Unless you can find a skilled independent C dev that does not already have a full-time job AND you can raise between 20 and 100k$ (and I'm being cheap here) to pay that person to work full-time on this for a couple months (or a year, accounting for potential "yak shaving" scenarios), what this needs is more people banging on the code... less people banging on the people. Those who have enough free time yet keep saying "but I'm not a C developer" and "what's stopping you from...": nothing stops you from learning C, too ;) and nowadays there is GNOME Builder to make your learning much easier.
(In reply to Debarshi Ray from comment #102) > Maybe somebody from one of those "many, many more free and open software > projects" will step up to contribute this feature. Some of the users of more popular projects which are utilizing this particular part of GTK have opted to develop patches for those applications to leverage the QT file picker instead. An example of this would be the firefox-kde-opensuse patch. I really think it would be better to simply define an API and allow the users to configure GTK to use any other file picker that conforms to said API. This way, it will be far more likely that someone will come along and implement this feature. Otherwise, after 13 years I highly doubt this is going to ever get done.
(In reply to nethackpro from comment #105) > I really think it would be better to simply define an API and allow the > users to configure GTK to use any other file picker that conforms to said > API. This way, it will be far more likely that someone will come along and > implement this feature. Otherwise, after 13 years I highly doubt this is > going to ever get done. Look at GtkFileChooserNative. But no, I don't think we want make this user configuration.
Correct me if I am misunderstanding this, but GtkFileChooserNative appears to be something that would have to be used by the developers of applications leveraging GTK. This puts the users in the same spot of needing to apply patches to applications which don't use that feature (or who implemented it poorly). My current understanding (based on previous comments made in this thread) leads me to believe that the lack of features I hear end users complaining about in regards to the file chooser would not be included in GTK because they fall outside the scope of a windowing toolkit (which I agree with). If additionally we can't even get it opened up to be configurable such that end users (or DE developers) can configure GTK to use a different file chooser, then what exactly are we expected to do? As someone who uses Linux exclusively, it is dilemmas like this that occasionally make me question whether I should just go back to using and developing for Windows and/or OS X. That's pretty much the only sensible option for someone who cares about this feature other than simply giving up any software which uses the gtk file chooser. However, I am less inclined to install Chromium instead of Firefox than I would be to install Windows rather than Linux.
I also want to add that my goal for continuing this conversation has more to do with nailing down acceptance criteria so that other people who are interested can more easily understand what needs to be done and how it needs to be done to be accepted. Many programmers who follow agile development methodology (which is pretty common these days) will be uncomfortable starting on a project without having clear and measurable acceptance criteria (nobody wants to do a bunch of work to be told that it won't be accepted because for various reasons). I'd like to have it be made clear exactly what is still needed as well as any caveats and/or additional criteria that must be met in order for this issue to be closed out. This will enable people to better understand the scope of the project and determine whether they have the time to contribute. Additionally, it will enable people to understand whether the end result will even be a satisfying solution, so that they can look into alternative courses of action if necessary (possibly completely outside the realm of GTK)
(In reply to nethackpro from comment #107) > Correct me if I am misunderstanding this, You are misunderstanding this.
(In reply to nethackpro from comment #107) > My current understanding (based on previous comments made in this thread) > leads me to believe that the lack of features I hear end users complaining > about in regards to the file chooser would not be included in GTK because > they fall outside the scope of a windowing toolkit (which I agree with). If > additionally we can't even get it opened up to be configurable such that end > users (or DE developers) can configure GTK to use a different file chooser, > then what exactly are we expected to do? This cannot be done without changes in the applications themselves. The current design of GtkFileChooser{Widget,Dialog} allows developers to put random GTK+ widgets inside, which is obviously not possible if the underlying implementation suddenly decides to use Qt. That's why GtkFileChooserNative does not allow adding widgets to it, and it itself is not even a GtkWidget. (Note: I've been on the "put the file chooser inside the file manager, not the toolkit" side of things for a long time) Making this a user-configurable option is wrong because that means you have to add API to change it (since "set this random gsettings key" is just a hack), or even UI to change UI (where would a settings dialog for the file chooser dialog go, exactly?). The entire discussion about making it configurable for the GTK+ file chooser to, well, not use GTK+ is pretty ridiculous when you are a GTK+ contributor and people ask you to change to toolkit so they don't have to use the toolkit. If an application developer decides to use GTK+, they probably made that decision for reasons and changing the application to use GTK+ everywhere but the file selection is just wrong. (In reply to nethackpro from comment #108) > I also want to add that my goal for continuing this conversation has more to > do with nailing down acceptance criteria so that other people who are > interested can more easily understand what needs to be done and how it needs > to be done to be accepted. Many programmers who follow agile development > methodology (which is pretty common these days) will be uncomfortable > starting on a project without having clear and measurable acceptance > criteria (nobody wants to do a bunch of work to be told that it won't be > accepted because for various reasons). I think people in here mentioned a good chunk of things that need to change for the file chooser to ever use an icon view. (Of course, if the file chooser were part of Nautilus, that would come for free...). I've been looking into fixing filechooser problems now and then but I stop for various reasons every time: 1) I'm pretty sure that, no matter how you change it, people will complain about it. Given that people rant online about every single change anyone makes to it, it's a pretty thankless activity to spend your spare time with. 2) The file chooser is ridiculously complex. 3) Fixing the underlying problem of using different views is way more work than anyone could crank out on a few weekends. It's so much that you'd have to constantly talk to other people and users to evaluate your current approach. Apart from that you still have all the technical problems. 4) Obviously, one big patch to change the file chooser to everyone's likings is not feasible, so an iterative approach is needed. Still, over the years nobody turned up and started making small changes. 5) Once you stare into gtkfilechooser*.c, you'll find lots of other problems, and if you look at the reports in bugzilla, you find lots of bugs, sometimes condraticting each other. But if you really want to know what it'll take, technically, so allow the file chooser to use an "icon view" instead of the current tree view... 1) There's GtkFlowBox for that already and Nautilus plans to use that in the future. gnome-photos already does in 3.24. *But* now we get to a problem of scalability -- how many files do you want to support in a directory at max? Because the current GtkFlowBox implementation only supports to display a fixed amount of widgets, so you'd have to create a new (potentially complex) widget for every file you display. 2) So, the obvious answer to 1) is: do what Android does and just recycle widgets, and only create widgets for the items that are currently visible[1]. That would obviously require you to use an underlying model instead of just adding widgets yourself, so you'd need to use GListModel. Luckily, GtkFlowBox already has API to bind a GListModel to it. But this creates a whole bunch of other problems, e.g. it breaks scrolling (Android "fixes" this by using a few hacks, like only doing row-based scrolling on drag, or not showing a scrollbar at all... which of these do you prefer?), it breaks the nth-child CSS stuff, it breaks a11y(probably?). So of course, a proper implementation would require to fix all these. 3) Now that you've introduced an icon view and that's using GtkFlowBox and you've ported the filechooserwidget to use a GListModel internally, you've just broken the treeview case. GtkTreeView does not operate using a GListModel, it uses a GtkTreeModel. However, we don't have a replacement tree view that uses real GtkWidgets instead of cell renderers. Now one way you could go is ignore that for the time being and implement this view using just a GtkListBox (which would work since it can use a GListModel as well). But now you've taken away the treeview, so people will rant online of course. 4) I can't think of other problems right now but I'm sure there are others. Now don't get me wrong, I don't want to discourage anyone from working on this, and the filechooser is often frustrating for me to use as well, but it't just not the kind of thing you can just throw patches in bugzilla for. It requires iteration and communication with users, developers and designers. [1] I've implemented a GtkListBox test case for this in https://github.com/baedert/listbox-c . It can display millions of rows fine, but it's broken in the ways described.
Why not do what Nautilus does (or will do with GtkFlowBox)?
> What's stopping us is the fact that we don't have a widget capable enough to do > so. GtkIconView can be terribly slow during start-up if the thumbnails need to > be generated. GtkFlowBox is nicer but isn't able to deal with thousands of items. Isn't this exactly what external thumbnailers exist for? On Windows you could leverage the native thumbs.db file per directory, and on X11/Wayland platforms there's Tumbler, which is exposed via D-Bus. Tumbler performs well even on directories with thousands of large image files in my personal testing. Also, you're talking about a few seconds of wait time on the worst case (5k+ files, 5400rpm drive) versus FIFTEEN YEARS of no motion on this ticket, so I think people will be more forgiving than you think. > 3) Now that you've introduced an icon view and that's using GtkFlowBox and > you've ported the filechooserwidget to use a GListModel internally, you've just > broken the treeview case. GtkTreeView does not operate using a GListModel, it > uses a GtkTreeModel. However, we don't have a replacement tree view that uses > real GtkWidgets instead of cell renderers. Now one way you could go is ignore > that for the time being and implement this view using just a GtkListBox (which > would work since it can use a GListModel as well). But now you've taken away > the treeview, so people will rant online of course. So write a new tree view instead. This seems like it would be easier to do.
(In reply to jon from comment #114) >> What's stopping us is the fact that we don't have a widget >> capable enough to do so. GtkIconView can be terribly slow >> during start-up if the thumbnails need to > be generated. >> GtkFlowBox is nicer but isn't able to deal with thousands of items. > > Isn't this exactly what external thumbnailers exist for? It's not about the thumbnailer. It's about the widget. >> 3) Now that you've introduced an icon view and that's using >> GtkFlowBox and you've ported the filechooserwidget to use a >> GListModel internally, you've just broken the treeview case. >> GtkTreeView does not operate using a GListModel, it uses a >> GtkTreeModel. However, we don't have a replacement tree view >> that uses real GtkWidgets instead of cell renderers. Now one >> way you could go is ignore that for the time being and implement >> this view using just a GtkListBox (which would work since it can >> use a GListModel as well). > > So write a new tree view instead. This seems like it would be easier to do. A new tree view with what? GtkListBox has the same scalability problems as GtkFlowBox. Writing a scalable list/grid view widget is very very non-trivial. If it was any easier, this bug would've been solved long ago.
This bug has closed the 100-comment threshold. Please use more suitable channels for general discussion of scalability.
Hello, I have been working on this for a little while now and I have a patch for gtk2 and gtk3. ahoka seemed to abandon his gtk2 patch, so I went ahead and forked it and brought it up to date with the current gtk2. Fortunately, porting was very trivial and not much work at all and it works beautifully. This implements a combo box for switching views and the list/icon views are created and destroyed upon switching. Patch here: https://gist.github.com/Dudemanguy911/d70734d5bdf82e79cbfb22894fac8a1b Git branch here: https://github.com/Dudemanguy911/gtk/tree/gtk2-filechooser-icon-view Example image: https://i.imgur.com/2jEYdqU.png For gtk3, I decided work off of what Wolfgang Frisch did above. Gtk3 has seen a lot of changes, so it took awhile to get it up to speed, but I'm pretty happy with what I have. Due to the introduction of gtkbuilder, I don't think there is a way for the views to be created and destroyed programatically like they are for the gtk2 patch. However, I did prefer using a combo box to switch views as opposed to the tabbed notebook. So I opted to simply hide the tabs on the notebook and add a combobox to switch the tabs. That way, the UI is exactly the same as the gtk2 patch even if the internals are technically a bit different. Wolfgang Frisch's patch didn't have an scale to increase the icon sizes, so I added that in as well and heavily based it off the one in the gtk2. Right now, there's only a few minor bugs. When the dialog is closed and reopened, the scale in icon view doesn't save what position it is in. But, the actual icon size itself is preserved (which is what is really important). So it's basically just a minor graphical glitch that I'm sure can easily be fixed, I just haven't figured it out how to keep the slider from different dialog sessions. There's another bug that involves the popover. Sometimes when launching with icon view, the right click popover seems to grey out. So you typically have to close it, reopen it in list view and then right click and it seems to work. A tad annoying but not a big deal. The last bug I'm aware of is that unfortunately it seems like switching directories sometimes causes the items in the directory to jumble out of alphabetical order. Since the icon view has no setting for this, you have to switch to list view to set it back to alphabetical order and then switch back to icon view. This one might be the most annoying one that I've found. It's not perfect, but it works pretty well so far and I much prefer it to the default upload dialog. Hopefully fixing the final few issues won't take too long. Patch here: https://gist.github.com/Dudemanguy911/c172394e30e1e7d0f477ad15c719bc71 Git branch here: https://github.com/Dudemanguy911/gtk/tree/gtk3-filechooser-icon-view Example image: https://i.imgur.com/mRc09Qy.png One final note, both of these patches work best with yet another patch to glib2 (I believe it's mentioned earlier in the comments). It's pretty old, but it's only adds a small amount of code and works just fine. Essentially, it sends dbus a signal to fetch thumbnails if you have a thumbnailer installed (i.e. tumbler). That way, the thumbnails for things like videos and whatnot load quickly in the icon view. Patch here: https://gist.github.com/ahodesuka/49c1d0eea4b64f24c4c7 I would definitely like to see this bug finally resolved once and for all, so I'm willing to make the changes necessary to get this accepted upstream. I believe most of the work is going into getting gtk4 ready. I believe most of the gtk3 code works just fine with the master branch. It's a matter of getting the UI sorted out since GtkBoxes will be left behind in favor of GtkGrids. I'm willing to work on the master branch once I get the lingering bugs sorted out in the gtk3 branch.
(In reply to dudemanguy from comment #117) > Hello, I have been working on this for a little while now and I have a patch > for gtk2 and gtk3. > > [...] > > Patch here: > https://gist.github.com/Dudemanguy911/c172394e30e1e7d0f477ad15c719bc71 > > Git branch here: > https://github.com/Dudemanguy911/gtk/tree/gtk3-filechooser-icon-view > > Example image: > https://i.imgur.com/mRc09Qy.png Did you see comment 102, comment comment 110 and comment 115? GtkIconView can be *slow* on start-up if the thumbnails are generated. So it can't be used as is without at least fixing that. Even then, it is not what we want to use for new features because it doesn't re-flow its content. That's why GtkFlowBox exists, but it needs work to make it scale to hundreds of tiles. Please, if you really want this, try to spend time on one of these issues. Either make GtkIconView faster, or make GtkListBox (that's easier than GtkFlowBox) scale.
Hey, dudemanguy, THANK YOU for reviving this old patchset! I just made it compile and sent a pull request your way: https://github.com/Dudemanguy911/gtk/pull/1 Don't worry about GtkIconView slowness for now - GtkTreeView isn't stellar, either. The important thing is to get this code back alive, which you have already done, and to make the controls to change the view as close to Nautilus as possible.
(In reply to Federico Mena Quintero from comment #119) > Hey, dudemanguy, THANK YOU for reviving this old patchset! I just made it > compile and sent a pull request your way: > https://github.com/Dudemanguy911/gtk/pull/1 > > Don't worry about GtkIconView slowness for now - GtkTreeView isn't stellar, > either. GtkTreeView is actually way better than GtkIconView when it comes to dealing with a bunch of GdkPixbuf's getting updated in quick succession. GtkTreeView might not be ideal because it uses GtkCellRenderers instead of normal GtkWidgets, but that's not an existential performance crisis. I genuinely do not know any mature application that uses GtkIconView to show a potentially massive collection of items. Note how Nautilus doesn't use GtkIconView but uses GtkTreeView. ;) The only major users of GtkIconView are the new GNOME 3 content applications, and they suffer pretty badly because of it. Try to delete your thumbnail cache and launch gnome-documents in grid mode. Then compare that to the list mode. I have read similar reports about gnome-music. Abstracting GtkIcon/TreeView over the same GtkTreeModel is not that hard, you know. Hell, libgd has had GdMainView for ages and is used by multiple applications. It also has GdMainBox for the GtkList/FlowBox case. GtkIconView also doesn't offer the UX we want for our content grids - it doesn't reflow the contents. That's not the future we should be aiming for. > The important thing is to get this code back alive, which you have > already done, and to make the controls to change the view as close to > Nautilus as possible. Nautilus is actually trying to move towards GtkList/FlowBox. Those are available today behind an experimental setting. So, pushing forward with a GtkIconView based file chooser is only going to increase the delta. The useful thing to do here would be to collaborate with Timm Bäder who is working on GtkListBox scalability. Once you have a scalable GtkListBox, you can apply the same to GtkFlowBox. That would not only get you a nicer file chooser, but also help move the whole platform forward.
>Please, if you really want this, try to spend time on one of these issues. Either make GtkIconView faster, or make GtkListBox (that's easier than GtkFlowBox) scale. Sure, I understand the concern. GtkIconView is a bit slow if there are many items. I don't think it's unbearably or unusably slow, but speeding it up would be preferable. I would like to note that GtkIconView in gtk2 seems much faster for me than in gtk3. I'm not sure what exactly the reason is, but I will look into it and see what I can do.
Just to be clear - landing this kind of change in gtk2 is pretty much out of the question at this point in its life cycle.
I'm re-doing the patchset by doing a few things: - Using a GtkFileChooserViewIface, instead of using separate functions to decide upon the view type. It's a lot of boilerplate, but it will keep gtkfilechooserwidget.c smaller. - Using the same toggle button that Nautilus has to switch between list/icons. - Making the .schema as close to Nautilus's as possible, for if we end up sharing the actual configuration key later. I'll publish this soon.
Work in progress here: https://github.com/federicomenaquintero/gtk-1/tree/gtk-3-22
Update: code moved to https://gitlab.gnome.org/federico/gtk/tree/filechooser-icon-view
The strategy is as follows: * We have a GtkFileChooserViewIface now. I'm removing calls to gtk_tree_view_*() and gtk_tree_selection_*() and similar from gtkfilechooserwidget.c, and adding the corresponding methods to the view interface. The relevant code from gtkfilechooserwidget.c moves into gtkfilechooserlistview.c. * We didn't have unit tests before. The file chooser needs to adjust a lot of widgetry on each action, and I want unit tests to check that behavior. So, I'm moving all the state that needs to be reflected in the widgets into a GtkFileChooserState struct. One modifies priv->goal_state as needed, and then calls queue_sync(impl). In the idle handler, the state will be synchronized to the widgets and copied to priv->state (the "current state"). The test suite can then check that the widgets match the state. * Since all the widget syncing is now to be done in a single place (the idle handler from queue_sync()), *but* it is now done all over the code, the strategy is to find a place where this is happening, add a test that checks that the widgets match the state, and then move that code into something called by sync_state().
Federico... Any progress on this?
> I genuinely do not know any mature application that uses GtkIconView to show a potentially massive collection of items. Note how Nautilus doesn't use GtkIconView but uses GtkTreeView. ;) > The only major users of GtkIconView are the new GNOME 3 content applications, and they suffer pretty badly because of it. [...] Just for the record, Pitivi does use the Gtk IconView in a reasonably performant way and can have many hundreds (don't remember if I tried "multiple thousands", but I probably did) of thumbnails in there... that's probably because we did the investigation work and workaround that most other apps didn't do: Pitivi does batch insertions instead of creating items one by one, to work around IconView's performance limitations (with little visible impact to the user). This was how the performance hack was done back then: https://git.gnome.org/browse/pitivi/commit/?id=497976f4ef551f10d77ad51c121a86336e1eaa3e Now, I know, _I know_, that you're not hoping to use IconView in the long term (because reflowing etc.), I'm just stating this for the record, and in the eventuality that Federico needs it for a stopgap implementation (unclear to me if GtkFileChooserViewIface means that he's not using IconView at all in his branch). It's not "ideal" as a technical solution, but the resulting performance was usable.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/233.
#233 does not let users/enthusiasts share their feedback on the progress as it has been locked by the developers for past 2 years. There is no light to be seen at the end of this tunnel. Share your feedback here: https://gitlab.gnome.org/GNOME/gtk/-/issues/2054
Parag Agarwal: Deliberately wasting people's time by intentionally creating duplicates is not welcome. This is a technical issue tracker. If you want updates, feel free to contribute software patches. "me too" comments don't help and are not welcome. Thanks for your understanding.