Wireshark Is Being Ported From GTK+ To Qt

[smani]

From the article:
Gtk is a third-class citizen on Windows. Gtk3 hasn't even been ported, the latest "stable" Window$ port is an old version of Gtk2 - not the latest Gtk2 version, but an old version of Gtk2.

This is not exactly true. There are no official win32 binaries to download (mainly because no-one stepped up to do so, though I remember it being discussed on the mailing list not too long ago), but the source does compile for win32, and for instance Fedora even has mingw-gtk3 binaries. Same goes for the latest gtk2.

[kosenko]

Thanks, but no. springlobby client which uses WxWidgets is terribly slow and ugly.

wxWidgets isn't slow. Any end user more slower than any GUI toolkit. Application could be slow if algorithms inside is slow.
wxWidgets uses native widgets, just don't use ugly themes in your OS and you'll be happy.

[Alejandro Nova]

I saw something some time ago, reading through the history of Krita, about an incomplete KDE port for GIMP called "kimp". It caused nothing but a flamefest, but became the foundation for Krita.

This time is the turning point to do something like that. Less and less apps are going to use GTK 3 and more apps will use Qt 5. And remember: with Qt 5.2, there are no KDELibs anymore; Qt 5.2 marks the point where Qt and KDE Frameworks 5 become one.

[Delgarde]

I see. I never looked there because it never occurred to me that "Hello World" would be under "API Documentation", which on every other language or toolkit website I have been to has the documentation for the API, not "Hello World" examples. Usually such things are under "Examples" or "Tutorials".

What's your point? You claimed there were no official tutorials for Gtk3, now you're finding endless more complaints after people pointed out that it took half a second to find them on Google, the first hit under the most obvious of keywords "gtk3 tutorials"...

[TheBlackCat]

What's your point? You claimed there were no official tutorials for Gtk3, now you're finding endless more complaints after people pointed out that it took half a second to find them on Google, the first hit under the most obvious of keywords "gtk3 tutorials"...

I was responding to someone else who claimed that there were no tutorials on the Qt website, despite the fact that they were there and extremely easy to find. The person then went on to contrast that with the gtk tutorials, despite the fact that the gtk tutorials are on a different website, and on the gtk website are not labeled as tutorials at all. Yeah, sure, if you use google you can find tutorials for both gtk and Qt, but that wasn't what the person I was responding to did. If you think that google is the way to go, then tell that to the person I was responding to, not me.

[Guest]

For me the question is simple: Want portability? Try Qt. Want your program best for Linux? Use Gtk.

Care to explain the second part? The best Linux programs I know I made with Qt.

[curaga]

This time is the turning point to do something like that. Less and less apps are going to use GTK 3 and more apps will use Qt 5. And remember: with Qt 5.2, there are no KDELibs anymore; Qt 5.2 marks the point where Qt and KDE Frameworks 5 become one.

Depends on your POV if that is a good thing (adding even more bloat to Qt).

[boudewijnrempt]

Depends on your POV if that is a good thing (adding even more bloat to Qt).

KDE Frameworks 5 does not "add even more bloat to Qt" -- it provides developers with a set of libraries that they can use in their Qt-based applications, if they need the functionality. And that follows the lead of Qt itself, which is significantly more modularized than Qt4 was.

[TheBlackCat]

Depends on your POV if that is a good thing (adding even more bloat to Qt).

It is more complicated than that. First, one of the big changes in both Qt 5 and KDE Frameworks 5 is that the libraries have been modularized. Rather than pulling in "libqt" or "libkde", you pull in only the bits your program actually uses. A text editor won't need to pull in multimedia components, for example. So that will result in a significant drop in bloat for most applications.

Further, for the most part KDE classes are still KDE classes, they have only added a few new classes directly to Qt (and that has been commonly-used, low-level stuff). Instead, they have been eliminating redundancy, looking for cases where KDE classes have the same or similar functionality as Qt classes and eliminating those, in some cases adding a few more capabilities to the Qt classes where needed. KDE classes are only being kept when they add significantly more features than their Qt counterparts or there are no Qt counterparts at all. So again, that results in a reduction in bloat, since there is less duplication and redundancy.

[pingufunkybeat]

KDE Frameworks 5 does not "add even more bloat to Qt" -- it provides developers with a set of libraries that they can use in their Qt-based applications, if they need the functionality. And that follows the lead of Qt itself, which is significantly more modularized than Qt4 was.

Boudewijn, I was under the impression that KF5 would be a set of Qt plugins, a sort of an extension to Qt, rather than become integrated into Qt directly.

Is this right?

It would be a bit odd to complain about the bloat of that, and then insist that you must use glib, for example.