Another GTK+ 3.0 Pre-Release Arrives

[pingufunkybeat]

I'm sorry about my post, and I can't edit it. It was trolled, and this thread shouldn't dissolve into a silly flamewar.

I think that GTK is a good toolkit, and will always be an important part of the GNU/Linux/*nix ecosystem.

It's just depressing to see that the "Kill KDE ayatollahs" from the dark ages of desktop wars are still alive. Qt is a fantastic toolkit used by some of the best Linux software: VLC, Amarok, SMPlayer, even Skype.

The most important Linux apps which made it viable for a desktop are neither Qt nor GTK anyway: OpenOffice and Firefox. Same goes for Thunderbird and other Mozilla stuff. The most important editors are neither: Emacs and vim (despite vim's optional menubar which is not needed).

[whizse]

Not that it in any way disproves your post, but Emacs does use GTK+.

[pingufunkybeat]

I might be stuck in the past... Does XEmacs use it too?

[whizse]

I'm not really sure, some sort of GTK+ support seems to exist for XEmacs, but I don't think it's used by default?

[mirv]

I personally like using fox, although naturally that, like qt, is for C++. One thing that gtk has is working entirely with C. Just wanted to point that out.

[mat69]

The point was made for a total re write of GTK+ toolkit... If it would get this the new version would be_incompatible_with_all_the_software anyway. Apps would have to be ported...

Since it is like that why not port to Qt4 a toolkit that is there and is way modern/has more features then GTK+ ?

Ugliness on the other hand is a thing of preference and any toolkit can look right with a good theme...

This is all about technology beneath the hood ... and Linux would certainly benefit if it had one toolkit instead of two incompatible ones...

Sorry but that is a myth. None said there would be a _total_ rewrite. Yeah binary compatibility and API will be broken at _some_ areas yet not at all. That would make no sense.
The idea of such changes is to remove old cruft, add new stuff where it was not possible before. As well to rearange stuff if it turned out to be far from ideal.

Same was true for KDE 4.0.

Yeah I'd like it if Gnome was written in Qt, yet that is just an illusion that won't come true. It would just take too much work for gains that would not justify that. Plain simple: Gnome works pretty well with GTK+ already so rather improve GTK+ than to start over.

[Arch]

GTK needs to improve dramatically to catch up to the innovations of the toolkits in Windows and OSX.

This is highlighted with the simple "Hello World" test where you count the number of lines of code to create a simple Hello World. In GTK it is more than 10 lines or so and in other toolkits it is usually under 4 - 5 lines of code.

I have to agree here. This is the reason I use typewriters whenever possible. They produce a "Hello World" in just one line of code and are thus far superior to all that new-fashioned compjooter stuff.

[drag]

I personally like using fox, although naturally that, like qt, is for C++. One thing that gtk has is working entirely with C. Just wanted to point that out.

What?

GTK supports lots of languages. I have programmed a couple different GTK python apps for different things.

If your going to go on about OO and C vs C++... 1989 called and wants their pointless language debates back.

[Delgarde]

The point was made for a total re write of GTK+ toolkit... If it would get this the new version would be_incompatible_with_all_the_software anyway. Apps would have to be ported...

Since it is like that why not port to Qt4 a toolkit that is there and is way modern/has more features then GTK+ ?

Apps *don't* need to be ported to Gtk+ 3.x, as long as they're already coded to "best practices" for Gtk+ 2.x - i.e not using any of the deprecated API that's being removed, not accessing 'private' data directly, etc. As far as I can tell, well-written code should be compilable against either version.

[drag]

Sorry but that is a myth. None said there would be a _total_ rewrite. Yeah binary compatibility and API will be broken at _some_ areas yet not at all. That would make no sense.
The idea of such changes is to remove old cruft, add new stuff where it was not possible before. As well to rearange stuff if it turned out to be far from ideal.

Same was true for KDE 4.0.

Yeah I'd like it if Gnome was written in Qt, yet that is just an illusion that won't come true. It would just take too much work for gains that would not justify that. Plain simple: Gnome works pretty well with GTK+ already so rather improve GTK+ than to start over.

GTK 3.x breaks ABI/API; slightly. It got rid of a bunch of old crusty features that turned out to not be popular and is introduced new frameworks to replace them. (Ie. Dbus for Corba)

But distributions can still maintain compatibility with older applications as long as they want without to much effort.


And, btw, the KDE 3.5.x transition to KDE 4.0 is the posterboy for what not to do. It's one of the best things that ever happened to Gnome, in terms of aiding in it's popularity.