> On Mon, Sep 16, 2013 at 10:14 PM, Timothy Pearson > <kb9vqf@...> wrote: >>> On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson >>> <kb9vqf@...> wrote: >>>>> 2013/9/13 Aleksey Midenkov <midenok@...> >> <snip> >>> There is no need in that. UI programs are not high-load programs, they >>> don't >>> require bleeding edge performance optimization. Everything worked fine >>> there >>> before Trinity! You've digging wrong places. Do UI, not system libs. >> >> So in other words, our users are supposed to just put up with frequent >> unresolvable crashes that were traced back to fundamental flaws in >> Qt3/TQt3, while we change the stable UI that our users expect us NOT to >> significantly change? This is not 1999 anymore, users own systems with >> multiple cores as a rule now, and some of the original KDE 3 code simply >> was not thread safe! Sure, it worked most of the time on hyperthreaded >> processors, but not on real multicore systems, just search our >> bugtracker >> for threading related bugs for a sampling of the problems *fixed* by >> changing the TQt3 library. > > 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. > In fact, I suspect that you will only add instability, not fix it. I > already had crashes on 13 (they were not too often before) and I've > read from people that noticed the same after they installed this > version. Interesting, given that 3.5.13.x does NOT include ANY of the fixes we are discussing, and therefore clearly demonstrates the problems that existed *before* my fixes went in. Give R14 a try to see the difference. >> >> As I have mentioned before, if you would like to see TDE on Qt4, why >> don't >> you figure out a way to port the entire codebase over, or at least start >> porting components yourself? You will find that it is not an easy task! >> Qt4 does not offer critical components that Qt3 did, and hacking around >> the missing features *will* slow TDE down on many systems, just as KDE4 >> slowed down. (Yes, I have tried!). > > 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