> 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