> On Wednesday 17 August 2011 07:53:17 Timothy Pearson wrote:
>
>> Second: I was merely thinking out loud.  With trolls on this list
>> apparently that is a bad idea; I will save my ideas for the meeting,
>> where
>> things have been more civil.
>>
>> Third: I do not need to break the existing KDE3.5.10 plugin, but over
>> time
>> it WILL break itself.  Good luck keeping it running when Qt3.3.8b won't
>> even build anymore.
>
> Instead of accusing me of trolling here you better should recalll that we
> use your
> patched version of Qt3. They are API-wise backward compatible and there is
> actually no need for rewriting anything that depends on purely Qt3.

API, yes.  ABI, no.

Qt3 has several flaws in it that have, over time, spawned nasty hacks in
the original KDE3 (now Trinity) source.  These hacks are a constant source
of consternation for our development team; they cause things to randomly
crash or fail in a nonreproducible manner.  One of our goals is to add new
methods to Qt3 in order to clean up the hacks in the Trinity source,
thereby stabilizing the system.

One of the bugs causes a crash sporadically when the filter bar is used in
icon mode.  The cause is a missing visibility set feature in QIconView. 
The only resolution is to fix Qt3.  There are other examples, but I hope
you get my drift.

Regarding trolling, you did make a very strong accusation and threat to me
earlier (regarding LibreOffice and contacting the dev team), and very
strongly asserted that you want to keep KDE3.5.10, which is long dead,
available.  Be careful what you say if you don't want to be judged.

By the way, if you continue to use the Qt C++ namespace you will run into
problems eventually.  Technically you are stepping on the toes of Qt4 and
any applications built with Qt4, which is not a good thing to do.  This
namespace collision is at the heart of why Qt4 cannot render Qt3 widget
styles and themes, as well as why Qt4 features cannot be utilized in
Trinity.  I refuse to halt progress in moving to the TQt namespace, which
would open the door to a number of features including a good KHTML
replacement, just to retain perfect compatibility with the long-obsolete
KDE3.5.10 release.

I hope this clarifies some things.

Tim