11 Dec
2011
11 Dec
'11
12:36 a.m.
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