GNOME Bugzilla – Bug 325095
show a 'size' column (all the time, no 'toggle' ability)
Last modified: 2009-07-15 23:42:35 UTC
+++ This bug was initially created as a clone of Bug #141155 +++ Original Bug is: "It could be useful being able to toggle additional columns, like file-type and size, because those are no less useful than "Modified date" in my personal opinion." Per comments 6-7-8, on that bug, I'm creating this one to separately track implementation of the 'size' column. I've already finished my patch, it works (although I've only tested on Linux with EN-US locale).
Comment 7 in #141155 said: "After some thinking about how to display size I have come to the conclusion that using only KB would be enough. I'm not so fond of mixing different "units" in one column like mc (Midnight Commander) does -- you don't see right away how big the file really is, you have to interpret the number by looking at units first (bad...). This is one of the things that Microsoft got right (see their's fileselector -- they display everything in KB and it works well and is easy to see how big the file(s) are by just a quick glimps on the list)....." So I cut out the code to format as 'KB', 'MB', 'GB', and raw bytes separately. Rather than convert to floating point and print with %1f, I simply round off to the nearest 1K by adding 512, then doing a gint64 divide. Source code looks bigger with the funky cast-and-store, but it avoids printing a decimal point (and matches Microsoft 'Windows Explorer', as requested. If you want, go ahead and convert back to a floating point divide and print-with-decimal-point.
There were a couple of problems in the code for list_size_data_func() when I enabled it: (1) there was at least one mistake in trying to initialize "impl" and "info" as constants. Fixed by separating the declarations from setting the values (in runtime code). Can you even declare a ptr to be the evaluated-at-runtime result of a function? I copied the declarations and code from the almost identical list_mtime_data_func(), the next function below this routine in the source file. (2) The "Directory" files were getting totally bogus values, because we didn't set the right number of parameters for g_object_set (). The calls which set 'Name' and 'Date' values both call g_object_set() with 6 parms, including "" as a value for text when an empty cell is desired. Again, I copied from the working call in list_size_data_func().
Created attachment 56457 [details] functional source code for list_size_data_func() There are a few "#if 0 .... #endif" blocks which need to be enabled to make this work. Sorry I didn't keep track of the line #s, but it's obvious which blocks relate to list_size_data_func() versus drag-and-drop stuff.
It would look better if we could make the 'size' justified-right, instead of left. We'll need to increase the initial width of the Box (source line #241 in today's CVS): currently: #define NUM_CHARS 60 should be about: #define NUM_CHARS 77 And also, a new line preceeding today's 3721, which is: gtk_tree_view_column_set_title (column, _("Size")); should be preceeded by: gtk_tree_view_column_set_resizable (column, TRUE);
If you use a gint64 for the file size, you can use this for the printf format: str = g_strdup_printf (_("%" G_GINT64_FORMAT " KB"), size); Don't put spaces around the format specifier; padding is the job of GtkTreeView.
A) Isn't this clutter eating valuable horizontal space? Is file size actually useful for most people to locate a file? B) If added, it really does need to use the mixed units and match nautilus. There should be code somewhere in the CVS history that does that, since a prototype version did have a file size.
Are we talking about adding the size column unconditionally ? I thought adding more columns would only be done together with a column editor...
*** Bug 329348 has been marked as a duplicate of this bug. ***
This feature is really needed. Use case: Folder with multiple log files. Question: Which one is interesting? Usually the file size gives some clue about this.
Use case 2: Attaching large files to emails. Does it fit?
Strange, gtkfilechooserdefault.c contains fully functional, but disabled code.
(In reply to comment #11) > Strange, gtkfilechooserdefault.c contains fully functional, but disabled code. see comment #6 for why it has been disabled. (In reply to comment #7) > Are we talking about adding the size column unconditionally ? > I thought adding more columns would only be done together with a column > editor... now that the file chooser can save some of its state we could probably add an item in the context menu, like 'Show size' for those with a screen wide enough.
Hi there, I don't want to be destructive - starting a new bug "gtk+ filechooser deters gnome users" - but would rather like to share my personal impression with this central, but insufficient GTK+ module. It took me quite a while to find the right assignment for this bug, BTW. for some reason, Debian favors Gnome to be the default desktop. My reason for using KDE is mainly Gnomes file browser. But as a matter of fact, major applications are using the GTK2 libraries (Mozilla, Openoffice.org, Gimp, Audacity etc.) - and Opneoffice.org is the only one that allows to use the KDE file selector. Now, what's wrong with the GTK2 file chooser? I will report a bug if anybody could name the package/library I have to refer to. Look at this screen shot for instance: http://imagebin.ca/view/wxHN3lH.html (1) all entries are displayed twice (2) there is no option to sort by size or to even display size. maybe this must be enabled by the calling app (audacity here) - but if this option is not diallowed explicitly, it should be possible to add it by the browsing user. (3) whenever I tell Mozilla to open a dialogue with a specific app, I can (to be quick) enter its path right in the file name box (say: /usr/bin/ark). Next time however, the file selector will start browsing that directory (/usr/bin) and produce a hang lasting at least 4-5 seconds. Suspecting - missing caching - slow algorithms - bad threading (4) missing eyecandiness: grey and simple icons, no rounded corners, dominating dark grey, low percentage of area used for content/ information (too much frame). Sorry, don't get me wrong - I just wanted to share my personal impression of this fun stopper - it's like a hair in a five star soup! Posted before to debian-devel ML: ================================= Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by liszt.debian.org (Postfix) with SMTP id 2586D13A5525 for <debian-devel@lists.debian.org>; Sat, 9 Aug 2008 13:13:01 +0000
P.S.: extract from "dpkg -l libgnom*" ii libgnome32 1.4.2-37+b1 ii libgnome2-0 2.20.1.1-1 ii libgnomesupport0 1.4.2-37+b1 ii libgnomeui-0 2.20.1.1-1 ii libgnomeui-common 2.20.1.1-1 ii libgnomeui-dev 2.20.1.1-1 uname -a Linux localhost 2.6.22-3-k7 #1 SMP Sun Feb 10 21:04:14 UTC 2008 i686 GNU/Linux [Debian Testing] $ apt-cache policy libgnome2-0 libgnome2-0: Installiert: 2.20.1.1-1 Kandidat: 2.20.1.1-1 Versions-Tabelle: 2.22.0-1 0 1 http://ftp.de.debian.org experimental/main Packages *** 2.20.1.1-1 0 500 http://ftp.de.debian.org unstable/main Packages 990 ftp://ftp.de.debian.org testing/main Packages 100 /var/lib/dpkg/status
*** Bug 550907 has been marked as a duplicate of this bug. ***
I would like to note that this bug is in the current released version of gtk+ (not just 2.4.x) and that it is being complained about on blogs etc: http://forums.mozillazine.org/viewtopic.php?f=7&t=318860&st=0&sk=t&sd=a&start=30 http://changelog.complete.org/posts/449-fromdrupal.html#c18918
(In reply to comment #16) > I would like to note that this bug is in the current released version of gtk+ > (not just 2.4.x) and that it is being complained about on blogs etc: > > http://forums.mozillazine.org/viewtopic.php?f=7&t=318860&st=0&sk=t&sd=a&start=30 > http://changelog.complete.org/posts/449-fromdrupal.html#c18918 thank you, we are very aware of this issue - and that the FileChooser is always the pick of so-called "usability experts". please: read comment #6 and comment #12 and remember that patches are always welcomed.
Created attachment 118907 [details] [review] [PATCH] Show the file size column since I was bored of people asking for this, here's the patch that adds a GtkFileChooserSetting and its relative context menu item for toggling the size column and enables the size column code path. it's probably going to bomb out with the search mode and the recent files mode, so this is jus a *proof of concept* patch. I don't understand why the description has a '(all the time, no 'toggle' ability): most of the time you don't want to see this column - like you don't want to see the hidden files most of the times.
Created attachment 118908 [details] [review] [PATCH] Conditionally show the file size column Add a new setting to the FileChooser default implementation for conditionally controlling the visibility of the file size column. This patch adds a new setting to GtkFileChooserSettings which is controlled by a check menu item inside the context menu of the file list. The file size is formatted using g_format_size_for_display(). The file size is only visible in BROWSE mode because the SEARCH and RECENT modes do not store GFileInfo inside their models. diffstat -w74 gtk-file-chooser-show-size-column.patch gtkfilechooserdefault.c | 87 ++++++++++++++++++++++++++++++----------- gtkfilechooserprivate.h | 3 + gtkfilechoosersettings.c | 27 ++++++++++++ gtkfilechoosersettings.h | 13 +++--- 4 files changed, 102 insertions(+), 28 deletions(-)
(In reply to comment #13) > Hi there, > > I don't want to be destructive - starting a new bug "gtk+ filechooser deters > gnome users" - but would rather like to share my personal impression with this > central, but insufficient GTK+ module. It took me quite a while to find the > right assignment for this bug, BTW. and yet you picked the wrong bug. also, for further reference, any bug with a description like "gtk+ filechooser deters gnome users" should be closed as RESOLVED NOTABUG (since we miss the more fitting a GOAWAY resolution) unless it provides feedback in form of usability studies, profiling or patches. > (1) all entries are displayed twice the only proper bug, already reported and already fixed as far as I remember. > (2) there is no option to sort by size or to even display size. > maybe this must be enabled by the calling app (audacity here) > - but if this option is not diallowed explicitly, it should be > possible to add it by the browsing user. this is the only thing that belongs to this RFE. > (3) whenever I tell Mozilla to open a dialogue with a specific app, > I can (to be quick) enter its path right in the file name box > (say: /usr/bin/ark). Next time however, the file selector will > start browsing that directory (/usr/bin) and produce a hang > lasting at least 4-5 seconds. Suspecting > - missing caching > - slow algorithms > - bad threading or, 4.: mozilla being utterly crap and dumping the user into /usr/bin to choose an application using the binary name. known issue. > (4) missing eyecandiness: grey and simple icons, no rounded corners, > dominating dark grey, low percentage of area used for content/ > information (too much frame). try changing gtk+ theme and/or icon theme.
I like the idea. But isn't the patch missing the part where the setting get written out ?
(In reply to comment #21) > I like the idea. But isn't the patch missing the part where the setting get > written out ? true. also, it shouldn't warn if the parser can't find a key in the file - but just use the default. updating the patch now.
Created attachment 118933 [details] [review] [PATCH] Conditionally show the file size column new version of the patch in attachment 118908 [details] [review] the updated patch saves the newly added ShowSizeColumn key to the FileChooser settings file. the patch also relaxes the parser to avoid warnings in case any key is not found - to allow future expansion for the file itself. diffstat -w74 gtk-file-chooser-show-size-column.patch gtkfilechooserdefault.c | 87 ++++++++++++++++++++++++++++++----------- gtkfilechooserprivate.h | 3 + gtkfilechoosersettings.c | 53 ++++++++++++++++++++---- gtkfilechoosersettings.h | 13 +++--- 4 files changed, 118 insertions(+), 38 deletions(-)
Looks good to me now. Do you think we should work towards supporting the size column for search and recent, too ?
(In reply to comment #24) > Looks good to me now. cool. > Do you think we should work towards supporting the size column for search and > recent, too ? it would basically boil down to: - add the GFileInfo to a column inside the search and recently used models; maybe just a G_TYPE_INT column - might be easier - get a GFile when populating the search and recently used models - queue a GFileInfo request for each row definitely possible.
committed to trunk. will open a bug for showing the file size in the other two modes. 2008-09-18 Emmanuele Bassi <ebassi@linux.intel.com> Bug 325095 – show a 'size' column * gtk/gtkfilechooserdefault.c: * gtk/gtkfilechooserprivate.h: Add a context menu item controlling the visibility of the file size column. This works only for the browse mode, and the column is not visible by default. * gtk/gtkfilechoosersettings.[ch]: Add a ShowSizeColumn key to the settings file.
I'm using gtk 2.16 (released in April IIRC) in Ubuntu 9.04 and I still don't see a size column in the filechooser. Did it make it into 2.16?
yes. did you read the commit message right above your comment ?!
Maybe that comment #27 reveals that this feature is hardly discoverable Why not letting the size column be visible by default ?
Considering comment #12 "now that the file chooser can save some of its state we could probably add an item in the context menu, like 'Show size' for those with a screen wide enough" I don't think that those with a screen not wide enough are in the majority Maybe default setting should be set regarding those that are in the majority. Why not taher adding an item in the context menu, like 'Hide size' for those with a screen not wide enough ?
What would be very smart would be if GTK+ could know what is the screen resolution and could set itself in consequence...
Set this check box once and it will be remembered forever, get over it...
(In reply to comment #27) > I'm using gtk 2.16 (released in April IIRC) in Ubuntu 9.04 and I still don't > see a size column in the filechooser. Did it make it into 2.16? > No, this is for 2.18 only.
> yes. did you read the commit message right above your comment ?! Just to clarify: yes, and no. What I read was the bug title which contained "all the time, no 'toggle' ability", and I read the commit message summay line which had the commit date, and then infered the version of GTK this was released in according to the date. Inattention mistakes happen, sorry. > No, this is for 2.18 only. Well now, who to believe? I guess I'll check at home if there's a popup menu checkbox to show file columns :) > Set this check box once and it will be remembered forever, get over it... Just for the sake of the argument, most "not tech savvy" users (I've seen this firsthand) have no clue whatsoever they can use a popup menu (right click). Even the HIG documents this phenomenon. And again for the fun of arguing on displaying info by default vs saving space, - I do have a 1024x600 netbook and I certainly wouldn't even miss this space taken by a simple "Size" colum. - How many people run in 640x480 these days? My analytics stats from many websites don't even have a single data point of 640x480 in the last months, and only 0.60% are on 800x600, 11.62% on 1024x768, and the rest is on much higher resolutions. But then, this is just food for thought. I'll probably just use the feature and assume that filesizes are for hardcore geeks/power users and go on with my life. I've lived without them in the filechooser so far, and they're much less important to me than, say, a thumbnail view (the infamous bug #141154). So thanks for your efforts and sorry for the confusion I had by not reading correctly the commit details :)
Overview of Changes from GTK+ 2.14.x to 2.15.0 ============================================== * GtkFileChooser - Optionally shows file sizes
ok i'm at home and i've just tried this new functionality and it's great, many thanks to developpers ! But it's really really really not easy to discover : - 1st you have to think : "i should try to open the contextual menu within the chooser to see if there is an option to get a new column that would show files size" (i guess that not everybody will think that). - 2nd, you have to be sure to open the contextual menu from the inside of the main pane of the chooser. Which is not obvious since you want to act on columns. Indeed, if you're used to spreadsheets you may try to right-click on the column titles which doesn't open any contextual menu (Whereas there's no contradiction to have the "show hidden files" entry that way since it does act on the inside of the main pane and not on columns) Considering 1° and 2° i'm not sure that a lot of people are aware of this (great) functionality ? Jean-François Fortin Tam says (Comment #34) : "And again for the fun of arguing on displaying info by default vs saving space, - I do have a 1024x600 netbook and I certainly wouldn't even miss this space taken by a simple "Size" colum. - How many people run in 640x480 these days? My analytics stats from many websites don't even have a single data point of 640x480 in the last months, and only 0.60% are on 800x600, 11.62% on 1024x768, and the rest is on much higher resolutions." Maybe that column should just be there by default, what do you think ? Is it the right place to argue or shall i open another bug report ?
Showing the size column is the default now; commit 68171b506f1a77b33367f69364d9991a4558a242.(In reply to comment #35) > Overview of Changes from GTK+ 2.14.x to 2.15.0 > ============================================== > > * GtkFileChooser > - Optionally shows file sizes Sorry, I got confused with the feature to remember the sort state; that one is indeed only for 2.18 :)
Concerning the feature discoverability, maybe that Bug 141154 could be the solution (by adding a way of choosing between multiple views :list, icon, thumbnail, etc. in the file selector. Also, Bug 141154#c28 by Nicolò Chieffo points out something that looks interesting : "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)." For instance on MS Windows it strikes me that the file selector is a declension of Explorer but maybe i'm wrong ?
I just came across this bug - surprised there hasn't been the addition of something like gtk_file_chooser_set/get_show_file_size_column() to the same extent of gtk_file_chooser_set/get_show_hidden().