Along with the stable bug fix release of GTK+ 2.4.10, the unstable feature releases of GLib-2.5.3 and GTK+ 2.5.3 were also made available.
GTK+ 2.4.10 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
What are the user-visible changes in the GTK 2.5.x and 2.6 line?
> What are the user-visible changes in the GTK 2.5.x and 2.6 line?
http://www.gtk.org/plan/
http://www.gtk.org/plan/2.6/
That has got to be the most uninspired roadmap I’ve ever seen.
Two years for maintence releases? Was it really that broken?
>That has got to be the most uninspired roadmap I’ve ever seen.
I am really sorry that I would have to agree with this. I like the Gnome Desktop usability (still with its flaws, but I prefer it from any other X alternative), but GTK+ itself and Gnome development blows.
And what’s worse, it doesn’t seem to be getting any better. GTK+ has just too many problems, including documentation and speed probs (and its theme engines are also very unoptimized) etc
Out of curiosity, what would you like to see?
Any since it is open source, I really can’t see any thing standing in your way that would keep you from implementing it.
That has got to be the most uninspired roadmap I’ve ever seen.
Did you not see the new planned about dialog!?!
Hmm I must admit that the development of gtk (and parts of the gnome development model) is not going very fast. On some levels (eg. usability, accessbility, dbus/hal, gstreamer) it is great to see all the new inspriring stuff that is being worked on (and clearly was needed if linux should head into the desktop), but it would also be nice to see some action being taken of the broken parts (eg. speed of gtk apps compared to QT apps).
Sometimes the gtk/glib thing remindes me of xfree before it was forked into xorg: slow development and ignoring the users, seams to be the way that things are done. Perhaps the lack of speed in gtk is not only due to the way gtk is implmented (I do not know if this is true however), but at least a lot of people seams to experience that gtk apps feels slow, so the developers should pay attention to this.
Well I love Gnome and the open source model will make sure that the problems will be taken care of, at some point. So perhaps I should just stop complaning and do something about it.
I’ve answered to it at
http://sinsalabintrix.blogspot.com/2004/09/on-gtk-uninspiring-roadm…
Wasn’t the percieved slowness of gtk, when moving/resizing due to the double buffering done in software?
If they move to a backend that can utilise OpenGL won’t the smoothness (maybe percieved speed) increase?
NOTE: I am not really familiar with the technologies used. I just vaguely remember reading something on OSNEWS.
My opinion on the topic is that there is a distict difference between “working slow” and “what to work on”. To me, it seems that the leadership of the GTK project is coming up with little to “work on” thus, it looks like the developers are “working slowly”.
What do others think.
Are you guys blind? GTK 2.8 ideas have some of the most exciting improvements in a long time – native transparency support, Cairo support (which would bring those performance improvements you guys are crying about).
So except for the major architectural changes in 2.8, it looks like most of their work is directed into better cross-platform and internationalization support. I’ve got no complaints there.
It’s apalling to see how people are mixing their criticism of GTK+ with GNOME. GTK+ is just a toolkit created for the Gimp, nothing more. It is not linked to gstreamer, HAL, DBUS, etc. Those are all parts of GNOME which just happened to choose GTK+ as its widget toolkit.
The 2.6 feature list may not be that exciting but the 2.8 features look pretty cool. The stuff they have in the “The future of rendering in GNOME” presentation on that site looks pretty sweet.
That’s where you are wrong. If GTK+ doesn’t get up to speed with the times and fixes its issues, it is Gnome and its users that will ultimately suffer, not Gimp.
QT is charging $1000 per year per machine. with that kind of money atleast they can hire decent programmers. remmember GTK doesnt get any money (except for donations). and they are distributing it for free.
I am aware of this, my only complaint is that people have been complaining of the speed of gtk based apps for ages and all that I have heard back in response was either noting or that this was not an gtk issue. If it is not a gtk isssue then the gtk developers should make documentation avalibel that will allow for us deelopers to implment responsive apps using gtk.
It seams that 2.8 will indeed be a sweet release, if all the planed spiffy stuff gets implemented.
The only thing that looks uninspiring is the webpage. But that’s not unusal since many GNOME projects have no webpage at all. Or they are, uhm, a little bit outdated, like http://www.pango.org
I’m rather glad, the basic libaries make small steps. Some of the cool applications written in GTK1 are still no ported to version 2. And Debian Sarge may be one of the last distros that ship version 1. The functionality in those apps will then soon be lost.
An example was Scigraphica which looked dead for almost 2 years. But according to the mailing list, the efforts of a few brave hackers resurrected the project.
Another nice example is terraform, an once awfully cool landscape generator. From the mailing list, it reads they already converted the code from GTKmm1.2 to GTK2.2 in CVS but apparently forgot to release it two years ago.
Given these examples — and I have a few more just in case someone is bored and needs a challenge –, I wonder why should the community bother with an improved development speed of the underlying libaries?
DBUS is more freedesktop.org than GNOME.
It can be used without GTK+ and GNOME libraries.
There are other things which are GNOME sprecific.
GTK+ might have been create for GIMP, but that’s past.
One thing why GTK seems to move so slowly is that there are unwilling to break backward binary compatibility, as well as source compatibility. (API and ABI). Software compiled for GTK 2.0 should still run on GTK+2.6 without recompiling and so on. I am not really sure how Qt does it, but it may be different.
That’s admirable, but Qt does the same thing. All 3.x releases are binary-compatible. Because of the fragile-base-class problem in C++, Qt and KDE take particular care in clearly noting when binary compatibility is broken (x.0 releases) and the deprecation schedules of to-be-removed features.
Some interesting presentations and papers by Owen Taylor on the future of GTK+.
http://people.redhat.com/otaylor/guadec5/
Oh, and the gtk+ apps are slow, is all bullocks!
No it isn’t. I’m typing this from a Fedora Core 3 install (wanna see what all the fuss is about
. It’s using GTK+ 2.4.9, with a back-port of the synchronized resize feature that’s in GTK+ 2.5.x. It’s definitely faster than previous iterations, but it still isn’t fast. The biggest problem spots are Epiphany (can’t even resize a simple window showing OSNews without lag), Gpdf, Gedit, and GNOME-terminal, which are slow enough that it significantly impacts usability.
What’s your hardware spec? What version(type) of X are you using? The resize issue seems to be a problem in X. And frankly, I don’t know any user who spends considerable amount of time resizing windows. Besides, lag during resizing doesn’t mean GTK is slow, it may mean it isn’t syncing properly with X. It is a timing issue, not a speed issue.
GTK+ still has one of the most responsive interfaces I have used. By X, I mean xfree or xorg.
What did that have to do with any thing?
You just ranted on about browsers, css, javascript, installing stuff from the net, and ect…
Nothing dealing with a toolkit.
My system is a 2GHz P4 with a GeForce4Go, Xorg 6.8.0, and the NVIDIA drivers with RenderAccel enabled.
The resizing thing isn’t an X problem, it’s a GTK+ problem. It’s also not a synchronization problem, since Fedora’s GTK+ uses the new NET_WM_SYNC feature. It’s just a matter of windows not redrawing quickly enough in response to a resize. Like I said, it’s a lot better, but there are still problem areas, particularly in any window with a lot of text.
Some years ago, when Gnome was just 1.x version, many people in Korea chose kde…but since after 2.x series rolled out, they began to prefer gnome over kde.
1. Gnome (and gtk+) has superior support for multibyte language like Korean. This multilanguage feature (pango) may slows down speed, but for me as Korean, would prefer more language usability than little bit of more speed.
2. Gtk+ has imhangul2, also thanks to pango…and it is ultra sweet
“What did that have to do with any thing?
You just ranted on about browsers, css, javascript, installing stuff from the net, and ect…
Nothing dealing with a toolkit.”
Actually, if there is no interest in the desktop, there is no need for change, investment, etc. There are some applications that need a fast toolkit, but many of these applications have already been written, so no need to worry about that. That is, many applications that need to be built can do alright without QT or GTK. Let’s be practical and assume that the desktop with KDE and GNOME and all the existing apps is powerful enough. No need for one of the two to take over the desktop, and have all the applications written for the winner. The little details that would make the desktop a little bit better can be worked out along the way, no need to hurry (no money to hurry.)
The reason why text-heavy applications are slow is because Xrender (which is used by Xft) is un-optimized. If you really dislike it, hack on it, or help cairo rock by next year.
The 2.6 release is focusing on stabilizing features introduced in 2.4 and adding a few oft-requested features. The reason why this release is “smaller” than 2.4 in terms of new features is because 2.4 actually caused a crunch for the GNOME 2.6 release (gnome releases are on a strict 6 month schedule, GTK+ is not, and GTK+ 2.4 caused GNOME 2.6 to miss it’s release date). The features which appear in 2.6 are intended to help towards deprecating libgnomeui (GtkFileChooserButton, GtkIconView, GtkAboutDialog), and fullfil common application-developers’ requests (ellipsizing, GdkPixbuf rotation, all the combo/treeview improvements, and –command-line-parsing). Finally, windows users get GTK+ apps which look like windows apps, thanks to the inclusion of the WIMP engine inside GTK+.
Now, for those that don’t quite understand what all the GTK+ 2.8 plan means: a vector-drawn (and thus exportable-to-PS/PDF) (cairo), OpenGL accelerated (glitz) graphical interface — IOW, a graphics subsystem equal in capabilities to the kickass one in MacOS X (with the network transparency of X11). Rotated text and labels. I’m personally working (right now) on an icon chooser widget which will let users pick icons (for things like launchers) from the icon theme standard using a nice, filter-able UI, and have written support for fd.o-standard thumbnailing of GdkPixbuf-supported types to go into GdkPixbuf — so any GTK+ application can easily use the ~/.thumbnails dir, not just those which use libgnomeui. Now, the subsystem stuff will be (ideally) user-transparent — they will hopefully only notice that GTK+ seems much quicker thanks to their hardware-accelerated OpenGL card. The new widgets will mostly be replacements for existing widgets in libgnomeui.
Some other widget-related features that I can think would be cool for 2.8 (that aren’t on the plan) would be: collapsing support in GtkPaned (possibly via a “toggled” signal and “active”/”can-toggle” properties, and implemented in Gtk{H,V}Paned), more advanced ellipsizing (bug at http://bugzilla.gnome.org/show_bug.cgi?id=147608 ), a dock widget (there’s work in sitting in libegg, as well as GimpDock), an application window (GnomeApp using GtkUIManager and a dock widget), and whatever other “it would be nice if GTK+ did XYZ” things that application developers can come up with. (This is why GTK+ is “user-centric” — its users are app developers.)
But, without people actually coding this stuff, debugging it, and putting in the work to make it work, it’s all idle talk. If you want a particular feature, hack it yourself and present a well-formed patch (or at least a URI) to the GTK+ team. File a bug to make sure your request/patch don’t get missed in the deluge. Don’t just complain about it, fix it! You’ve got everything you need a few keystrokes away 🙂
> QT is charging $1000 per year per machine.
So much wrong: First, it’s written Qt. Second the toolkit doesn’t charge but its creator Trolltech. Then it’s not “per machine” but “per developer”. The “per year” is for support and one year of free upgrades (both minor and major releases). Nothing prevents you to continue to use the bought (or last upgrade version) beyond this year. The price for optional one additional year support and maintenance starting with second year is much lower (about a third).
You can Report Abuse but it’s true!
I’ve tried to do a GTK app using Python (PyGTK), and that sould be lot more easy but…
I couldn’t get any docs, even for simple things, PyGTK has literally 2 years old docs, while it’s not GTK itself PyGTK is “official” bindings…
Glade does suck, compare it to Qt Designer
I’ve managed to put menu help tips in a Status Bar with a lot of hacking, but then again not even PyGTK devs wore able to tell me a better way to do it or even another way at all, 2 weeks later when installed GTK 2.4 it broke and then again no one knew why.
And other dumb thing I’ve depared with, like the Evil GtkTreeView or those wierd APIs of Open/Save dialogs
So I will not using GTK anymore, but I’m also not coding nothing now so…
I personally don’t see this happening anytime soon now. Take Blender3d for example, a fully OpenGL based program, including controls, etc. Start it with “blender -w” Try to resize it, or drag a window over it. Doesn’t look much like an improvement, now does it?
I have *very* little faith in that GTK+ will improve speed-wise. It’s developers will simply wait for CPUs to become so fast, that GTK+ won’t be perceived as being slow. Ofcourse, your laptop batteries won’t last half as long as on another system, but who cares about that anyway right?
Now a little rant about Mozilla Firefox. Firefox/win32 resizes and scrolls a *LOT* faster than Firefox/GTK. To most, this wouldn’t be such a problem. But I’m a laptop user, sorry about that. I find it quite distrurbing that whenever I scroll, my CPU fan activates. For crying out loud, I was just scrolling!
But take X-Chat/win32, which is based on GTK+. Resizing is *SLOW*. Even resizing the userlist is *SLOW* as is on Linux. Don’t tell me GTK+ isn’t the cause. It *is* if both Win32 and Linux suffer from a slow GTK+. For those that don’t know, Windows doesn’t use X. So don’t blame it on X.
You probably went to wrong website. PyGTK official website says that the newest documentation was updated in 11 Oct 04.
In another word….YOU SUCK, timerever! Unless you stop make baseless accusations, you are one of the worst flamer of the universe.
Interesting that the docs for the PyGTK bindings are updated almost one month in the future… Maybe you should check your facts before insulting other people?
Version 2.4.10 Last updated 2004-08-11
http://www.pygtk.org/reference.html
Version 2.2 Last updated 2004-08-03
http://www.pygtk.org/tutorial.html
Doesn’t seem to be outdated to me, though that of course doesn’t mean they weren’t outdated at the time the poster who complained used them.
And one question to those complaining about the lack or slow pace of gtk development?
Why don’t you consider a switch to cairo -> glitz a major development or didn’t I understand you correctly?
It was just a mistyping. Very bad of me. However that doesn’t mean that I was lying. The document was nearly up to date, contradictory to the guy who attacked that the pygtk docs are two years old.
Oh, and the gtk+ apps are slow, is all bullocks!
It isn’t. GTK+ 2.x is really very slow. It’s not only the resizing and redrawing that so many people constantly whine about and GTK+ developers and fanatics constantly ignore. It’s slow in many other aspects. Many things in GTK 2.x eat more CPU cycles than in Qt for instance. Like showing menus (with right-click), expanding/collapsing stuff, etc. Or multitab dialogs – when you switch between the tabs, you can see the contents being gradually drawn on the screen. Text editing, the TreeView… And so on.
It’s also not an X problem – like someone else already said, GTK+ is equally slow on MS Windows, where the difference between the native Windows GUI and GTK+ is even more noticeable (because the Windows GUI is damn fast). GTK+ 2.x is simply an inefficient CPU eater.
It’s also sad when I see GTK 1.2 apps being ported to 2.x. They become so much slower. For example, I tried the GTK 2.x version of gtk-gnutella. This app permanently updates many thing quickly in its GUI in multiple tabs, tree widgets etc. The 1.x version eats 0% CPU on my PC, with occasional jumps to 1-2%. The GTK+ 2.x version needs 20-50% CPU for the same thing. And it’s the same app with the same UI, just ported to 2.x. This is really depressing, but typical for GTK+ 2.x.
I agree with Rayiner Hashem that Qt/KDE can be almost (but not quite, still much slower in some things) as fast as the WinXP GUI except for one thing – KWin. It’s by far the slowest window manager I’ve seen and unfortunately it hurts the overall percieved speed of the GUI very much.
Instead of spending so much time complaining about gtk 2.x’s speed… start up a major gtk app with a profiler and find out what is taking so long. There has got to be someone out there who has the free time to at least find out what the trouble parts are.
Why don’t they include libegg-equivalent for X anw Win32 into GTK core?
I don’t feel like doing this XRender thing again. Go run renderbench on an NVIDIA-accelerated XRender implementation. For unscaled alpha transparent blits, it’s twice as fast as imlib2 (and tens of times faster than software-acccelerated Render). So Render being slow isn’t a good excuse, unless Pango is doing something that causes it to hit the unaccelerated path in the driver.
At least one performance problem is/was that Pango doesn’t optimize for the common case of ASCII text, rather it does a lot of avoidable calculations for all text regardless of its complexity.
The given justification for this was that otherwise the complex rendering paths wouldn’t be used much and so wouldn’t be optimized, so non-English users would get slower speeds.
I think Owen has since been argued around from this POV, but am not sure. I’m also not sure it’d make a noticable difference, but a faster Pango is a generally good thing …
I hope RMS, Linus, Alan Cox remember their first computer experience and drop everything (512 CPU scheduler, 10 different fs, whatewer) and fix “Linux Graphics” – not xorg, XFree, cairo, GTK, pango, freetype, wm, – GRAPHICS, it is just good old CPU, L1-L2 cache lines, 2D arrays, not rocket science plus maybe modern OpenGL – like tricks. Throw away that network transparency bloat, X will never fixed, I wait it from 1999 when be shocked by terminal slowness. Terminal, simple kiddish 2d program that deadly fast on other OS from ~1994 in both pure text and graphics modes, I start think about conspiracy theory against OpenSource that Dark side pay to key FSF developers
.
4 years ago i try to port my SoftImage 3D / mental ray clone to Linux (sounds scary but do not hold your breath, program can only draw simple NURBS balls-on-checkerboard), and gave up for reasons : 50% – gcc slowness( my fun was mostly to get every bit from my Cel333 ) and 50% – gui. Pleeeeasseeeeee! Fix linux graphics (and gcc
) and LOT of developers follow the Linux.
People still have to dispel this myth over and over again, forever… It’s not X that’s the problem, if you don’t believe it, read the benchmarks and hundreds of discussions, including this one. GTK+ is slow because GTK+ is slow. Again, if you don’t believe it, run a GTK+ app under Windows.
I doubt that no one has tried to fix the speed of GTK+. Maybe the problem is the same as it is with Pango. Its developers DO NOT WANT SPEED HACKS! All they care about is how clean their code is, and on how many platforms it runs with the same codebase. The guys in #GIMP have told me too often that they don’t care if The GIMP is slow. “It’s designed to be cross platform, not to be fast.” But who the hell wants to run any GTK+2 app on Windows anyway. It’s totally alien. Optimize it for the target platform, then care about the rest.
“Finally, windows users get GTK+ apps which look like windows apps, thanks to the inclusion of the WIMP engine inside GTK+. ”
This “WIMP engine” you are talking about is just a theme that has problems with not matching font sizes correctly.
I even submitted a bug report about it and it was deleted, that means they refuse to fix it.
@Bryan
What a big suprise
All they care about is their personal ego. Like I said, any ‘fix’ that implies that their design was wrong will be rejected. One codebase to rule them all. No matter if it doesn’t fit in everywhere.
I’m sure that fixing the font thing will require some #ifdef’s, which will make it look like a workaround to their bugs.
I am sort of an CG exprt. No kidding, 7 years ago I start my own project to clone (even dissassemble) MS software OpenGL, Softimage|3D + mental ray. Reason – Evil west contries have powerful cinema FX tools and Russia can only look and cry looking hi-end Hollywood video Ivan’s solgers (me, my father, etc) eating kids and porno dancing on the tables(dont remember exact movie titles – one about D-Day?). I been yang and brave. And stupid, 3D is not politics. But I learn fast, ~1 year spend i have real working software only OpenGL dll that replace opengl32.dll and can run SI|3D, doom2 with stunning multitextures not so slow compared to MS. Try yourself, can you achieve just correct image, don’t speak about speed. Brain-damage 4D homohenous culling, diamond-shape line rasterising, cool and fast gamma – correct dithering, maybe fastest in universe AA points with any size, all that and more required a lot of work. And I am speed fan, first version be pure assembler code. Then HD crash, and I resurrect all in C. BTW – M$ compiler optimizer really cool staff( VC6.0). Later I finish number of OpenGL demos and NURBS editor, and do huge amount of benchmarks. nearly 2 years i every free minute start editor, do simple scene, render, profile, see assembler output, change code, again and again. Of course, I am not good coder/programmer, but i have a lot work with optimizing complex graphics software. And I repeat again – something BIG wrong with ALL graphics in Linux. Not in X. In ALL that draw something on screen. CPU waste all time to call another call and convert data to portable internal format(network transparency bloat), No portable vertical blank interrupt test, always hack over hack, result- no cool smooth 2D games. Many time I try to look at X source – and finish it with strange blood ticks in my head
. If hardcore X guys do not want to touch sacred cow – network X protocol may be fork it and do different binary with shortcuts that utilise gcc unit-at-a-time and autoinlining ? But as i sad, I gave up. Sorry for long ugly spelling.
The benchmarks say that X has similar throughput to the GDI. Unless you programmed X incorrectly, you should be getting similar performance. Maybe you can describe how your app used X, in detail, so we can see where the problem is?
It should be noted that ILM uses Softimage XSI on Linux with NVIDIA hardware. XSI itself runs just as well on Linux as on Windows. If they can do it, the problem isn’t X itself.
The resize problem you mention occurs because, currently, there is little integration between OpenGL and X. OpenGL windows are “special” windows in X, just like Xv windows. The problems should theoretically go away when they change X to run on top of OpenGL.
That’s really cool. For modern machines. Modern machines with graphics cards that have proper OpenGL drivers. Hmm, that means it shouldn’t be too modern, unless….
NVidia will only work with binary drivers (seperate download). Same for ATI, although the opensource drivers support OpenGL on anything <= Radeon 9200.
Currently the state of OpenGL on Linux leaves much to be desired. It’s not all bad, but it’s not great either. So by moving onto a fully OpenGL accelerated desktop, you’re limiting yourself to closed source drivers. Is Xorg willing to do that? Or shall we all render OpenGL in software, with the amazing MesaGL library. Hah.
Remember, on desktop machines OpenGL support is a matter of plugging in a supported graphics card. This will not be so easy on Laptops. And who really wants to support both OpenGL and Software modes seperately. I dare to bet that Software mode will be an afterthough. It’s gonna be dead slow.
If your computer doesn’t support OpenGL, it won’t use a software GL, but fall-back to XRender or core rendering.
In the last paragraph I meant a seperate software mode, for example XRender. It will be an afterthough however. Don’t expect it to become fast.