branches/kdevelop/3.4/src

[Jens Dagerbo]

On Friday 15 September 2006 22:27, David Nolden wrote:
> Am Donnerstag, 14. September 2006 20:14 schrieb David Nolden:
> > Seems to be working good.
> >
> > greetings, David
>
> Is anyone else experiencing the problem that this patch causes kdevelop to
> get slower and slower, and hog 100% CPU-Time after some time? I first
> thought it was something with my navigation-menu, but after some debugging
> and disabling this patch, the behavior stopped.
> When I was debugging I saw that Qt spent all the CPU-Time while walking
> through some internal lists, dispatching timer-events or something.
>
> Maybe something calls setLineNumber way too often.. or a Qt-bug?
>

Since the patch actually goes in a "loop" until it has managed to set the line 
number, I would be surprised if it isn't possible to get it to misbehave.

I haven't been able to make it cause any noticeable slowdowns, but it didn't 
take long to come up with a usecase that makes it crash KDevelop. (While it 
is looping, unload one of the documents it is trying to set the cursor on.)

Other issues: 
We have a method called "setLineNumber" - where would you expect the cursor to 
be after this call? Clearly unexpected behaviour.
Also, since the problem is actually the setCursorPositionReal() call and we 
use that directly elsewhere in the code we would have to come up with a 
solution here as well.

What is the fix in the Kate code, btw? If it's this "loop fix" there as well I 
think this is really dangerous.


A third party extension to Qt is making katepart crash, which makes KDevelop 
crash. Trying to paper over this in KDevelop is the wrong fix. It stinks that 
this bug has been around for 2 years now, but I don't think that is a good 
enough reason to introduce problems and bugs (which this patch does, even if 
it also helps) where it isn't needed. (Don't have the XIM patch? Don't need 
the fix, dont' want the bugs.)

I wish I could offer a solution though. Is anyone up to fixing the XIM 
patch? :(

// jens