10 Dec
2011
10 Dec
'11
8:40 a.m.
Hello,
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).
--
Serghei
10 Dec
10 Dec
9:36 a.m.
New subject: [trinity-devel] tqt future
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
11:31 a.m.
New subject: [trinity-devel] tqt future
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
11:46 a.m.
New subject: [trinity-devel] tqt future
On Saturday 10 December 2011 21:31:40 Timothy Pearson wrote:
[...]
+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.
Conversion is done, but how a programmer should develop a new application? A
converted .ui cannot be opened in designer. Also, there exists some methods
prefixed by tq*, I have no idea when to use it (actually I won't).
Tim
--
Serghei
11:59 a.m.
New subject: [trinity-devel] tqt future
On Saturday 10 December 2011 21:31:40 Timothy Pearson
wrote:
[...]
Those methods should actually be migrated back to non-tq prefixed methods.
They are a leftover from a very early stage of conversion.
As R14.0 will use tqt3 the designer issue will resolve itself. That being
said, I personally find that I obtain better results without designer, but
YMMV.
Tim
+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.
Conversion is done, but how a programmer should develop a new application?
A
converted .ui cannot be opened in designer. Also, there exists some
methods
prefixed by tq*, I have no idea when to use it (actually I won't).
4543
days inactive
4543
days old
4 comments
3 participants
participants (3)
-
Darrell Anderson -
Serghei Amelian -
Timothy Pearson