Retitling for clarity and changing product.  We should really just follow the
Nautilus options for columns and such.

Is any work being done or planned on this one?

Personally I find "Modified date" not useful, however file size is a fundamental
file attribute I like to see.

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

I strongly agree that showing a 'file size' column should at least be offered via the API (if not just ALWAYS made present).

However, I feel that "modified" (i.e. date modified) is also easily understood by newbies and quite valuable, it should not be removed. Rather (I'm writing a new enhancement bug) we should expand the field to include the modification time, and use a CONSISTENT date format (not "Tuesday", "Monday", and then "12/12/2005").

There are limits to how dumbed-down you should go, I think. Even Windoze file manager shows you the modification time, it's NOT "too complicated".

Hi guys, I opened <a href="http://bugzilla.gnome.org/show_bug.cgi?id=324543">bug 324543</a> for the "modified" enhancement. When I downloaded the code to check out what I had to work with, guess what I found?

gtkfilechooserdefault.c already has code, currently disabled by "if 0" blocks, which define a column for file size. (My download was gtk+-2.8.8, not CVS.)

Federico, have you been working this?

Since Nautilus already shows it, I'm sure that it's available from Glib on all supported platforms. This might be VERY easy, unless GUI elements to select and deselect "details" are added (per Nautilus).

(In reply to comment #0)
> It could be useful being able to toggle additional columns...

Hoping that you and Dariusz are still listening to this bug:

I'm not thrilled with the prospect of adding a lot of GUI buttons to select from a gazillion columns, ala Nautilus. How about just the size?

If you want to sort via file-ext (reminder that's not file-type) your other RFE for user-entered wildcard matching, bug 141153, might be almost enough?

I think that file-type is buggy, we don't do proper matching of extensions versus "types". For example, a "something.php" page which was downloaded by a browser *DOESN'T* count as an "HTML file". On the other hand, a PHP Source page will certainly not appear correctly as an HTML page, it needs to be interpreted in a Web Server first. So, between the two, I think that file-ext is better.

But again-- can we get by with just the change in bug 324543, plus the size? And also, may I use xxxKB and yyyyMB to keep the width down?

Looking forward to your replies. (And those of anyone else with an opinion.)
   

Rick, in my personal opinion "Size" is essential. "Modified date/time" may have use sometimes (although I rarely use it, it does happen that I do). "File type" is not so critical, however it may have its use times too. I see the problems with determining type, not to mention passible side effect on speed (I'm not sure how fast this is). Being able to sort by extension would cover most of the uses for this column for me but I can't say for others.

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).

Now for the columns: adding just "Size" would work for me, yet I would like to hear opinions of others. How to manage many columns? See Mozilla Thunderbird -- the header for the list of mails has a small clever button as the last "column". When you click on it menu is displayed with names of all available columns and you can tick which ones you want and untick the ones you don't. Simple, intuitive.

And last: it would be great to be able to choose order of columns. But maybe I'm pushing for too much now? ;-)

Thanks Rick for looking at this one!

I think that this is best done in two steps:

(1) I'm gonna start by creating 'size' in KB, still showing everything unconditionally. Just to get that all working, see if Federico accepts it.

(2) Then, afterwards, a separate project for 'select columns to display, and their order'.

(3) And then, review whether we really want to have a 'extension' column, or whether filtering by pattern (bug 141153) is sufficient. I'm inclined to add the column, as long as the default is to NOT display it.

I would like to point out, that the Modified column should follow the date format set for Nautilus. (I was prepared to file a bug report just for that, but it seems it fits in here.)

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

Rick, any update on this?

Hi guys, I vanished for quite a while there, kinda hoping that someone competent would work on this.

When I hacked around to create the column (while ignoring the requirement to applying the correct locale), I hacked to solve both this bug AND http://bugzilla.gnome.org/show_bug.cgi?id=324543 at the same time. That bug has now been fixed by *real* programmers (Thanks!), and so my mis-submitted old "sample patch" attachment (entire source file, rather than the diff), wouldn't be even remotely close to matching the current CVS Trunk code.

Since I can't do locales properly, and don't really have time to learn, I think it would be a lot better for someone to just read the notes here (about how it is almost completely present already, disabled at compilation by "if 0" blocks).

But if you want me to give it a whirl, I'll recreate my "patch" against CVS and submit it in "diff" form.

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

I think it is time to retire this bug - the file chooser and nautilus are not the same, so sharing things one-to-one does not really make sense.