GTK+ and GLib 2.4.2 are released. This is a bug fix release and is source and binary compatible with 2.4.0. There are a considerable number of fixes in this release, especially in the areas of GtkFileChooser, GtkComboBox and GtkEntryCompletion. Also, a problem on Solaris has been fixed.
GTK+ 2.4.2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
When do we get the ability to select hidden files with the new File Chooser? It seems all this release is for is bugs, which is never a bad thing.
Just right click and select it (it’s the only option). It’s a bit too well hidden I think. I had to be shown…..
Just right click. Take a look:
http://img21.photobucket.com/albums/v64/super_science_monkey/gtk_fi…
No you don’t.
This will show you hidden directories, not hidden files. It is a known bug.
Great. a new gtk+ release.
To tell you the truth, i never really liked the “New” file save/open dialog box. i feel as though its cluttered and confusing.
flame all you want, i dont care. just my .02 cents.
I don’t think people would ‘flame’ just for giving your opinion if it wasn’t pre-prended with sarcastic undertones, and appended with a challenge. We all know it’s your .02 already, also. Next time just leave the comment I never really liked the “New” file save/open dialog box. i feel as though its cluttered and confusing. and all will be well.
If it’s a flame, it will be moded down already.
As for the file selector, I like the new design, but think having a retro option would be neat. I am not familiar with the new dialog as I don’t use it, but is that option available? (Without installing the older GTK, almost like a skin?)
Right clicking in the save/open dialog does not give me the option of viewing hidden files, heh…
You right-click in the file area of the dialog, not on the window itself. I am using GTK+ 2.4.1.
1.The actual GtkF+ileChooser doesn’t use the mouse configuration for the desktop
2.The modes are so confusing
etc…
can we not just have a way to set the Filechooser as plugin?
So you could set a gConf key or so to your favorite FileChooser?
Why not have the Filechooser as an XML interface or what not.
The system does request a Filechooser and tells the Filechooser the bookmarks/mime-types, etc. ( or the Filechooser can pull them seperately ). And returns the File/Fileselection/Dir, what ever.
I would prefere that by far more!
I personally miss the [tab] completion feature from the Old Filechooser. I was like 20% faster in location a File… ohh well…
I have come to agree with Eugenia’s assertion that all features must be available by the menu. VS.NET 2003 has been driving me insane because it hides things in weird context menus, and has keyboard shortcuts that have no corresponding menu entries.
Any nay-sayers to the idea of having the option (via right-click menu) to “Browse This Folder” in GtkFileChooser? I was trying to change my Desktop Background so clicking on Add opened up the FileChooser, but it didn’t have previews! Nautilus does, so I was hoping a simple right-click, Browse This Folder option would be a nice thing to have. I’m sure other apps would benefit from that, eh wot?
I agree. I don’t think you should have context-only options. I would have never expected that from gnome. I like that they’re consistent and that seems inconsistent.
And what file browser would you use? GTK+ isn’t a part of any desktop, even if it has a close relationship with Gnome… It needs to steer clear of unreasonable Gnome dependencies. (Using a lib created by the Gnome team is one thing, but depending on Nautilus is a totally nother.)
“can we not just have a way to set the Filechooser as plugin?
So you could set a gConf key or so to your favorite FileChooser?”
You can. In fact, this is exactly how GtkFileChooser is designed.
The thing is, nobody has written an alternative GUI yet. You could be the one to do so.
For your specific problem, previews in the gnome-background-properties file choose are going to be in 2.8. As far as linking to nautilus from the filechooser, it is possible. It wouldn’t make GTK depend on GNOME. Notice that the new filechooser can use GNOME VFS. This doesn’t mean that Windows GTK users depend on GNOME VFS. They simply use a version of the filechooser widget that doesn’t rely on GNOME VFS. That’s the beauty of the new API – it is completely pluggable and adaptable to the environment/user.