On Friday, May 25, 2012 11:14:17 Dominik Haumann wrote: > On [1], the Kent Hansen says:
ime, Kent tends to be focused on the better future rather than the pragmatic present while tending to ignore use cases that his team doesn't have themselves. this can make using things that comes from his team at times rather difficult. we've gone through these sorts of issues a couple times already in the past. (i love his excuse for not including a QScriptContext style API in QJS, given that it is indeed highly useful: "it's an implementation detail". it is never useful to be able to introspect into the call stack, right? *sigh* QScriptContext itself does expose too many implementation details, but the idea of QScriptContext is rather good. it would be nice to see it conceptually improved rather than dumped becase of problems with the current implementation.) i find that usually pressing the issue, reiterating the use cases, finding others with the use cases and producing patches (ignoring the "we might not even accept changes" sillyness) tends to help. there's no reason to throw the baby out with the bathwater here, and improving QtScript rather than rebuilding (and all the testing that comes with it) the JS support in numerous KDE applications is rather more sensible imho. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.