This bug-fixing version of GTK+ 2.4.11 fixes a number of bugs mostly in the file selector area. GLib 2.4.7 was also released.
GTK+ 2.4.11 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
Why each new Qt release is not noitced here?
Is not a new post about each upcoming GTK+ minor version a little overkill?
Anyway, they don’t fix major problems GTK has…
did you ever try submitting any?
OSNews seems to be a GTK+ site, hence the GNOMEFiles connection etc. But if you submit it it’ll probably get mentioned – its just more like Eugenia will notice GTK+ herself, and not QT updates.
huh?
http://www.osnews.com/story.php?news_id=8370
http://www.osnews.com/story.php?news_id=8003
http://www.osnews.com/story.php?news_id=8070
http://www.osnews.com/story.php?news_id=8234
http://www.osnews.com/story.php?news_id=7622
http://www.osnews.com/story.php?news_id=6875
The above is a number of recent articles on QT related releases..
Are people completely incapable of using search?
…and more…
http://www.osnews.com/topic.php?icon=59
We always report news on new Qt releases as soon as they become available. In fact, we have a very good business relationship with the Trolltech guys (in fact, the CEO was at my house a few months ago).
I suggest you lay off your laughable conspiracy theories and get back on topic.
>and get back on topic.
That’s the problem — there’s not much to talk about. The Gtk folks seem to ignore the major problems this toolkit had since years, while providing useless bugfixes. Luckily I don’t use Gtk apps anymore. 😉
I couldn’t agree more.
seeing notices for releases of minor versions of GTK+ (or Qt or whatever) is both boring and useless.
unless there a huge security issue or a brand new feature (new FileOpen dialog, whatever), there is nothing NEW to speak about.
unless there a huge security issue or a brand new feature (new FileOpen dialog, whatever), there is nothing NEW to speak about.
Well…you could always try NOT speaking.
ok, here we go, right from the link :
* GtkFileChooser
– Make path bar arrows larger
– Make SELECT_FOLDER mode work
– Speed up the completion popup
– Update the preview when searching
– Pop up completions again when tab is pressed
– Don’t prepopulate the location entry
this is sooo exciting. stop the press, tell the world !
excuse me while I wet my pants.
Stop the flame, would you?
Anyway…one bad news in South Korea: the Hancom Linux, one of the largest Linux distributer in South Korea, went bankrupt in 4th of October.
They contributed A LOT to KDE community in S. Korea. (improvement to Hangul handling in kdelibs and Qt)
“The Gtk folks seem to ignore the major problems this toolkit had since years, while providing useless bugfixes. Luckily I don’t use Gtk apps anymore. ;-)”
Oh really? So tell me. Is this why GTK Win32 went from being virtually unusable a year ago, to being extremely stable today? Because they haven’t been fixing bugs? Yeah right. They have a done a very good job at fixing bugs.
It is the Filechooser repeated but then with other “problems” GTK+ seemingly (according the trolls) not caring about. This time it is speed. Off-course are the trolls ignoring that there is a a massive backend change planned (cairo) for gtk+ so it is quiet pointless to work on depecrated code (unless it are real showstoppers). GTK+ as quiet a hate-group following.
Garrrrr….the sssspeed thing again…!
I think GTK+ is quite fast….But text rendering and resizing is slower than Qt…due to our beloved Pango library. Some westerners might hate pango for slowness…but to us East Asian, pango is the most indespensable part of GTK+!! (YEAH!! I LOVE IMHANGUL2 Pango Module!!! I LOVE NABI Korean Input Method!!!! Hurray!!!)
Anyway…I don’t resize Window very often…so I don’t have much problem at all. So never felt GTK+ slow. :3
If somebody finds a way to speed up Pango w/o sacrificing its great Multilanguage handling capacity, he will be a hero.
I don’t want to hear about GTK till they are using Cairo. Maybe i’m being a jackass, but i’m foaming at the mouth (eye?) for some more eyecandy
Really, Hancom is not anymore ?
That is really sad. 2-3 years ago, they were really big.
And what happened to hancom office ? Their Office suite ? It’s a really nice software!
And what happened to hancom office ? Their Office suite ? It’s a really nice software!
But then again, if you compared it to what we have now, even KOffice is competitive when compared against Hancom Office; what Linux “entrapranuers” are failing to realise is “its the friggin applications!” that matter. Someone setup another Loki like operation, port applications, sell them and split the profit with the original IP owner, the profit made off that would be considerably more than trying to re-invent the wheeel again or creating yet ANOTHER Linux distribution.
Why each new Qt release is not noitced here?
Releases of Qt do get mentioned here, and I’ve seen quite a few articles about Qt, and not just about a new release.
There just isn’t as many iterative releases of it as GTK has, so we get more news about GTK releases. Not rocket science.
It wouldn’t be THAT bad if it was only the text rendering, but the WHOLE toolkit is damn slow. Not only resizing, but redrawing, etc. For some reason, many GTK+ applications are slow compared to QT counterparts (JuK identified my 20GB MP3/OGG collection over NFS in about two minutes, Rhythmbox in over ten)… and I don’t think that’s a Xfree/X.org problem, given that QT is fast and GTK+ is incredibly slow even on MS Windows (I use GAIM and GIMP). It might be fast inside the hood but perception is everything when you use a computer.
But I must admit that it does look better and might be a blessing for those who don’t use the LATIN-1 alphabet…
I program with GTK, and personally I don’t think it is slow at all.
Remember, that when you make performance comparisions like this, the two apps have to be IDENTICAL except for the GUI code. Otherwise the comparision is invalid. Performance usually has a lot more to do with what the code is doing under the hood then with the GUI toolkit being used.
Yeah, I know, that’s why I said “for some reason”.
But GTK applications just feel über-slow here. Like I said, I have tried them on Linux and Windows and the redraw is painful… I don’t resize my windows that often but I often have windows over others. My computers are relatively fast (two AXP 2500+, one Centrino 1.7G) so I don’t think they can’t handle the TK.
But hey, I don’t hate the toolkit itself. Before I had to switch to KDE, I was using GNOME or XFCE with only GTK apps. Perhaps that’s why I never had noticed the crawlness. I just wish it was faster from the perspective of an user.