Sure, all you mentioned about KDE4 are indeed drawbacks that hold me from using it. What I expect to be done for KDE4 is some 'Classic mode' (like for Windows), that will rip those horrible kid visuals and needless daemons. Also merge of window manager features from 3 to 4 is a must to decide KDE4 more or less serious shell. Sorry, I don't want to repeat in details why TDE is wrong. You can find it in bugs (open and closed) and here on the list by searching for my name. Figuratively speaking, they try to move a mountain to build a straight way through when it is satisfactory to build a road over that mountain. They will never have enough resources to move the mountain, the project will always be half-finished and half-working. In fact, all this tremendous work is needless. And moreover, it is even worse than this simple image. Moving a mountain is finite job and what they do is doom of endless support. They will never have time for real features and bug-fixes. Moreover, I'm afraid that they will only make more bugs. Unfortunately, both of these projects KDE4 and TDE hadn't followed real users expectations.

Since TDE now uses TQt3, the old Qt3 libraries (unmaintained as they are!) can be installed at the same time as TDE. At this point I don't see any serious drawbacks to changing the TQt API; would anyone consider it a major problem if Trolltech had changed the Qt3 API? We all probably would have complained about it a bit and then moved on--how is this different from the TDE project *improving* Qt3/TQt3 (e.g. adding proper threading support) and changing the API as needed? Tim

2013/9/14 Timothy Pearson <kb9vqf(a)pearsoncomputing.net> For now — yes, it's ok to do with TQt api anything we want to, but when it was introduced for the first time IMO it was a huge issue, that called a lot of concerns about further destiny of the TDE. AFAIK Trolltech hadn't changed the Qt3 API. It was backward-compatible through all it's lifetime... They had to release the Qt4 to change it. That's why we are here now. Fix me if I'm wrong. 2013/9/14 François Andriot <francois.andriot(a)free.fr> environment variable. If we started to talk about it, Tim, can we do something about that? Btw: what are your plans about tqt/tqtinteface? We are about to remove the second one because it doesn't needed anymore, isn't it?

On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson <kb9vqf(a)pearsoncomputing.net> wrote: And not only about that. There were more things that have taken years of time and was needless to end user and a handicap to programmers. You are not Trolltech. You have no such human resources neither by count, nor by experience. Moreover, there is no reason to dig in depreciated code. Want better lib? Gradually switch to Qt4, one program after another. If you weren't doing all these stupid things with TQt, Qt3 API changes, K* -> T* renames you would already have finished. But I wouldn't recommend that either. Bug-fixes, functionality and UI. Only these are important. 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.

Speaking as a user, while I don't agree with everything that happens, this is Linux and open-source. If you don't like something, fork it. On Mon, Sep 16, 2013 at 1:14 PM, Timothy Pearson < kb9vqf(a)pearsoncomputing.net&gt; wrote: -- Bro. Michael Henry Associate Pastor Monticello Christian Church Be kinder than necessary. Everyone you meet is fighting some kind of battle. You never know when a moment and a few sincere words can have an impact on a life for a life

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

On Thu, Sep 19, 2013 at 12:35 PM, Aleksey Midenkov &lt;midenok(a)gmail.com&gt; wrote: Hmm, I've just read of a little bit opposite. On Xorg Qt4 uses XRender for composing by default. This is done on server side and this engine is very slow. If to switch Qt4 to raster engine, then performance goes to normal. Here is an article: "How to drastically boost up your KDE 4 performance by using the Qt raster rendering engine" http://tinyurl.com/644b7a5

On Thu, Sep 19, 2013 at 1:45 PM, Mag. Dr. Nikolaus Klepp &lt;office(a)klepp.biz&gt; wrote: Well, it worked at least until the April 13, 2011. Maybe things have changed since then.

Then what's the explanation for QT4 being way slower than QT3 on e.g. ('cause I have access to this hardware) X61 and GeForce GTX 470? -- Mag. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

The same old diskussion, and it will not lead to a solution. As neither KDE nor TDE or any other DE offers a test suit the user is up to his/her personal impression. Some months ago (was it last year? time flyes ...) you suggested tde to switch to kwin4 and drop kwin3.5. Well, I tried it and posted my results. It's like walking in tar. Just install TDE, change the WM to kwin4 and start working. You could do as I did, set up 2 identical maschines next to each other (I'd suggest you use Intel or Nvidia gc - X61 in my case) and make a one by one comparsion. And Nokia is still the rising star of smartphone universe ;-) Nik -- Mag. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

On Thursday 19 September 2013 12:35:17 Aleksey Midenkov wrote: It's not interesting news, it's just wrong. Qt's internal rendering doesn't depend on whether compositing is used or not. Even more a compositor would not even be able to make use of any optimizations done inside Qt for the composited case, because there is no way for the compositor to know that the app "supports" it. Compositing on X11 happens behind the scenes of the window. The window doesn't and doesn't need to know that it gets composited. Cheers Martin Maintainer of the X11 Compositor of the KDE Plasma Workspaces

On Thursday 19 September 2013 13:35:42 Timothy Pearson wrote: your assumption is wrong. XRender is slow, software rendering is faster. This is no surprise. The rendering if done on the CPU is performed in one go by one process. If done with XRender the rendering is split over two applications which results by definition in non-deterministic behavior. With XRender you need to have roundtrips to the XServer during the rendering to e.g. fetch the geometry of the pixmap you are rendering to, etc. etc. Thus the number of context switches is rather high. It gets better when using XCB, but neither Qt 3 nor Qt 4 have been using XCB, so that is a rather irrelevant point to make. Using X for rendering makes everything more difficult, like when to time the frame so that you get flicker free rendering. X itself doesn't have a concept of double buffering, so this has to be done client side. Otherwise you run into situation that X performs a scan out while you still render to the window thus you have tearing. The solution is to render to a off-screen pixmap and then swap it. Now if you already render to an off-screen pixmap why would you want to use X if you have an alternative renderer available? (Note: the link you provided shows that Qt 3 used to demand applications to carry their own double buffering code while Qt 4 is double buffered by default. This might explain the differences you notice if you compare a single buffered application to a double buffered one). As KWin has an XRender compositing backend I am rather familiar with the quirks and the problems it needs. XRender performance is extremely dependent on the implementation inside the X drivers. This is completely outside of control for Qt (or KWin) and we have seen that the performance can become very bad depending on the driver. The CPU is way more reliable in that regard and can be timed better. If it doesn't render the frame in 16 msec you reduce the complexity. This is not possible with X - one cannot determine the length of one rendered frame from the previous one. One roundtrip can completely screw your timing. Last but not least: rendering on CPU allows you to render in a thread, this is not possible with the native graphics system. If you render in a thread you can keep the application responsive even if the frame takes quite some time. So I'm sorry to say: your assumptions are wrong. I assume if you talk about Qt 4 you mean the Oxygen widget style, which is extremely heavy compared to any style used in Qt 3? Please don't mix things. The performance of Qt doesn't depend on Oxygen ;-) and that is something I doubt - are you really the one who sees that the emperor is not wearing cloths, are the hundreds of experienced Qt developers wrong, while just you found the ultimate truth? I rather think that you have an incorrect setup[1] combined with that you see what you want to see. Yeah if one wants to see Qt 4 being slower you will see that it is slower - whenever I do an optimization I'm sure that it's faster. Our eye is not good enough to notice such difference - this needs benchmarks. We try to render at 60 frames per second, thus each frame should be there after 16.6 msec - I cannot see such differences and you neither. As you probably know I have to work on an application where every frame counts and we try to do animations at 60 Hz. I know what can be seen and what not. A missing frame for example is something I do not spot. Cheers Martin [1] One of the reasons why we introduced support information inside KWin was, that users claimed it to be slow and with very few settings we were able to get it fast. In most cases it was because the users "optimized" by changing away from defaults or using something they thought is "faster".

Am Samstag, 14. September 2013 schrieb Martin Graesslin: Which does not solve the slugish performance of QT4 :-/ Nik -- Mag. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

Since the talk of TQT can someone explain how to port a KDE3/QT app to Trinity/TQT? On 9/14/13, Serghei Amelian &lt;serghei(a)thel.ro&gt; wrote: -- Bro. Michael Henry Associate Pastor Monticello Christian Church Be kinder than necessary. Everyone you meet is fighting some kind of battle. You never know when a moment and a few sincere words can have an impact on a life for a life

long time, and the obvious, see and think: * What distribution officially uses "TDE" as main desktop.? * What derived distribution, use "TDE" as main desktop.? * Where is a website that oficialize the number of users who use "TDE" (non-advanced)? The differences between TDE and KDE are of two types, surface and backgorund. In surface, the only thing user see is an obvious and inefficient appereance like Windows Real changes in background are not highlighted to ommon user (new software support etc.) TDE has no real differences, not like Razorqt, or LXDE, where you notice things like good performance and simplicity, In TDE avanced users like me, expected that well know bugs like missing quanta updates, dialup simplicity (kpp are a pain), konqueror crash on flash sites, or support on kwallet for subversion >= 1.6 or support for kwallet for git, the most wanted are dialog open/save integration with GTK and FLTK.. but , in 4 releases of TDE only windo like features was made! On 9/18/13, Aleksey Midenkov &lt;midenok(a)gmail.com&gt; wrote: -- Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com

<big snippage> Just to add my two penneth... Management Summary - TDE Chaps: Please carry on as you are. We tried KDE4 and the latest Gnome and for us (lots of users on X Terminals with a central server) they were completely unusable as they demand 3D graphics acceleration and other resource that just isn't there or works horribly over a network. The world seems to have gone mad on the 'need' for eye candy and lost sight of the fact that a desktop is not an end in its own right. For us, a mouse is mainly a device with which you indicate which xterm you want to type at :-) TDE works superbly for us and long may it continue to do so. Many thanks to all involved. -- Regards, Russell -------------------------------------------------------------------- | Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 | | Lady Lodge Systems | WWW Work: http://www.lls.com | | Peterborough, England | WWW Play: http://www.ruffle.me.uk | --------------------------------------------------------------------

On Wednesday 18 September 2013 18:48:11 Russell Brown wrote: at least for KDE Plasma this is not true - we do not demand 3D graphics acceleration in the 4.x series. I'm happy to help you setting this up correctly (the defaults are rather unsuited for Terminal servers) or to point you to people who can help you there. Feel free to contact me off-list. Nevertheless I need to point out that X11 is unfortunately although claimed otherwise completely unsuited for terminal setups. It mostly works because bandwith is enough, but in general it just sucks. There is some good material on that topic by X developers :-) Cheers Martin Gräßlin

On Thursday 19 September 2013 13:40:07 Russell Brown wrote: doesn't mean it's a good thing ;-) I'm going to explain a little bit more now as I think that can be of general interest as there are misconceptions about "Qt4 being slow". Understanding what's going on, can help here. Let's go back into the 80s of the last century when X got invented. Back then Unix didn't support shared libraries. Drawing functions on the other hand were quite complex and adding it to each process was not possible due to memory constraints. Therefore a client-server approach was used so that all the drawing functionality would be in the server and the clients would only need a considerably smaller library to use the protocol to communicate with the server. That's how X became network transparent, but it has never been the aim to be so, it's rather a side-effect of the constraints by the operating system and hardware back in those days. If one works with the protocol (and I do so each and every day, a printout is just in the moment next to my keyboard on the desk) one notices that it's not designed for network. The protocol has huge overhead, doesn't support compression, is more sync than async (very bad for network), etc. etc. What X provided for rendering were the most basic primitives for rendering what was supported in the 80s and what was invented and not patented in the 80s. Yeah quite some common algorithms used today didn't exist back then and the patents luckily expired by now. In the 90s this started to get painful and applications wanted to be better. Slowly, slowly things got replaced by new extensions (e.g. XRender extension in 2000) or moved directly into the clients (e.g. fonts). In the last decade moving to the client went even further. All modern toolkits render completely client side, that is use either CPU or OpenGL to render into a local buffer and just transfer the resulting image to X. And that's the point where the network transparency really hits its limits. What we are now doing is transferring video over X - without any compression, neither loss- less nor lossy). In such a situation VNC provides clearly the better choices. The end result of this trend is Wayland which doesn't have a server side rendering component any more. Obviously one can say now that everything used to be better in the past, but there are reasons why it's done that way. CPU or OpenGL is just faster on a local machine which is as of today the majority of systems. The exchange of the image data is extremely fast on a local system as one can use the SHM extension and just use a shared memory segment as the rendering target. So the local usage increases while the remote capabilities go down. In the discussion about Wayland one can see again and again that people complain about it, but nobody "in charge" cares about it, because X was never meant to be used that way. That was the technical background, now I go to explain a little bit more inline. Qt 4.(0-7) and Qt 3 and not really different in that regard. Since 4.8 rendering has switched completely to client side by default. If you are using Qt with network transparency: ensure that the graphics system is set to native! But, KDE4's visual style is way more complex. This includes everything: icons, widget style, window decorations and most important: animations. Especially Oxygen is very complex (even on a local system it contributes quite a lot to resource usage) and uses animations. The radial gradient on the global window is slow in X and by that completely unsuited for network transparent usage. Therefore: the flatter the style the better. A general recommendation is to use the Plastique style as widget style and Laptop style in window decoration (don't use Plastik, it uses strong gradients, too). Animations are problematic as they are dependent on the connection to the X server and get slowed down by roundtrips. KDE 3 was rather static and didn't animate much (I assume that you disabled the tooltips of Kicker). Animations mean that way more data needs to be transferred to the server and thus one easily hits bandwith limits. There is a global setting to disable the animations, though it's not honored by all applications: systemsettings -> Application Appearance -> Style -> Fine Tuning (tab) -> Graphical effects (dropdown) hardly any software written in the last decade is suited for that, because as I explained X is not suited for it. Especially Firefox is no surprise. The complete content is considered as one canvas and the modern web is just updating all the time. On a local system it doesn't matter, but on a remote it means transferring video data for which X is not suited for. The same more or less with OpenOffice. The rendering is probably done client side, so it transmits the complete document view as one image to X whenever it changes. If you are a fast typer that will be painful. No :-) It had never been considered and there are better ways today. Think of the broadway HTML capabilities of GTK which gives you for example OpenOffice in a browser. The general recommendations as already mentioned in this mail summarized: * ensure graphics system is native * disable all animations (everywhere) * don't use Oxygen or any other heavy style - neither as window decoration nor as widget style * switch to a less detail icon theme, best disable icons globally for toolbars, menus, etc. Each icon needs to be transferred uncompressed * stick to an older version of KDE SC (max 4.8 I'd say), the latest ones use QML and are probably ignoring the animation settings everywhere because it has become so easy to do animations. My personal advice is to reconsider the setup and think about whether X is the proper choice. If you still think X is the proper choice rethink what you want to use. Both GTK and Qt have moved away from using X for rendering, so you need something extremely simple which uses plain old X for everything. Maybe openbox is a solution - LXDE, though, isn't as they also switch to Qt. Cheers Martin

Sorry, I have to add my 2c: Isn't that true for each and every project? IMO the whole "discussion" misses the point. TDE is a wonderful piece of software and I appreciate every afford put into it. It's the only DE running fluently on my older IBM flee (A3*, T4*, X6*, T6*) . I am quite sure it's not only me who is using "antique" hardware that will not go out of business the next decade. Admitted, TDE could need a marketing bootst :-) Nik -- Mag. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

Am Mittwoch, 18. September 2013 schrieb PICCORO McKAY Lenz: Oh, even the "awesome" window manger has it's community ;-) And on what facts do you base the assumtion that TDE is only used by it's developers? It has not more bugs pending than any other DE, I'd even say it has less. Anyhow, this discussion leads nowhere. Either you like to use TDE, then use it, or take something more apropriate for your needs. Nik -- Mag. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

On Wednesday 18 September 2013 11:01:03 you wrote: Pointless, but none the less...in uspport of the great work of the dev's. I am not a TDE dev,I do use it on my local business net of 5 machines, more of a small enterprise attitude, it works don't change it. About 10 years of mail archives in Kmail, do not want to screw that up ! A kdepim, gwenview, digikam, k3b user. Used to use these apps with Windowmaker but since TDE maintains them I can and did switch to TDE as a DE. I belong to my local LUG, ( support your local LUG) of which there are other users of TDE that don't know or care to know about these forums, do not partitipate. TDE works so well on older hardware which, as a LUG, we can reuse..not recycle. Every so often a noisy person drops in on this list, trash talks, then moves on...sigh -- Peace, Greg