Owen Taylor released GTK+ 2.3.4, Glib 2.3.3 and Pango 1.3.3. These versions are intended for testing.
Gtk+ 2.3.4 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
Just wonder to know if gnome 2.5.6 will released tomorrow, I hope to use the BMG’s ebuild to emerge it.
and to test the new GtkFileSelect.
… really rocks. There was an entry on the gnome blogs about it a few days ago. They’re adopting the path widget thingy that I think I first saw in mockups at OSNews….
Shaping up to be a good release that’s for sure 🙂
slighly related news, GNOME Office on IRIX
http://www.nekochan.net/weblog/archives/000207.html
http://www.nekochan.net/albums/gnome2/abiword.jpg
Rocks? A file dialog where you must know some hidden shortcut to be able to type in path+filename? The developers failed to deal with all suggestions, now they let decide/implement the file dialog maintainer alone. I doubt that any usability expert is still involved in designing this central widget.
Additionally, the developers failed to implement a new file dialog for several releases/year – why should they succeed doing it properly when it’s now done in a hurry?
>Rocks? A file dialog where you must know some hidden >shortcut to be able to type in path+filename? The >developers failed to deal with all suggestions, now they >let decide/implement the file dialog maintainer alone. I >doubt that any usability expert is still involved in >designing this central widget.
What are your sources?
I wonder if there are any optimization improvements in terms of drawing?
As often said, most speed problems are from applications. gedit takes 3 times more than abiword on start up. And abiword is a word processor while gedit is an editor.
> What are your sources?
The problem is not that there is development power missing but wrong decisions are being made by those who are in charge.
Hi
”
The problem is not that there is development power missing but wrong decisions are being made by those who are in charge.”
blatant statements like that mean nothing. if you got complaints learn to voice it in a specific manner
regards
Jess
So you’re saying that the GTK2 port of gftp, gqview, bbrun and gnome-commander, are all written worse than their previous GTK versions? Because they all start up, and draw significantly slower. Or maybe it’s because GTK2 is much more powerful, which I unfortunately do not really care for, since GTK1 worked well enough for me.
I would be happier with GTK2 if it was compatible with GTK1, so I could simply configure new versions of apps with –enable-gtk1 and keep speed. Anti-aliased fonts and 32bit icons are really cute, but not when the memory and CPU penalty is more than 200%.
But this is just my damn opinion. Thanks for listening me out.
In regards to my statement, gtk2 can be faster when it comes to drawing as compared to qt3. Things feel snappier in qt3. Compare for exampe gnome-terminal to konsole. One specific area gtk2 seems slower is in drawing and placing text.
Apps written in purely gtk2 startup very fast. It’s the apps that use the gnome libraries that startup slow.
That may be due to having to link to so many more symbols at startup.
It’s not fair to compare gtk2 to gtk1 — they are apples and oranges. It’s more fair to compare gtk2 and qt3.
I’m happy that both exist, but I’d like gtk2 to improve in certain areas.
For those who are interested I think this is the post Mike was talking about in an earlier comment. (It shows of the path-widget that was also shown in mockups on this site
http://primates.ximian.com/~federico/news-2004-02.html#23
Actually, the new UI *was* designed by a UI expert: Seth Nickell, who also helped write the Gnome HIG.
You can see mockups of the new file selector at: http://www.gnome.org/~seth/filechooser-spec/
The new in-progress GUI is at: http://primates.ximian.com/%7Efederico/news-2004-02.html#23
Seth actually has a reason for removing the entry widget: it removes a layer of abstraction. From his site:
No entry widget means list selection is a direct manipulation, rather than going through a layer of abstraction. Conceptual model is “List selection chooses items to open” vs. “List selection changes the entry widget, the entry widget indicates the file name to open from the current path”.
Is this a good reason? I imagine so; he’s the usability expert. Will others agree with this? No. gnomedesktop.org already has a thread exceeding 100 messages with people complaining about how “wrong” it is to use Ctrl+L to open a new dialog box to enter path+filename. Others are complaining about the lack of tab completion.
Filename completion should still be present, it just won’t be tab completion. I’m not sure what the specifics are, though.
From Seth’s mock-up:
“Long term: It might be nice to not “destroy ahead” in the path widget, and only update the path widget when the path shown is inconsistent with the current hierarchy.”
I really hope they immediately put this in. Suppose you’re currently at [/] [home] [username] [Documents] [Thesis].
Then if you select [username], the path widget should not change unless you select a new folder in [username] because it would make it easier to go back to [Thesis] or [Documents].
Also, I really hope the reconsider including a “Select File” text widget which would have tab completion. I mean, what would be the confusion? Those who don’t know about tab completion would not’t use it, and it would make clear which file is currently selected. In fact, the latter should be justification enough to include it.
just my opinion …
> Is this a good reason? I imagine so; he’s the usability expert.
Did he test this design/implementation with different people or not? I guess not because they didn’t plan any time for this. Or is he just doing what he is thinking is right? Then he is no expert.
> Seth Nickell, who also helped write the Gnome HIG.
The GNOME HIG was at least partly the result of usability tests.
The new dialog is great. I’m a little hesitant about the C-l because there’s nowhere in the UI to let users know about it.
There’s no reason for 90% of desktop users to have to deal with obscure path strings and most will only put files in one of the default folders. If you know that you need to open file ~/.foorc then you can certainly hit control-l and type it. Of course, how your going to find out about that C-l is a mystery at this point.
BTW, the save dialog is better (better, as in, more intuitive) than the open dialog.
By “not designed by a usability expert” you actually mean “every GUI that I don’t like”. That’s the problem with you complainers – if you don’t like the GUI then you automatically mods it down like that and personally insult the developers. It’s exactly because of people like you why critics are not being taken seriously anymore.
You complainers all think you’re experts yourself. If you know better then why don’t you come up with your own GUI design (no you don’t have to be a programmer, making a dialog in Glade is just click & fill in some values!)?
Wait and see – once you’ve released your own design, that you think is 100% perfect and is usable by everyone, hundreds of people will complain and flame you down and insult you and mod you down for not being a usability expert.
It’s good to see improvements being made to the GTK+ file chooser. I dare say it’s a milestone advancement from its predecessor. More importantly, it is evident a lot of thought was put into its design.
The absence of a location entry comes as a usability surprise/shock to conventional Unix/Linux users. I think such changes should be refrained from in the future. Thankfully, it’s functionality can be activated by toggling the ‘Ctrl – l’ shortcut keys.
I cannot yet pass judgment on the new file choose. Not until I use it extensively. But from a superficial and observatory perspective, the changes are welcome, at least when compared to the old file chooser. And the reasons behind most of the changes are sound.
Kudos to the GTK+ developers!
Go and copy from Windows, err i mean take inspiration from Windows. Their open and save dialog rocks
You can do everything in them, that you can do in explorer, including renaming existing files/folders, creating new ones etc. Sometime when i am saving a file, i feel like renaming something else there not to overwrite it and with windows save file dialog, i can easily do it.
No one mentioned that the list of files are shown as a table of ‘filename, size, attrib, date…’, aka windows explorer’s ‘detail view’. It wastes a lot of space in large directory and we normally don’t need to known those information. I would like to see the file view just list the filename in a fixed width or height sheet. Like the ‘listview’ in windows explorer or the default unix ‘ls’ behavior. All the other information can either be shown in the status bar or tooltips. I admit there are no builtin widget can do that for now. maybe that is the reason most gtk based file manager all emulate the NC way of file panel.