I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
If you install 3.5.13 you will get too much trouble. I think, that implementing all the missing features into KDE4 is less cost, than waiting when this woe project will get to a decent condition.
On Fri, Sep 13, 2013 at 01:09:57PM +0400, Aleksey Midenkov wrote:
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas.
Would you please identify these "unprofessional decisions" and "strange unpractical ideas" ?
In fact, it came to a logical unsuccessful end.
Has the project been terminated? There's no hint of that on the website.
If you install 3.5.13 you will get too much trouble.
Please specify this trouble.
I think, that implementing all the missing features into KDE4 is less cost, than waiting when this woe project will get to a decent condition.
I thought TDE was pretty well usable now. (Haven't tried it myself, still using KDE3.)
From what I've seen, the problem with KDE4 isn't only that it lacks some features. It has some very undesirable aspects, which is why so many people want to stay with KDE3 (which OpenSuse still offers in its latest version 12.3) or TDE.
o KDE3 and TDE try to be minimal systems to get the job done. That's the Unix way. KDE4 throws in a lot of misfeatures that most people don't need.
o KDE4 has trashed the virtual desktop system. The desktop switcher (pager) applet puts window outlines in the button for each desktop and they obscure the desktop's name. I use all 20 desktops, each for a different purpose (Mail, Music, Website, etc.), and each containing multiple konsoles with mc running in them pointed to appropriate places in the file system for that purpose. I can get to any of these places with two mouse-clicks, and the computer works as a wonderful extension of my mind. With KDE4 it feels like I've had a stroke.
o KDE4 has a non-intuitive UI for setting up and adjusting panels and their contents.
o KDE4 tries to index the _contents_ of every file in the system, which paralyzes the computer unless you make the programs that do this non-executable.
This "feature" is unnecessary, because you can make files findable by giving them good descriptive names, and organizing the filesystem hierarchically by subject, e.g., /science/energy/solar. Then use the locate command with a handy bash script like the one below, that constructs a pipeline of locate and greps for you from the keywords you specify, and executes it.
o KDE4 tries to force you to use the Phonon sound system, which doesn't work with some sound hardware. I had to rip that out and use ALSA.
o KDE4's panels don't retract.
o The KDE4 devs aren't very responsive to user needs. I tried several times to get them to fix the problem with the virtual desktop pager, but they weren't interested. (And they didn't want my hacked version that fixed it, because I'd eliminated the window outlines permanently.) They either use only a single desktop, or they use the "activities" system, which they think should replace virtual desktops. But there's no good applet for switching between activities with minimal mousing.
KDE4 is not an incremental improvement over KDE3. It's an entire redesign, and I'm talking about what the user sees, not the innards. The people who redesigned it apparently thought that they knew better than all those who had created KDE3 and previous versions. In my opinion, they didn't, and they created an ugly monster. I find KDE4 very aggravating, and will not use it.
I'm very grateful that TDE exists, and I'm sure that many other people are, too.
Mark
******************************************************
#!/bin/bash # locgrep
if [ -z "$1" ]; then echo 'Usage: locgrep string1 string2 ... [-v stringA stringB ...]' echo echo 'Find files in the locate database whose pathname' echo 'contains all of the strings 1, 2, etc,' echo 'and none of the (optional) strings A, B, etc.' echo 'Case insensitive.' exit fi
function printfct { while read fqname; do size=$(stat -c %s "$fqname") size2="$(printf "%'13d" $size)" echo "$size2" $fqname done }
cmd="locate -i $1" vflag=false
while [ -n "$2" ]; do if [ "$2" = "-v" ]; then vflag=true else if $vflag; then cmd=$cmd" | grep -iv $2" else cmd=$cmd" | grep -i $2" fi fi shift done
eval $cmd | sort | printfct | less
exit
******************************************************
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.
On Fri September 13 2013 02:09:57 Aleksey Midenkov wrote:
I think that the project is not capable of public use and rather suited for small group of inside hackers.
Our happy user base - non-technical people such as journalists, authors, teachers, and lawyers - respectively disagree with you.
--Mike
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
While in hindsight some of the project's goals were a bit too ambitious, this has been true at some point for many open-source projects over the years. A better measure of success is whether or not the project is still alive and moving forward, along with an active and engaged userbase. At this time I think we can answer both questions with "Yes!".
If you install 3.5.13 you will get too much trouble. I think, that implementing all the missing features into KDE4 is less cost, than waiting when this woe project will get to a decent condition.
I encourage you to hack on the KDE SC 5 sources to fix the issues you have experienced, and then work on getting the resultant patches into KDE SC 5 so that all may benefit from them. AFAIK the KDE 4 series has transitioned into maintenance mode at this time, so it is highly unlikely that you will get anything UI-changing accepted into the KDE 4 series branches.
Just my $0.02. :-)
Tim
2013/9/13 Aleksey Midenkov midenok@gmail.com
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Strictly speaking, this is not true I've talked to a couple people who are using trinity and not subscribed to the developer mail list ;-) Although I'm not sure if there are any other such people anywhere...
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
I believe you are speaking about qt3 API breakage. If so, I'm totally agree with you... IMO that was really crappy choice independently of reasons. I can name some other controversial moments but they are relatively small...
If you install 3.5.13 you will get too much trouble. I think, that implementing all the missing features into KDE4 is less cost, than waiting when this woe project will get to a decent condition.
I've got the same thoughts sometimes: to port kicker, kdesktop and keramik style to kde4 and there will be no need in trinity. I've even tried to start several times to port kicker and keramik... But all this have gone nowhere...
On the other side: even if we won't take into an account the fact that all this would require numerous of efforts, and if we will be able to push our patches to kde upstream, anyway we can't do anything about performance issue of kde/qt 4/5. Sad but true.
2013/9/13 Aleksey Midenkov midenok@gmail.com
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Strictly speaking, this is not true I've talked to a couple people who are using trinity and not subscribed to the developer mail list ;-) Although I'm not sure if there are any other such people anywhere...
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
I believe you are speaking about qt3 API breakage. If so, I'm totally agree with you... IMO that was really crappy choice independently of reasons. I can name some other controversial moments but they are relatively small...
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
Le 14/09/2013 03:41, Timothy Pearson a écrit :
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
I confirm that, with TDE R14, I manage to get working KDE4, working KDE3 and working TDE at the same time on the same openSuse computer. So we leave alone QT3 for KDE3, now TDE is using TQT3 with its own API without conflict with anyone else.
Francois
2013/9/14 Timothy Pearson kb9vqf@pearsoncomputing.net
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
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@free.fr
I confirm that, with TDE R14, I manage to get working KDE4, working KDE3 and working TDE at the same time on the same openSuse computer. So we leave alone QT3 for KDE3, now TDE is using TQT3 with its own API without conflict with anyone else.
Francois
At least one conflict is still there: both tqt and qt3 uses QTDIR
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?
Le 14/09/2013 12:16, Fat-Zer a écrit :
2013/9/14 François Andriot <francois.andriot@free.fr mailto:francois.andriot@free.fr>
I confirm that, with TDE R14, I manage to get working KDE4, working KDE3 and working TDE at the same time on the same openSuse computer. So we leave alone QT3 for KDE3, now TDE is using TQT3 with its own API without conflict with anyone else. FrancoisAt least one conflict is still there: both tqt and qt3 uses QTDIR environment variable. If we started to talk about it, Tim, can we do something about that?
I don't know if TQT really uses QTDIR variable, but at least I'm sure it's not needed. The way we build R14 puts libraries in standard locations (e.g /usr) , and TDE runs perfectly without any QTDIR environment variable set. I think we can safely rename QTDIR to TQTDIR, just in case someone builds TQT under non-standard prefix.
Francois
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
2013/9/13 Aleksey Midenkov midenok@gmail.com
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Strictly speaking, this is not true I've talked to a couple people who are using trinity and not subscribed to the developer mail list ;-) Although I'm not sure if there are any other such people anywhere...
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
I believe you are speaking about qt3 API breakage. If so, I'm totally agree with you... IMO that was really crappy choice independently of reasons. I can name some other controversial moments but they are relatively small...
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.
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?
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.
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?
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.
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
2013/9/13 Aleksey Midenkov midenok@gmail.com
<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.
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 to get into this argument yet again. If Qt4/Qt5 become suitable for our use in the future, then we will consider a port. Until then, TDE continues to be available for X11 based systems as it always has.
Tim
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@pearsoncomputing.net> wrote:
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
2013/9/13 Aleksey Midenkov midenok@gmail.com
<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.
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 to get into this argument yet again. If Qt4/Qt5 become suitable for our use in the future, then we will consider a port. Until then, TDE continues to be available for X11 based systems as it always has.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Mon, Sep 16, 2013 at 10:14 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
2013/9/13 Aleksey Midenkov midenok@gmail.com
<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.
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.
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.
I don't want to get into this argument yet again. If Qt4/Qt5 become suitable for our use in the future, then we will consider a port. Until then, TDE continues to be available for X11 based systems as it always has.
The problem is not with that. The problem is with that you are trying to comprehend incomprehensible. I see the progress and the results.
Tim
On Mon, Sep 16, 2013 at 10:14 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
2013/9/13 Aleksey Midenkov midenok@gmail.com
<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
On Wed, Sep 18, 2013 at 9:10 PM, Timothy Pearson kb9vqf@pearsoncomputing.net 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
On Thu, Sep 19, 2013 at 12:35 PM, Aleksey Midenkov midenok@gmail.com wrote:
On Wed, Sep 18, 2013 at 9:10 PM, Timothy Pearson
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.
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"
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"
To put it simple: it does not work.
On Thu, Sep 19, 2013 at 1:45 PM, Mag. Dr. Nikolaus Klepp office@klepp.biz 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"
To put it simple: it does not work.
Well, it worked at least until the April 13, 2011. Maybe things have changed since then.
On Thursday 19 September 2013 13:20:01 Aleksey Midenkov wrote:
On Thu, Sep 19, 2013 at 12:35 PM, Aleksey Midenkov midenok@gmail.com
wrote:
On Wed, Sep 18, 2013 at 9:10 PM, Timothy Pearson
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.
Hmm, I've just read of a little bit opposite. On Xorg Qt4 uses XRender for composing by default.
That's for rendering, not for "compositing" as Tim talked about. It's a different can of worms.
This is done on server side and this engine is very slow. If to switch Qt4 to raster engine, then performance goes to normal.
And that's why raster engine is the default since 4.8 and xrender is no longer present in 5.x. None of these improvements is present in Qt 3 btw, as Qt 3 only supports the slow XRender implementation.
Cheers Martin
This is done on server side and this engine is very slow. If to switch Qt4 to raster engine, then performance goes to normal.
And that's why raster engine is the default since 4.8 and xrender is no longer present in 5.x. None of these improvements is present in Qt 3 btw, as Qt 3 only supports the slow XRender implementation.
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?
Cheers Martin
On Thursday 19 September 2013 13:15:16 Mag. Dr. Nikolaus Klepp wrote:
This is done on server side and this engine is very slow. If to switch Qt4 to raster engine, then performance goes to normal.
And that's why raster engine is the default since 4.8 and xrender is no longer present in 5.x. None of these improvements is present in Qt 3 btw, as Qt 3 only supports the slow XRender implementation.
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?
well first we have to define what "slow" means. Then we have to setup a benchmark which verifies that it is in fact slower. At the moment I don't have any possible way to validate your claim - I have to believe it (no offense, but I do not, see below).
If we can verify that it is in fact slower, then we can look into why that is the case. My personal assumption is that something is incorrectly configured and the newer setup just exposes the problem. Also there's the possibility of bugs in the application you tried or that you compared incomparable things (e.g. Kicker vs Plasma - doesn't make sense, doesn't say anything about Qt).
So let's start with: how do you test that Qt 4 is slower than Qt 3? What's your test, where can I get the source to verify it?
Just as a small reminder: do you really think that can be the case? Qt 4 got trimmed to run on smartphones - I have a few of those (e.g. the N9 and the N950, also used to have a Symbian device) and they would love to have the specs of your X61. Given that Nokia invested lots of money in that area, do you really think the engineers would not have realized that Qt 3 was faster, look at that code and make better use of it in Qt 4?
Cheers Martin
So let's start with: how do you test that Qt 4 is slower than Qt 3? What's your test, where can I get the source to verify it?
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.
Just as a small reminder: do you really think that can be the case? Qt 4 got trimmed to run on smartphones - I have a few of those (e.g. the N9 and the N950, also used to have a Symbian device) and they would love to have the specs of your X61. Given that Nokia invested lots of money in that area, do you really think the engineers would not have realized that Qt 3 was faster, look at that code and make better use of it in Qt 4?
And Nokia is still the rising star of smartphone universe ;-)
Nik
On Thursday 19 September 2013 15:00:06 Mag. Dr. Nikolaus Klepp wrote:
So let's start with: how do you test that Qt 4 is slower than Qt 3? What's your test, where can I get the source to verify it?
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 with that we are back to lets' define slow and don't compare what cannot be compared.
KWin4 is a compositor, KWin3 isn't. With other words you are comparing Apples to Oranges. I don't know why you experience a slowness with KWin4 but it's not supposed to be that way :-) I know the code and everything just got much faster. I'm sorry that you have bad experiences but I'm quite sure that your issues could be solved (first step: qdbus org.kde.kwin /KWin supportInformation).
Just as a small reminder: do you really think that can be the case? Qt 4 got trimmed to run on smartphones - I have a few of those (e.g. the N9 and the N950, also used to have a Symbian device) and they would love to have the specs of your X61. Given that Nokia invested lots of money in that area, do you really think the engineers would not have realized that Qt 3 was faster, look at that code and make better use of it in Qt 4?
And Nokia is still the rising star of smartphone universe ;-)
and that matters exactly what to the discussion? You are also aware that Nokia decided the switch to Windows Phone before the only MeeGo phone got released?
Cheers Martin
On Thursday 19 September 2013 12:35:17 Aleksey Midenkov wrote:
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.
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 12:35:17 Aleksey Midenkov wrote:
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.
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
My apologies; I was not referring to compositing in the window management sense, I was referring to the new painting system code in Qt4 (Arthur: http://www.trinitydesktop.org/docs/qt4/qt4-arthur.html), and even more specifically to things like the backing store introduced in Qt 4.1 (http://doc.qt.digia.com/qq/qq16-background.html).
While I don't have a link to it handy, newer versions of Qt essentially are just blasting pre-rendered pixmaps to the X server on every change (graphics system raster). In fact, Qt is working hard on removing native bindings and replacing them with their software-only renderer (http://blog.qt.digia.com/blog/2009/12/18/qt-graphics-and-performance-the-ras...) for performance reasons.
I have to ask: If the XRender system worked so well in Qt3, even over the network, why is the XRender system working so badly in Qt4 that Nokia now needs to fall back on a software rasterizer? What changed?
Even over a fast RDP connection (yes, RDP, not X11 native, though X11 native shows the same effect) I can tell the difference between Qt3 and Qt4 apps just from their redraw speed alone. Essentially, *as far as I can tell*, if your remote desktop is not blasting entire screens over the network on each update (e.g. some old versions of VNC), you will see a definite performance difference between Qt3 and Qt4 apps. My best *guess* is that the graphics server does not know what changed when a Qt4 app updates its visible contents, therefore it sends the entire contents of the window over the remote desktop connection, even if 99% of the pixels are the same.
I probably got some of the Qt4 stuff above wrong as usual, but I don't really have the time or desire to keep up with the latest Qt4 information as I don't use Qt4 very often. :-) All I know is that there *is* a performance drop on many systems (unquantified, though this seems most severe on non-VNC remote desktops) that so far has eluded the teams at Nokia, the various KDE SC developers, the TDE developers, and various application developers such as Xilinx.
Tim
On Thursday 19 September 2013 13:35:42 Timothy Pearson wrote:
I have to ask: If the XRender system worked so well in Qt3, even over the network, why is the XRender system working so badly in Qt4 that Nokia now needs to fall back on a software rasterizer? What changed?
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.
Even over a fast RDP connection (yes, RDP, not X11 native, though X11 native shows the same effect) I can tell the difference between Qt3 and Qt4 apps just from their redraw speed alone. Essentially, *as far as I can tell*, if your remote desktop is not blasting entire screens over the network on each update (e.g. some old versions of VNC), you will see a definite performance difference between Qt3 and Qt4 apps. My best *guess* is that the graphics server does not know what changed when a Qt4 app updates its visible contents, therefore it sends the entire contents of the window over the remote desktop connection, even if 99% of the pixels are the same.
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 ;-)
I probably got some of the Qt4 stuff above wrong as usual, but I don't really have the time or desire to keep up with the latest Qt4 information as I don't use Qt4 very often. :-) All I know is that there *is* a performance drop on many systems (unquantified, though this seems most severe on non-VNC remote desktops) that so far has eluded the teams at Nokia, the various KDE SC developers, the TDE developers, and various application developers such as Xilinx.
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".
On Saturday 14 September 2013 02:54:43 Fat-Zer wrote:
I've got the same thoughts sometimes: to port kicker, kdesktop and keramik style to kde4 and there will be no need in trinity. I've even tried to start several times to port kicker and keramik... But all this have gone nowhere...
just for the record: kicker was already more or less ported to Qt4 at the time it got replaced by Plasma. It was in the source code till October 2007 [1], just a few months prior to the 4.0 release. So it would be a good idea starting from this point.
And I personally agree on that this would be a better approach for Trinity from a maintenance point of view as I have pointed out a few times in the past ;-)
Cheers Martin
[1] dcc7c9fc85524b5fb2b19e5c6755deb99f07f5e9 (http://commits.kde.org/kde-workspace/dcc7c9fc85524b5fb2b19e5c6755deb99f07f5e... )
Am Samstag, 14. September 2013 schrieb Martin Graesslin:
On Saturday 14 September 2013 02:54:43 Fat-Zer wrote:
I've got the same thoughts sometimes: to port kicker, kdesktop and keramik style to kde4 and there will be no need in trinity. I've even tried to start several times to port kicker and keramik... But all this have gone nowhere...
just for the record: kicker was already more or less ported to Qt4 at the time it got replaced by Plasma. It was in the source code till October 2007 [1], just a few months prior to the 4.0 release. So it would be a good idea starting from this point.
And I personally agree on that this would be a better approach for Trinity from a maintenance point of view as I have pointed out a few times in the past ;-)
Cheers Martin
[1] dcc7c9fc85524b5fb2b19e5c6755deb99f07f5e9 (http://commits.kde.org/kde-workspace/dcc7c9fc85524b5fb2b19e5c6755deb99f07f 5e9 )
Which does not solve the slugish performance of QT4 :-/
Nik
On Saturday 14 September 2013 20:51:15 Mag. Dr. Nikolaus Klepp wrote:
[1] dcc7c9fc85524b5fb2b19e5c6755deb99f07f5e9 (http://commits.kde.org/kde-workspace/dcc7c9fc85524b5fb2b19e5c6755deb99f0 7f 5e9 )
Which does not solve the slugish performance of QT4 :-/
Nik
Too much FUD about QT4 performance :) Note that LXDE is migrating to QT4.
Since the talk of TQT can someone explain how to port a KDE3/QT app to Trinity/TQT?
On 9/14/13, Serghei Amelian serghei@thel.ro wrote:
On Saturday 14 September 2013 20:51:15 Mag. Dr. Nikolaus Klepp wrote:
[1] dcc7c9fc85524b5fb2b19e5c6755deb99f07f5e9 (http://commits.kde.org/kde-workspace/dcc7c9fc85524b5fb2b19e5c6755deb99f0 7f 5e9 )
Which does not solve the slugish performance of QT4 :-/
Nik
Too much FUD about QT4 performance :) Note that LXDE is migrating to QT4.
-- Serghei
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Martin Graesslin wrote:
On Saturday 14 September 2013 02:54:43 Fat-Zer wrote:
I've got the same thoughts sometimes: to port kicker, kdesktop and keramik style to kde4 and there will be no need in trinity. I've even tried to start several times to port kicker and keramik... But all this have gone nowhere...
just for the record: kicker was already more or less ported to Qt4 at the time it got replaced by Plasma. It was in the source code till October 2007 [1], just a few months prior to the 4.0 release. So it would be a good idea starting from this point.
It is indeed not so hard to get this to compile against KDE 4.11 again. I just pushed the mentioned Kicker port to GitHub with some fixes to get it to compile and run against KDE 4.11.
Maybe I'll play a bit more with it when I have time. It would be nice to see how kicker & kdesktop on KDE 4 would work. I don't think it could replace Trinity in every single situation, but I think could be an interesting alternative.
If anyone would like to look more at this, be sure to get in touch.
Best regards, Julius
I use Trinity since January 2011 on every X-equiped machine I use.
So far, I had some issues, but what I like with Trinity is that it kept KDE3 living. TDE provides a consistent user experience. Thanks to the user interfaces that are not changing every month, I can continue to use my computers without being forced to relearn everything after each "improvment".
Nicolas
On 13/09/2013 11:09, Aleksey Midenkov wrote:
I watch over Trinity project for as long as 3 years. I want to give my grade on its development activity. I think that the project is not capable of public use and rather suited for small group of inside hackers.
Along the history of development there were too much lame unprofessional decisions. It was fulfilling some strange unpractical ideas. In fact, it came to a logical unsuccessful end.
If you install 3.5.13 you will get too much trouble. I think, that implementing all the missing features into KDE4 is less cost, than waiting when this woe project will get to a decent condition.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Good point. I second that.
On Tue, Sep 17, 2013 at 12:47 PM, Nicolas Bercher nbercher@yahoo.fr wrote:
I use Trinity since January 2011 on every X-equiped machine I use.
So far, I had some issues, but what I like with Trinity is that it kept KDE3 living. TDE provides a consistent user experience. Thanks to the user interfaces that are not changing every month, I can continue to use my computers without being forced to relearn everything after each "improvment".
Nicolas
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 midenok@gmail.com wrote:
Good point. I second that.
On Tue, Sep 17, 2013 at 12:47 PM, Nicolas Bercher nbercher@yahoo.fr wrote:
I use Trinity since January 2011 on every X-equiped machine I use.
So far, I had some issues, but what I like with Trinity is that it kept KDE3 living. TDE provides a consistent user experience. Thanks to the user interfaces that are not changing every month, I can continue to use my computers without being forced to relearn everything after each "improvment".
Nicolas
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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!
Then I suggest you use the desktop environments that you mentioned, as they are apparently a better fit for your needs. Open source is all about choice--that not only includes user choice in software selection, but also developer choice whereby hackers can improve software in ways that they need for their particular application(s).
Oh, and enough with the Windows bashing already. :-) Like any other system (including various Linux DEs and OS X), Windows has its strengths and its flaws. There is no reason we need to succumb to NIH syndrome and ignore good ideas from other systems.
Tim
<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.
On Wednesday 18 September 2013 18:48:11 Russell Brown wrote:
<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.
+1
On Wednesday 18 September 2013 18:48:11 Russell Brown wrote:
<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
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
Quoth Martin Gr��lin.....
On Wednesday 18 September 2013 18:48:11 Russell Brown wrote:
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
at least for KDE Plasma this is not true - we do not demand 3D graphics acceleration in the 4.x series.
OK obviously my mistake in understanding the root cause; Sorry... but the bottom line was that we have up to 90 X-Terminals (modest hardware, pretty low grade graphics chipsets, some with 64 or 128 megabytes of RAM, no local storage; no local swap) running on KDE3/QT3 for years (TDE since late 2012) on a modest network (the terminals are on 100Mbit ethernet from a couple of 48 port hubs being fed by a single 1Gbit ethernet connection from the Linux terminal server).
This works very well.
When KDE4 came along (and the LTS on Hardy came to an end prompting a need to change) I tried very hard to get it to work at an acceptable performance level and just failed :-( The 'user experience' really wasn't nice. I Googled and tweaked, tweaked and Googled but couldn't get the interactive feel anything like KDE/QT3 on the same hardware. It was painful to use or just blew away the terminals with small amounts of RAM (my memory is possibly a bit fuzzy here as it was well over a year back when this all happened).
Changing the infrastructure for high bandwidth connections and more powerful machines on everyone's desk just didn't make any sense when the net benefit was 'only' a slightly different look to the desktop and some widgets and concepts that they didn't understand (this from a users perspective; I'm not denigrating the efforts that the KDE4 team have obviously put in).
Hence my delight at the whole TDE project :-)
X11 is unfortunately although claimed otherwise completely unsuited for terminal setups. It mostly works because bandwith is enough, but in general it just sucks.
Hmmmm.... it's suited us since the mid 1980s !
Obviously we have 'enough' bandwidth for TDE but not enough for KE4/QT4. That might sound like a backhanded compliment but it's not intended that way; I'm just saying it as I found it.
KDE4/QT4 seems to be aimed elsewhere than our sort of usage. It's sadly not alone there with things like Firefox and Openoffice assuming that the display device has both a lightspeed connection and infinite resource. The whole concept of X11 client (lots of resource typically running on a powerful server grade computer) and X11 server (limited resource merely a device to provide a mouse/keyboard and screen) seems to have been forgotten.
It's a bit like all those graphics heavy flash ridden websites that obviously looked great when the 'designer' demo'd them to the client on his powerful laptop in a meeting room but are just awful when accessed via the congested and limited internet that we mostly have to live with.
On a positive note, you offered to tell me how KDE4 can be configured for a Terminal Server environment and I'll take you up on that; if only for my own education and to find out what I, and many others it seems, did wrong.
However, if TDE carries on the way it has been then I can't see myself moving away from it.
Thanks once again to the whole TDE team.
On Thursday 19 September 2013 13:40:07 Russell Brown wrote:
X11 is unfortunately although claimed otherwise completely unsuited for terminal setups. It mostly works because bandwith is enough, but in general it just sucks.
Hmmmm.... it's suited us since the mid 1980s !
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.
Obviously we have 'enough' bandwidth for TDE but not enough for KE4/QT4. That might sound like a backhanded compliment but it's not intended that way; I'm just saying it as I found it.
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)
KDE4/QT4 seems to be aimed elsewhere than our sort of usage.
hardly any software written in the last decade is suited for that, because as I explained X is not suited for it.
It's sadly not alone there with things like Firefox and Openoffice assuming that the display device has both a lightspeed connection and infinite resource.
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.
The whole concept of X11 client (lots of resource typically running on a powerful server grade computer) and X11 server (limited resource merely a device to provide a mouse/keyboard and screen) seems to have been forgotten.
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.
On a positive note, you offered to tell me how KDE4 can be configured for a Terminal Server environment and I'll take you up on that; if only for my own education and to find out what I, and many others it seems, did wrong.
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.
However, if TDE carries on the way it has been then I can't see myself moving away from it.
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
i talk about KDE3 parts that still not in stable... i'm a developer and i need a powered desktop, KDE3 was a powered desktop but hav some problems, i was in hope TDE will improved but still here...
Tim u only response few topics, and window only.. If the project is maintained only by the few who use it one day will consume its developers, remenber u must keep a job, some other also a family... think abou it je je
On 9/18/13, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
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)?
? what about that?
by the way, what are the projects goals?
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 now compile and install with newers versions of current older software and integrates with new libs.. but real thing like kdenetwork are hte features that we need! thanks for Tdenetwork
its a great work that KDE3 now can be installed on newer versions of linuxes.. but its a pain the changes .. and from KDE3 to TDE there many changes on install process, but few in real features as now many here said
kmplayer works: not complety kdenlive works: not complety mlt : older (but works, thanks) kppp: not work kvpn: work only with few protocols kopete: not work all protocols
My advice: focused in bugfixeds and support event features But now its late, TDE its in a ported fase from KDE to TDE naming sheme...
Remenber: If the project is maintained only by the few who use it one day will consume its developers, TDE its like xp with spteroits
Sorry, I have to add my 2c:
[...] Remenber: If the project is maintained only by the few who use it one day will consume its developers, TDE its like xp with spteroits
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
On 9/18/13, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Admitted, TDE could need a marketing bootst :-)
Nik
yeah nik that's the point, du u read the mails, who will market a DE only used by its developers, and with many bug pending, and that goes behing of wndo like path!
Am Mittwoch, 18. September 2013 schrieb PICCORO McKAY Lenz:
On 9/18/13, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Admitted, TDE could need a marketing bootst :-)
Nik
yeah nik that's the point, du u read the mails, who will market a DE only used by its developers, and with many bug pending, and that goes behing of wndo like path!
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
On Wednesday 18 September 2013 20:01:03 PICCORO McKAY Lenz wrote:
On 9/18/13, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Admitted, TDE could need a marketing bootst :-)
Nik
yeah nik that's the point, du u read the mails, who will market a DE only used by its developers, and with many bug pending, and that goes behing of wndo like path!
Piccoro, with all due respect, you come across like an immature 18 year old. You have no idea of the depth and breadth of the users of Trinity or KDE3 for that matter. What you want as a developer and what is wanted by users in general are/maybe totally different things.
Your opinion is valuble, and ought to be constructive but the way in which it is given leaves something to be desired.
KDE4 for me is not a useable desktop ! For others it is the next best thing. Many cannot afford to upgrade hardware just to support the latest Windows etc. I like most people, I belive, need something that just works. Trinity fills that need.
On Wednesday 18 September 2013 11:01:03 you wrote:
On 9/18/13, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Admitted, TDE could need a marketing bootst :-)
Nik
yeah nik that's the point, du u read the mails, who will market a DE only used by its developers, and with many bug pending, and that goes behing of wndo like path!
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
On 9/18/13, Greg Madden gomadtroll@gci.net wrote:
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 !
5 machines. ok well better than none right? so then u' must send money to TDE developer o patrocinate.
Every so often a noisy person drops in on this list, trash talks, then moves on...sigh
hard wors for a little very little enterprise..
i was using TDE in my (more thant 5, je je) machines on a distribute network over my country.. but i clarelly TDE has no focus, can see that in the X11 behavior discusion now
i copy that to my parners in my job
-
Aleksey Midenkov -
Baron -
Fat-Zer -
François Andriot -
Greg Madden -
Julius Schwartzenberg -
Mag. Dr. Nikolaus Klepp -
Mark S Bilk -
Martin Graesslin -
Martin Gräßlin
-
Michael Henry -
Mike Bird -
Nicolas Bercher -
PICCORO McKAY Lenz -
russell＠lls.lls.com -
Serghei Amelian -
Timothy Pearson