> 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