On Wed, Sep 18, 2013 at 9:10 PM, Timothy Pearson
<kb9vqf@...> wrote:
>> 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.

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?

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

Hmm, interesting news. Ok, that's a good reason to stay with Qt3. I
don't like how Qt4 performs either.

>
> Tim
>