19 Sep
2013
19 Sep
'13
8:35 a.m.
On Wed, Sep 18, 2013 at 9:10 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
Then fix it *where they exist*. Fine, good decision. You fixed it in
R14 and I say of everything that I saw up until R13. You changed API
not because of stability fix. You made a decision to support and port
every Qt3 program. That's what I'm talking about. You made a proxy lib
TQt and script-written bulk code processing with some useless renames
that have taken 2 years of time and no real progress.
I've upgraded to R13 and it even not started! I spent a hour to track
down the problem. What is expected from you as from distributor is to
make correct packages, test and simplify upgrade process, etc. And you
are doing the opposite -- make some handicaps of upgrade process. The
packages was renamed.
The first priority and most simple task is to make correct
dependencies. And even this was not done well. Why is that? Isn't it
because you are busy with something completely different?
Hmm, interesting news. Ok, that's a good reason to stay with Qt3. I
don't like how Qt4 performs either.
You can fix
thread-safety as it is usually fixed: put mutexes, rw
locks, etc. in right places of program and use thread-local variables.
You don't need to get into the deeps of Qt. And for sure, you don't
need to change API for that.
And from where I sit such work, multiplied across all of the multithreaded
programs in TDE, would be a *massive* waste of effort that would primarily
help to make TDE unmaintainable by all except the most elite hackers.
Fixing the problems *where they exist* makes it easier to use threading in
a stable, tested manner. I don't
want Qt4. I'm Ok with everything except the UI. I said, that
if you want more sophisticated lib, then do it with Qt4, not modify
Qt3. If you say that Qt4 is missing something, I'm sure that there is
some solution with additional libs. I not quite understand, why moving
some functionality from Qt3 to KDE4 has slowed it down. Is it because
programmers at KDE worse, than at Trolltech? Again, there should
already be ready lib that does it good.
No, the programmers were/are not worse, but the project goals apparently
changed. Simply compare the size of the Qt3 vs Qt4 library for an example
of this! Qt4 decided that they wanted to be a compositor instead of
passing compositing off to the native display server, and most of the
performance problems and drawing limitations stem from this decision.
Tim