The new Glib/GTK+ 2.2.3 and Pango 1.2.5 were released yesterday.
GTK 2.2.3 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
The new Glib/GTK+ 2.2.3 and Pango 1.2.5 were released yesterday.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t get it. What’s glib divided by gtk plus 2.23. I guess the g’s cancel each other out.
glib and gtk+ are shipped together. glib is a library that provides a great set of tools to use lists , queues , unicode , threads , files , hash data structure and other fun functions.
glib is used by gtk+ , gnome and other projects such as Arts , Koffice , libole2 and many other modern apps.
The fact that both gnome and kde apps use it makes it a real sucess story. I wish that more people would use glib.
I use it for http://libots.sf.net It gives me a great set of tools for using UTF-8 (unicode) functions , everything from a unicode char to functions to lowercase it or to check it’s type.
Is the new file selector in this version? =)
Victor.
Would you all quit whining about the file selector.
the version says 2.2.3, minor upgrade still in the 2.2 series, no new fileselector.
get over it or use KDE, whatever you do stop whining about that frikkin file-selector
What’s wrong with the old file-selector ? It works.. what more do you need?
There’s a reason why i (and lots of other people) whine so much about the file selector: it’s a very OLD discussion, and we’ve all agreed there is an urgent need for a new file selector.
Victor.
You must be kidding… the current file selector is great for geeks, not for the common user (for a number of reasons i don’t feel like repeating here… search on google and you’ll find it).
Victor.
>> I wish that more people would use glib.
I wish that more people would use stl/boost.
Not to start a flamewar, just to point out that we’ve all got our wishes.
There will be no new file selector in GTK+ 2.2.x. The official new one is planned for GTK+ 2.4.
However, there is an inofficial improved file selector for GTK+ 2.2.2:
http://gnomesupport.org/forums/viewtopic.php?t=3635
New features includes metadata viewing (like size, date and file type), file icons, navigation buttons (back, home, etc.), bookmarks, editable location field, and more.
I am currently working on porting the patch to 2.2.3.
I’m tempted to think that people asking about the File Selector are just trolling. I guess its a valid question, but does anyone think it is coming in a X.X.X release. This File Selector has been discussed here many times before and for quite a while, the answer has been that it is coming in 2.4. If you really didn’t know this already, you aren’t a troll, but you really should know by now. If you did know and just used the question to complain, then this is just politely disguised troll.
It makes finding files a chore, as opposed to the KDE (3.0 was better than 3.1) file selector, or even (gasp!) the Windows selector.
Do QT and GTK work in sync or something? I mean new versions are normally released at one time…
Just a quick note: Glib presents a C interface, while the STL and Boost libraries are C++. C programmers cannot use either STL or Boost, while C++ *can* use glib. Thus, glib is a lowest-common-denominator.
There is a *new* and *much improved* file-selector in the form of a patch to gtk+…..
Look here for discussion
http://gnomesupport.org/forums/viewtopic.php?t=3635&postdays=0&post…
and here for the patch….
http://members1.chello.nl/~h.lai/gtkenhancements/
From the above listed URL:Enhanced file selector
* The file selector now has Back, Up, Reload, Home, Bookmarks, Terminal and File Manager buttons. All toolbar buttons have tooltips.
* The file operation buttons are turned into toolbar buttons with nice icons.
* Removed the . and .. from the file list; they are now replaced by the Reload and Up buttons.
* UI cleanups: I changed the spacing in order to make the dialog look nicer and more HIG-compliant.
* The file list now has a Date and Size field.
* Removed the “Selection: /foo” label since it’s kind of redundant. This also gives more space to the file list.
* The pulldown menu has been changed to a combo box. This can also be accessed using Ctrl+L.
* It will remember the last directory you visited, even when the GtkFileSelector widget is destroyed.
* If the app is linked to gnome-vfs, the file selector will display each file’s file type name. If the app is linked to libgnomeui too, the file selector will also display the file icons. This feature does not add any dependancies to gnome-vfs or libgnomeui! Pure GTK+ will work like before, but GNOME apps will “magically” gain the ability to display file types and icons.
and finally a picture….
http://members1.chello.nl/~h.lai/gtkenhancements/filesel-new-small….
Boost and STL make use of templates that are typesafe, and are type checked at compile time. Why would they want to give that up to use glib even if its the lowest common denominator?
You probably wanted to show this screenshot instead: http://members1.chello.nl/~h.lai/gtkenhancements/filesel-new.png
People here should go to the discussion forum first before downloading anything. http://gnomesupport.org/forums/viewtopic.php?t=3635&postdays=0&post…
But, I agree it’s a great improvement nontheless. Also, teh old one wasn’t even good for geeks if you ask me.
Boost and STL make use of templates that are typesafe, and are type checked at compile time. Why would they want to give that up to use glib even if its the lowest common denominator?
Different people have different reasons to not want or not bea ble to use C++. Until C++ has the linguistic portability of C under Linux, it won’t be acceptible. (I’m talking here about language, not architecture.)
Oh, and only stupid languages make the user care about types
Then what more do you want in a file selector other than file filters?
Hmm, looks good… Better than the one in KDE (and I’m a KDE user).
just using standard c++ features will make your code 200% more readable and save you a dependancy on a legacy library.
You should care about if it’s glib (libc6) or Glib (GTK).