29 Aug
2012
29 Aug
'12
3:09 p.m.
On Wednesday 29 August 2012 17:13:27 Timothy Pearson
wrote:
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.
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. 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.
Well, I think that original Qt3's API is powerful enough, it needs just
some
underground tweaks (like glib eventloop support). 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.