>> 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