On Wednesday 29 August 2012 17:13:27 Timothy Pearson wrote:
I don't understand this obsession for Qt4+ and KDE4. KDE4 is every
time a
step behind GNOME. For this reason I preffer to patch a little the Qt3 to support glib mainloop and then I will develop various applications based on excellent libraries provided by GNOME community. Moreover, glib integration is
not
broke Qt3 API, so I don't need to patch any of older KDE3 apps.
This is a matter of opinion. ;-) I used to program GTK applications, and in my opinion they are very hard to code and maintain past a certain size and complexity level.
I say about glib libraries, not about gtk ones. For example, kopete can be a simple shell for libpurple, knetworkmanager can be a shell around libnm-glib, the same thing I did for kpolkit-agent and so on. Even KDE4's polkit-qt-1 is a simple bridge between Qt4 and libpolkit-1.
So you are suggesting that we use glib backend (non-GUI) libraries to power TDE native frontends. This is an interesting idea that merits some additional research.
Moreover, KDE4 libraries tend to be very tight linked to KDE4 core libraries, while the GNOME libraries often depends only to glib (which is used anyway by KDE3/TDE, for example in aRts and other modules).
Of course, this is why I have not used any Qt4/KDE4 libraries in the TDE core, however it would be nice to be able to provide a plugin or two that leverage portions of KDE4 that are more powerful than the TDE equivalent (KHTML/Webkit for instance).
Qt3/4/5 applications on the other hand seem more scalable, and those libraries provide many useful features in their respective APIs which were lacking when I last tried the GTK libraries.
Minor hack or no, it is ugly. Replacing strings automatically
introduces
a risk to make unwanted changes (which sometimes are translated in strange and hard to hunt bugs).
At this point most, of not all, of those bugs have been found and stamped out. There is no real reason not to use TQt3, with its better compatibility and continued development, except for personal preference.
Well, I think that original Qt3's API is powerful enough, it needs just some underground tweaks (like glib eventloop support).
OK, here is a single example of how TQt3 is more powerful than Qt3 in the context of cross-toolkit drawing operations:
If I want to draw a widget element on an X11 pixmap in Qt3, I have to create a full widget object, configure it, "show" it, then bitblt its contents to the desired pixmap. With TQt3 I can simply command the style subsystem to paint the desired element(s) directly to the desired pixmap.
As an aside, the aforementioned Qt3 sequence of painting events is the root cause of most of the GTK style engine performance and stability problems that KDE and TDE users have experienced over time. Sometimes API changes actually introduce new functionality; you should take a look at the latest Qt3/TQt3 versions in our GIT tree before saying Qt3.3.8 is sufficient for everything. ;-)
Tim