extragear/sdk/kdevelop/app

[David Nolden]

2010/4/18 Andreas Pakulat <apaku at gmx.de>:
> On 18.04.10 11:29:31, David Nolden wrote:
>> The lock within notify only "locks" within the main thread (that's the
>> expression within the parens), and since the lock is recursive, this cannot
>> lead to a deadlock.
>
> Just changed that to not use a global static (yet again). But my
> question was not wether it can or can not, but wether you tested it? The
> other thing is that the lock adds useless code which has 0 benefit over
> the non-lock version unless you start adding code into the background
> thread that uses it. And that must not happen for 4.0.0 (and IMHO also not
> for 4.0.x)
I tested it in the sense that KDevelop still works, yes. But now that
we have it, we might start using it to fix specific bugs. I don't get
why it should be more dangerous than any other way of fixing a bug, as
any change is at first "untested". Then you test it, and if it works,
it's fine.

However, if we only want KDevelop to work with kdelibs 4.4, I guess we
don't need the lock (yet), and can also revert it. Generally, given
all the changes that seem to be going on in kate, I think we should
completely disallow the startup of KDevelop 4.0 together with kdelibs
4.5.X, as I'm pretty sure it will be a sub-par experience. We can tell
the user to update KDevelop, as we may suppoert kdelibs 4.5.x in a
later release. Else we'll get tons of bug-reports because of kdevelop
+ KDE 4.5 bugs.