>> I'm curious if tqt have any future, we really want to run
>> trinity over Qt > 3?
>> From a developer perspective tqt layer is pretty sux, every
>> time I need to
>> remember to use T prefix, namespace is polluted with
>> hundreds of useless
>> macros, a lot strings have been damaged by automated
>> migration tools, .ui
>> files cannot be opened directly by designer, etc etc. Also,
>> I'm pretty sure
>> that many bugs have been introduced in process (I remember
>> that few times I
>> waste hours to debug strange behaviour because tqt). Even
>> now I notice
>> in .xsession-errors errors like "WARNING:
>> DCOPReply<>: cast to 'TQCString'
>> error".
>>
>> We need to handle all these problems, with no real benefit
>> (ar least from my
>> perspective).
>
> I'm not qualified to discuss the programming nuances of using the TQt
> layer. Recently Tim wrote the following:
>
> TDE will (as of a couple days ago) build completely against tqt3,
> theoretically resolving any remaining Qt3<-->Qt4 conflicts and allowing
> the usage of Qt4 directly in new (or manually ported) TDE code. Since I
> can hear people's confusion now, this ONLY ALLOWS NEWLY-WRITTEN QT4-BASED
> CODE to be compiled and linked into TDE applications--it does NOT
> magically make TDE compile on Qt4, nor will it ever. :-)
>
> My feeble understanding then is TQt provides a mechanism for QT4 apps to
> run in TDE and provide a more native look-and-feel within TDE. Sounds good
> to me.
>
> Other than occasional inadvertent conversions to TQt syntax, I have
> noticed no problems building packages. I am not noticing any usability
> issues derived from TQt. I notice that TDE 3.5.13 is faster and more
> responsive than KDE 3.5.10.
>
> After all the work involved to create the TQt layer, do we now want to
> strip that layer? Is that effort worth any alleged or perceived gains?
> What does removing that layer provide us long-term? What does keeping that
> layer provide us long-term?
>
> Even if Tim agrees that removing the TQt layer is a reasonable long-term
> plan, there are about 200-300 paper cut bugs that need desperate
> attention. Desperate attention.
>
> A paper cut bug is a bug "which in and of itself is insignificant and may
> also be trivial to fix, but when combined with other like bugs create the
> overall impression of an unfinished, buggy piece of software."
>
> Stripping the TQt layer will delay any efforts at quashing those bugs and
> highly likely, introduce about twice as many more such bugs.
>
> The great gripes of any desktop environment is not the enhancement
> requests but the bugs. TDE is no exception.
>
> I am not using TDE full time because of these paper cut issues. There is a
> reason these kinds of bugs are called paper cut bugs --- relating to the
> old adage of "death by a thousand paper cuts." A few such bugs are
> annoying but tolerable. Too many and the desktop is interfering with
> enjoying any usage.
>
> Although the discussion about the viability of TQt might be important, I
> hope the moment GIT is open publicly that all we see in this list for the
> next four months are discussions about building packages, testing
> packages, bug quashing patches, etc.
>
> I want to see R14 rock solid and users and reviewers agreeing. I want to
> be able to migrate full time to TDE.
>
> That so many paper cut bugs are being reported is a good sign many people
> are actually using TDE. TDE will prove more popular by quashing these
> paper cut issues. Popularity will encourage more developers and packagers
> to join the community.
>
> These bugs were supposed to have received attention for the 3.5.13 release
> but that never happened. Users have suffered too long. :) If stripping TQt
> becomes a project goal then do that after R14, not now.
>
> I'll leave the debate about TQt to you programming experts, but my vote
> and voice is with the paper cut bugs.
>
> Darrell

+1.

And TQt stays right where it is. :-)  That conversion is done and the few
remaining problems with it should be resolved in R14.0 with tqt3 as
mentioned.

Tim