After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141155 - Share column settings with Nautilus
Share column settings with Nautilus
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.4.x
Other All
: Normal enhancement
: Medium feature
Assigned To: gtk-bugs
Federico Mena Quintero
: 312012 327232 363987 (view as bug list)
Depends on: 80867
Blocks: filechooser-nautilus
 
 
Reported: 2004-04-26 16:14 UTC by Hakon
Modified: 2015-07-07 04:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hakon 2004-04-26 16:14:40 UTC
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 opinon.
Comment 1 Federico Mena Quintero 2004-07-09 01:18:42 UTC
Retitling for clarity and changing product.  We should really just follow the
Nautilus options for columns and such.
Comment 2 Dariusz Garbowski 2005-02-24 22:16:57 UTC
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.
Comment 3 Federico Mena Quintero 2005-11-11 20:06:10 UTC
*** Bug 312012 has been marked as a duplicate of this bug. ***
Comment 4 Rick Stockton 2005-12-19 20:56:03 UTC
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".
Comment 5 Rick Stockton 2005-12-23 08:23:13 UTC
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).
Comment 6 Rick Stockton 2005-12-27 00:46:54 UTC
(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.)
   
Comment 7 Dariusz Garbowski 2005-12-27 10:40:03 UTC
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!
Comment 8 Rick Stockton 2005-12-27 21:25:14 UTC
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.
Comment 9 thorwil 2006-02-13 14:20:59 UTC
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.)
Comment 10 Federico Mena Quintero 2007-01-25 17:05:38 UTC
*** Bug 327232 has been marked as a duplicate of this bug. ***
Comment 11 Alexandre Prokoudine 2007-09-12 11:17:32 UTC
Rick, any update on this?
Comment 12 Rick Stockton 2008-01-07 05:37:25 UTC
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.
Comment 13 Federico Mena Quintero 2013-05-17 19:43:59 UTC
*** Bug 363987 has been marked as a duplicate of this bug. ***
Comment 14 Matthias Clasen 2015-07-07 04:48:43 UTC
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.