And this is the single greatest cause of crashes: it's overprogrammed.

As someone who spent a lot of time on performance and stability: thanks for wasting my time. 

How to do it: how to rewrite the screen refresh:

It is simplicity itself.  Define an area in memory per NTSC or PAL screen.  This should take up the number of pixels in a full screen scan, generally, 3.6 megabits, but can be 6.0 unencoded, or higher for HDTV scanning.  Make this memory locked into local cache or RAM directly to the video.  Make as many areas as you like, within your memory limits, make the limits selectible by the user.

Now, instead of "refreshing" the screen content, write a module of code that changes the "pointers" and instead of updating the screen, update the pointer to the screen.  That should mean that the video can now change in one machine execution cycle, or, faster than you'll ever see it.

Normal video is scanning the screen at about 3.6 mHz, interlacing and all, it's still so fast you can't see it change.  And new TV's and monitors are even faster, HDTV for instance.  They revolve around one thing; the broadcast frequency.  If my television changes the screen so fast I can't see it, or it looks like a continuous image, as in a movie or something of normal everyday "sight" activity, why is it that my computer acts like one of those old nickelodeon hand-cranked, early movie images of about the 1890's?

Because no one has ever tried to improve the process of computer TV.

I have written such a routine, some years back, for very early computers; before Microsoft existed, so I know it works.  In the early days of Windows, which came from GeOS, which came from a bunch or early BBS pioneers in graphics and the original Windows [which was not written by Microsoft, nor owned by them], the name of the routine was simply "screen" and it can be traced back before 1979.

I may be forced to write it for KDE and Linux because the windows environments have gone too far with overloaded programming, bells, whistles, and peripheral and secondary concerns.  The primary concern of a graphics environment is always speed.

Everything else is decoration.

Try the relative pointers update; it works.  Pre-process your screens in the video pipeline pre-processing queue so that they are ready before the update is called.  I/O and perhaps the Video Chip Set should be able to do this for you, up to how ever many screens you need.  If size becomes a question, feed a disk cache area to local memory, RAM, or video memory in off-cycles at pre-processing time.  This is how CDR and DVDR do it; say 100-600 meg of space, perhaps up to 4 gig for DVD type feeds and super graphics resolution.  4 gig RAMS will not be unheard shortly.

Advise your Video Chip Set manufacturers to start putting some real memory in their sets, gigs of memory, no longer megs.

Try working with them.  They have a lot to gain by implementing this concept; sales of new video cards and monitors/TV's.  Which they need in the current market.

Phillips should already be on this because they have basically made all of the innovations in plasma and LCD HDTV to supplement their Direct Broadcast Satellite Television [Direct TV].

Lord Thompson and Rupert Murdock already had Professor Midwinter, of Imperial College, London, England, work out the schema of pixelation; changing only delta areas in TV scanning and not the whole screen.  Professor Midwinter is working in femtoseconds, by the way, far ahead of these nanosecond technologies.  And these developments are over 20 years old already!

And that, my dear friends, was based on refreshing the pointers and not the whole screen!  Does anyone get the point yet?

Meanwhile, KDE is slugging along, drib-a-drib, drab-a-drab, like some slug that crawled out of the network wiring.

And "slow" translates as "going to crash."  It is a fact.  When you bog down a processor in checking 9 million if statements to look for some new feature, like "word completion." it is going to crash!  As the stack seeks more and more memory to meet your nested statements, is sucks up RAM, then disk cache, then starts thrashing, and eventually the bubble bursts.  Why?  Because you're asking the processor to do too much borrowing from Peter to pay Paul in memory usage.  The generic term is efficiency, another major area of concern in KDE programming.  KDE is NOT efficient.

Efficiency is using object oriented programming, that is, calling a module with its own little stack, when you need it, then reinitializing that stack so other modules can use it when you're done with it.  At the same time, you keep track of the nesting of modules so that you don't overbloat the entire stack and hence memory.  KDE does not do this, instead relying on uncompiled scripts, plugins [which mismanage their own memory and stacks], and generally parsing everything in sight.  This is not how object oriented programming and modular programming work, this is a throwback to batch processing.

The great example of KDE's slowness is in it's mishandling of the keyboard and mouse.  If you type or click too fast while KDE or Konqueror is doing something else [multitasking?], the keystroke and/or the click get quickly mis-assigned.  I have seen this very prevalently when another set of slugs, MySQL and PHP, sites, are accessed.  I sit and watch in amazement as the "click" occurs about a second after I've hit the mouse button, MySQL or PHP have now resized and moved the screen, and my click has changed to a click on a link that I didn't want.

Priority!

The interrupt of the routine, whether C++ or Operating System, must be immediate, of the highest priority, and suspend that routine dead in its tracks!  Not after it has completed a Case or If statement, but smack dab in the middle of such statements.  You do this by resetting the routine!  That means, in pre-processing and mutitasking processing, you roll back the routine that was executing to the "restart" state.  "Restart" in a processor is now a built in hardware function of pre-processing, look-ahead logic, parallel, processing pipeline architecture.  So you're interrupt has to "remember" that the whole routine will be re-executed from it's current caller.

If you really don't know how this works, please find someone who can describe the architecture of the B7800/B7900/MODIII computer systems architecture.  As this is the origin of all such architectures, pre-processing, look-ahead logic, highly parallel, processing pipeline, barrel logic, and all the innovations you take for granted.  You might be able to learn something about programming from the mainframers who designed your software based on their design of their hardware [and not the other way around].

In short, the keyboard and/or mouse must generate an instant IRQ which forces a change to the special mouse/keyboard interrupt handler instantly, regardless of any executing loop within the executing routine, even the keyboard/mouse interrupt handler itself.  And that interrupt request must be handled immediately, not after some window resizing or do loop, etc..

Here is a clue; this mishandling of the keyboard/mouse interrupt causes KDE to crash.  This was seen decades ago on mainframes - catch up!

The keyboard and mouse interrupts must be instantaneous; the gui environment must be suspended immediately upon the click, and not after some delay while a page is loading or resizing.  Someone, somewhere, lost sight of the absolute highest priority in the IRQ [Interrupt Request Queue, remember that one?] to the human interface, i.e., the keyboard and mouse!

And all of this, all-of-this, is due to the lost sight of the basics of computing; speed, accuracy, human friendly.  A computer is mankind's tool, nothing more, so don't try to make it more than it is.  After all, it came from human intelligence, not the other way around.

A tool should be fast, precise, human friendly.

And KDE developers need to take at least one step backwards so they can see the "big picture."

Maksim, take time to read the report, I can teach you something, if you'll listen.

And this was not assigned to you; it may be assigned to myself.  So stop marking it as resolved.

This is the most valid bug in all of KDE.

Your denial proves my point about developers losing sight.  Speed is more important than performance and stability currently as it is the speed of KDE execution that is degrading the stability and performance.

And if it's a waste of your time, that does not mean it is a waste of others' time, so stop making decisions for them, stop trying to "complete their words."

Let it be assigned to me, if it must, ignore it if you will, but stop interfering with my trying to improve KDE and Konqueror.

If you're worried about this low-level of a performance problem, you should really be talking with the X developers and the kernel developers. This is too low-level for KDE and not something we should be implementing. 

Waldo, any comments you have will be appreciated.  Maksim didn't even read the entire thing before dismissing it.

I have, lying about at my property, various designs of hardware which I personally have worked on for some very well known computer manufacturers.  Many of these designs were innovated by myself and a team of top engineers.  We know how computers work.  We're trying to educate others who may not have had the advantages of intricate design, right down to the substrate level.

What I have said about the "restart" micro-operator is particularly important.  It was, at the time of its innovation, an entirely new concept in computer processing.  At the heart of it was the desire to avoid a machine lock-out, that is, when a machine is so tight in a loop that it cannot be interrupted and thus the machine just seems to sit there and do nothing.  The design breaks the loop regardless of the level of execution, thus avoiding the dreaded reset or power off buttons.  The behavior of a machine to get "locked up" is not new, however, as operating systems and programs grow in size and execution requirements, so does the possibility of machine lock up.  The "restart" micro-operator solves this problem.

But after solving that problem, I was specifically assigned to teaching programmers how to use this micro-operator, as they had never seen it before.  All of them loved the concept of this new micro-operator.

It is similar to the supervisory modes and control modes of most micro-operators, but has an even higher priority than all of them.  Which is why it exerts control even over loops.  The great problem was always breaking out of an endless loop.  This micro-operator, implemented in software, was the solution.

Perhaps Maksim doesn't understand that I too have had a lot of experience in performance and stability, but that is no cause to shut someone off who is trying to and can, definitely, help.

As I said, I would like to get some of the developers to listen.  Listen to all I have to say first.  Then consider it.

Matt, you could have waited a bit before trying to invalidate it.

You're really just proving my point about devlopers losing sight and taking a myopic view.

I was there when KDE was created, when X was created, and when the kernel was created.

The problem is exactly what I stated: the manner in which KDE refreshes the screen.  It isn't in the kernel because the kernel doesn't do the KDE screens, KDE does.  And if it were in X, then KDE is dependant upon X, which doesn't make sense either.

If the ignorance of this bug continues, someone else will re-write KDE and rename it, after making the improvement.  And at least they'll get the deserved credit for listening to people.  After all, KDE, X, Windows, and GeOS before them all, was a rewrite of someone else's windows program.  That's what we called it when we wrote it, long before the others copied it.

Now, can anyone discuss this issue, about the modules related to refreshing the screen in KDE and Konqueror?

> This is the most valid bug in all of KDE.

No, it isn't. File concrete bug reports against KDE components, contribute patches or spare bugs.kde.org with your drivel.

I just thought I should add this: Qt4 adds more double-buffering code for most (all?) of its widgets. This should solve SOME of the problems Terry is alluding to.

This will happen in KDE4.

> Tell the developers to rewrite the screen and window refreshes in machine
> code; it's thousands times faster.

That's X's job, not KDE. Please file your wish with them. We can't do a thing about it.

> I may be forced to write it for KDE and Linux because the windows
> environments have gone too far [...]

Please do. We always appreciate new, better code.

I have been working on this problem.  Mostly because KDE crashes about every hour or so.  The time it is taking me to trace and document it is quite extensive.

Begin with this:  any click on a folder while another task is initializing results in the intterupt to the mouse or the keyboard to be handled out of sequence.  This can only result if the priority for the IRQ is out of whack.  And it is out of whack at the most basic of KDE code level, the core interrupthandler.

That happens when programmers lose sight of the fact that the human has the absolute authority to interrupt anything, including a nested do loop, instantaneously, for handling of the human input.  This is crucial to stopping endless loops.  The mouse and keyboard are supposed to be top priority and cause a "restart" of the running function by resetting its status back to where it entered.  The "escape" key should have the same ability to enter Control Mode or Supervisory Mode [as it is called in Intel terminology] and stop all processes and bring up a debug screen for the operator.

I have verified keys typing out of sequence and clicks being assigned out of sequence.

This is because the interrupt for the mouse and keyboard were erroneously "put off" by the interrupthandler while the executing routine finishes up.  That is completely wrong!

That is not multitasking, that is batch processing.

Give me a couple of weeks and I will document the entire thing.  Then I'll consider the fix.

Finding the headers and sources alone takes a couple of days.

This all occurred after trying to create a mimetype, wherein KDE and Konqueror, erroneously [also reported and ignored] change all of the file types, instead of assigning a type to that specific file.  So, an "open with foo" for the filetype chosen, such as text, changed all of the text file associations on the system!  KDE configure and other configures should not have had permissions to do this to the Linux Operating System.  The KDE code there is wrong too.  So now, I have a nice "Could not find mime type: application/octet-stream" which also means that this error pops up everytime the mouseover tries to preview a file.

I found kdatastream.h and related stuff, but because of somewhat disorganized nomenclature of routines, haven't even found the source for octet-stream yet.

That gets back to the basics of paths.  Though they may be agreed upon, that doesn't make them the best.  Headers are included source files, really nothing more than a forward declaration, I would have put them in the source tree, perhaps under include, but I wouldn't have spread all of the sources all over the place.  It's basic organization that seems lacking, and that always results in things being overlooked as programmers struggle more with memorizing where things are than what's wrong with them.

Sources go to source, Objects go to object [lib is such a rather dumb acronymical term anyway], and Programs go to program.  Basic human language, English in this case.

So, while I meander about the compile trees, it will take some time to find the bugs, and there are plenty of them.

By the way, bugs aren't ever made of concrete, unless your computer is in one of the tiers of the Brooklyn Bridge.

Error #12234: Stupidity buffers overflow ....
Rebooting brain ....

Engineers?
So this is what engineers contribute to improve KDE?

(I once worked in the health service, and part of the hospital hosted the local psychiatric ward. There were said to be, sometimes, people who postured like Napoleon, and thought of themselves as the Emperors of Russia. Hmmm... *were* they emperors?)

> And it is out of whack at the most basic of KDE code level, the core interrupthandler. 

LOL. Good luck finding an IRQ interrupt handler in KDE.

Maybe, but it's got to call one, doesn't it?

What I was saying is that no interrupt from the mouse or keyboard should ever be allowed to be maskable.  So, if you know what an NMI [Non Maskable Interrupt] is, you'll understand.

Every time you interract with KDE, whether it's a mouse movement or a keyboard stroke, an interrupt handler has to be called.  Whether or not KDE has its own interrupt handling may be questioned, but not the fact that it has to have one.

One of the great old-time problems was the TCP/IP was not interruptible while waiting for ACK in WAIT state during Internet Tx/Rx.  It only took about 5 years to get W3 to recognise this as a problem, Apache, maybe a bit faster, but it is actually still a problem.

Like I said, the core problems are not in widgets, etc., they are actually in a basic lack of knowledge in exactly how a computer, processor/IO work.  You really can't blame the computer or the Operating System if it somehow has granted permission to mask critical interrupts.

Yesterday, a series of keystrokes caused KDE to freeze the computer.

Using "Time Study" techniques, it is observed that KDE and X use too much time doing nothing.

That's just a fact.

Window refreshes, resizes, too many widgets, compound the problem, whatever its source.

Perhaps a read of the Gnome human interface requirements should be suggested for better development.

Sir, you have made a fool of yourself. You accuse developers of lacking basic
knowledge, while it's in fact you who is. But alas, i had a great laugh =).

We know what interrupts (and NMIs) are. What you don't understand is the layering: the code that handles the mouse is X, not KDE. Please talk to the X.org developers about the mouse handling.
BTW I doubt that the gnome user interface guidelines talk about non maskable interrupts :-)

bla bla bla

Reassigning to the special needs department

It works for me so it must be a problem with your RAS/CAS timing.

The kernal, Linux OS, X, and KDE handle the mouse interrupt, not just one, if you had read what I wrote you would see that I stated other programs were overriding the NMI's, and that that is the problem.

The problem does not occur when fvwm or linux itself is running without KDE desktop frontend.

Corrections:  Peter, learn our native English language and its grammar and syntax before criticizing the knowledge of others:

"Sir, you have made a fool of yourself. You accuse developers of lacking basic 
 knowledge, while it's in fact you who is. But alas, i had a great laugh =). "

Syntax and Grammar error above, dangling participle : who is . . ."  Corrected by tailing " . . . you who is the fool."  Better correction, proper use of pronouns, requoted and corrected:

"Sir, you have made a fool of yourself. You accuse developers of lacking basic 
 knowledge, while it is, in fact, you than lacks the knowledge. But alas, i had a great laugh =). "

Slang-type pseudo-correction:

"Sir, you have made a fool of yourself. You accuse developers of lacking basic 
 knowledge, while it's in fact you that is lacking. But alas, i had a great laugh =). "

Acronyms are abysmal:  RAS/CAS were terms associated with refresh memory, an early form of dynamic memory.  They are also acronyms with entirely different meaning in the field of televsion and broadcasting, so the use of acronyms is discouraged in a scholarly document because they are confusing and often misinterpreted.  The timing of the refresh for the screen should not have any priority related to the NMI's of the mouse and keyboard.  Now, I have referenced NMI above as "Non Maskable Interrupt," and this is how acronyms should be used, with at least one inline reference to their meaning.  All legal documents are written this way, i.e., U.S. Laws, Court Decisions, and all Professional Engineering documents.  In fact, it's a requirement of professionalism.

Besides compiling libsigc++-2.0.6, gtkmm-2.4.6, glibmm-2.4.5, libgnomemm-2.6.0, libgnomecanvasmm-2.6.1, libgladmm-2.4.1, gconfmm-2.6.1, gnome-vfsmm-2.6.1, libgnomeuimm-2.6.0, I am working on disassembler-for-linux-0.2.0 and running into various errors which I am documenting.  Not the least of which is KDE screwing up mouse clicks, and libtool failing for the stupid reason that $VERSION fails because no $VERSION file is currently required by autoterd.

The number of script files, and their sizes, has regressed compilation back to the time when each line of code, now in scripted form, has to be parsed and reparsed, slowing the compile process by over 100 times.

The reason for automake was to automate compile time options in a predictible form.  However, over time, the scripts have grown almost larger than the source codes they are compiling, and parsing them as scripts [interpretors] is fully known to take more than 100 times the cpu time to accomplish.

This was part of my point about disorganization.  Reported errors are vague in compiles.  KDE is no exception.  So I'm working on a way to also make compiles easier and more human friendly.  Versioning is only part of the problem; a look at how Apache sets up a compile is a good read for anyone that want to become a programmer.

I'm working on the problems, in addition to this one, and I use some very basic small files to "workaround" developer problems.  Perhaps you should try these:

Files for critical information, insteading of repeating scripts that do not locate the cause of the failure, or any indication on how to fix it:

LAYOUT
VERSION
ARCHITECTURE
DISTRIBUTION
PACKAGE
OPERATING_SYSTEM
PROGRAMNAME
_Config.Tmpl

These files contain only what is necessary to override environment dependencies which often fail to materialize in autoconf and automake, resulting in a failure by libtool.  libtool often reports failuers in ltconfig, a file that no lone exists, meaning, the developers of libtool either forgot to fix the error message, were in a hurry to get a patched release out, or were simplu unwilling to fix the error reporting problems.

The same can be said of KDE and Konqueror.

I'm actually working on the problems; mostly because no one else will, and some simply refuse to see the problems.

If most of the automake scripts can be replaced with compiled code, it is assured that the compiles will run 100 times faster.  With Options for the basic builds as actual files on a per distribution set of variable files, then the whole string of errors unique to each distribution can be eliminated, or, made correctible in a much more human friendly and efficient manner.

This, in turn, will reduce development time greatly, and, produce programs that both compile and work on every system.  Which is what I would think developers who spend tons of money paying programmers would want.  Perhaps they are fools for trying to achieve this.  But then again, perhaps that would save enough money to either gives raises to programmers and/or hire more programmers.  To some that may be a foolish idea, but one man's foolishness is often recognized later as true genius.  My favorite fool is Albert Einstein who was denied admission to the University of Berlin by the superbeings that ran it.  Thus, the wise supermen were confounded by the fool's atomic bomb when they and the other empire lost the great war by refusing to listen to a fool.

Fortunately for us, the Swiss in Zurich, the Americans, and the British, did listen to him.  Their reward was the world as we know it today.

Tim Berners-Lee studied at that same school, in physics, at the CERN Lab.  He's a fool too.

Dismiss thy detractors as you would dismiss a bug.

Tery, can we please see your proposed patches ?

Damn collision...

Auto* sucks, and we all know it.  The ./configure script is frequently several MB in size.  We all know this and don't deny it.
There are various projects that are attempting a rewrite to make it better.  Some are fairly close to being done, like unsermake, and various people are currently getting kde to work with it.  In fact unsermake is in cvs:

http://www.kde.me.uk/index.php?page=unsermake

Check kdenonbeta/unsermake

We all have limited time, and work on what we do best.  Being rude and insulting everyone isn't the best way to get people on your side.

Well, I must take offense at your criticism of my friend's perfect usage of VP-ellipsis, which was in accord with normal pragmatic norms of avoiding redundancy. 

Further, I am having some difficulty with your acronym and abbreviation use. First of all, what is that CERN thing? And what is W3? And what is IO? And what is Tx? Rx? These seem too different from the acronyms I see every day, such PLDI, OOPSLA, OSDI, SIGCOMM, POPL, and, of course, BOOM.

After talking it over with other, we won't be switching, but unsermake is still used by quite a few developers in kde.  Check it up.

Terry,

please get one thing straight: be specific.

We don't want a bug report telling us that everything we have done for the past 7 years is wrong and telling us to start over. If you have *any* specific complaints, make them in individual and straight-to-the-point reports.

This bug report has been closed more than once. It's not about a specific bug AT ALL. Please do not reopen it. File a new one WHEN you have something specific to report. Overly long rants are not bug reports.

"Corrections:  Peter, learn our native English language and its grammar and syntax before criticizing the knowledge of others:"

You are a twat of the finest quality. Not everybody is a native English speaker. In fact, the majority aren't.

Oh, and you mis-spelt criticising.

Now go back to our troll hole and go and annoy some other people while I travel on my hyper galaxy ventilating lift shuttle being careful that I miss the non maskable interrupts on the way.

Chris, est-ce que tu es en train de me dire quìl va falloir que j'apprène l'anglais ... merde qu'est-ce que je vais faire?  En passant, c'est probablement le bogue le plus drole que j'ai jamais vu. Terry continue ce bon travail, rire est un excellent traitement contre la dépression.

merci 

Mathieu, es tut mir leid aber ich verstehe nict. Koenen sie ein bisschen deutsch sprechen?

It doesn't matter to me that I get criticized or called names, be called "merde" or other names.  Especially when the namecallers assumed that I don't speak their language.

I didn't say everything the teams did for the last seven years was wrong, I said their was a basic misconception that was overlooked at the beginning, and this is quite a natural occurrence; we can't know everything at the beginning.  However, we can go back and fix some things.

Here are a handful of the beginnings of proposed fixes; I have to start with the way in which everything is compiled because of the numerous failures to compile for testing:  for make [it would be 'compile' in Algol] add some simple files that each distribution can create, modify, or fix when configure reports an error, these are:

PROGRAMNAME
BUILD
DISTRIBUTION
ARCHITECTURE
BINORSOURCE
VERSION
LAYOUT

Other possibilities:

OPERATINGSYSTEM
_Config.Tmpl

which I am working on to make disassembler-for-linux compile on any system.  This package requires 9 other compiles which libtool and automake totally screw up.  So I'm forced to rewrite how automake and libtool generate their files.

I need disassembler-for-linux because of a larger project and its relevance to this thread is that KDE is the slowest link in the chain.  The larger project will use every tool available, including the disassembler, to find the bogs in KDE [as well as the suggested kernel, Linux itself, and X] in order to create and/or recreate code which eliminates the bottlenecks and general out of order and/or outdated routines.

I will continue regardless of the critiques [I spelt "criticizing" in the American colloquialism form which follows the Germanic 'z' in place of 's' rather than the Samuel Johnson English form which uses 's' in most gerundatives, but spelling is not static either, except in programming, where it is critical; obviously, our coz'es need an injection of some humour enzymes].

Oh well, Big Brother is quite ticked off at me for questioning his perfect code.

When I do get the fixes for some slow stuff, I will publish, post, and use them.  By the way, trolls come from other places like Germany and perhaps Ireland, I'm just a lilaputian in a world of giants.

Sheesh, have a bitters in Picadilly and chill out dudes.

First of All I never called you a "merde" I think you should revise your French. And if you're saying that the trolls come from Germany you're insulting the majority of the kde developers. 

Just to be sure that  you're not working for nothing, are you using KDE on a 486sx25? Because if you do, you're definitly making an ass of yourself.

Stop reopening this bug report. I've told you once and I'm going to tell you again: you're ranting.

We don't care about rants. Some mailing lists accept rants and long posts. Not so here. You can go rant in your grandma's house for all we care.

If you have *bugs* to report, then we'll listen. Again: be specific. Otherwise, don't waste our time.

Terry, reopen this report one more time and find your bugs.kde.org account locked.

I am not ranting, and don't be stupid enough to pretend that the obvious anti-American sentiments are not readable either in French double-entendre or German double-entendre.

One thing I have learned here, through this discourse: if you're American and you speak with the All American sense of humor, the rest of the world, but in particular Europeans, are going to try and start a flame war to satisfy their old world aristocratic egos.

Who are you?  "Who" "are" "you" to tell me what to do?  Lock them, lock your minds as well, I really don't care.  Cheap threats don't intimidate Americans, as I'm sure you've witnessed over the last century.  And Americans that join the "other side" are called either "sympathizers" or most often "traitors."

How dare you come off highhanded with me.

Now go ahead and lock all the bugs, close your mind, and apply for a job at either Microsoft or GMBh.

Once again, you've made my point.  No one here can even discuss a problem at the academic level.  And that's simply because there's no one else here who supports Freedom Of Expression.

I'm not surprised at the jealousy.

Put this in your hat,

Educated: University of Pennsyvlvania, MIT, one-on-one tutoring, J. Presper Eckert, John Mauchly, Fred Reynard, Imperial College, London, among others.

It's incredible that you have not addressed one single problem, but have opted instead to use typical software industry personnel attacks against anyone and everyone that questions KDE, and if that doesn't sound like Apple or Microsoft or IBM, nothing does.

I no longer care about your actions as they have shown themselves to be what I have said, closed-minded.

You all remind me so much of every grad student I've ever run into that held the opinion that he was better than everyone else.

When I fix these problems, don't bother looking for the answers, you all know more than everyone else so there's really no need to bother with the little people for you.

You've proven yourselves to be just another group of non-listeners out to play psychological games with anyone who disagrees with your high opinions of yourselves.  And I am absolutely convinced that none of you knows how to apologize, nor has the manners to do so.  Which is why we don't have an Aristocracy here anymore.

I imagine you do this to everybody that comes along that you think you are better than.  Great, alienate the new people to KDE.  Close it off, close your ears and your minds, and don't allow anyone else into the inner circle.

And you really don't even see the wrong you do.

Closing one last time. Account GinEric@Musics.com has been disabled.

The show is over folks, continue to work. :-)

Sorry, but if you think this is any kind of useful bug report then you are WIDELY mistaken.

There is one thing, and one thing only, which makes a useful bug report. This applies to everybody, not just you with your oracle of engineering knowledge. In fact, I am disappointed that someone like you seems totally unable to grasp this.

--- Start recipe ---
A useful bug report contains a single specific problem and provides several simple steps to reproduce the problem so it can be isolated and fixed.
--- End recipe ---

I work on KDE in my (not very much) spare time. I DO NOT have time to wade through hundreds of lines of ranting looking for a potential bug.

And anti-American? Give me a break. If you come onto any open source bug reporting system and, as an outsider, try to tell everybody about how your amazing new programming skills are going to save KDE from doom and write large amounts of text, but produce no actual code, no one is going to give a DAMN.

Apologise? Are you trying to be funny? You are the one that has wasted everybody's time continually re-opening this bug even though you have been told numerous times that in its current state it is nothing but worthless dribble.

Nobody is denying that KDE can't be improved. You are just clueless about how to do it.

This thread proves the KDE community has too many wanks who need to get laid,  on both sides of the debate.

Terry, you just (IMO) wasted 30kb of writing, it might be clever writings but they will never bring you where you want to get. 30kb of clever code (which is about a 1000 lines) would do a much better job.

Please also consider that KDE is not the only option for you. There are many other desktop solutions for Linux available to you. FreeSoftware is about a positive upward spirit, breaking that spirit is a sin. Calling peoples project InternetExplorer is considered offensive by many.

Please be more gentle in public,
_cies.

Why am I commenting here?  I don't know but ... 

KDE does have a perception of slow screen refresh.

HOWEVER, this is not the actual screen refresh.  The problem is that something is causing a delay before the actual screen refresh occurs.

-- 
JRT

>The problem is that something is causing a delay before the actual screen refresh occurs.
Yeah, I can feel it too. I think it is just right before the bits take the last u-turn before entering the X server, they seem to slow down and wiggle against each other causing friction and thus, loss of impulse. Maybe widening the pipe might help?? ;)
ok well joke's over; this report thread really was a waste of so much time. Most shocking to see actual educated people putting all their intellectual energy into childish trolling. What a weird planet. Mankind needs one hell of a service pack..

flamebait tbh but pointful. that's why kde has ever renewed competition from gnome or xfce.