On October 6, 2009, Aleix Pol wrote: > Well, depends a lot on how odd it is, you could install it within kdeedu > the same way we do with the kalgebra plasmoid. There's no odd dependency > crossing here.
the problem would be that we would then have two calculation plugins: one in kdebase (because a calculator isn't really optional in krunner) and one in kdeedu. we'd either need to ship both together (which means kdebase) or we need to provide a way for one plugin to automatically deactivate another. that would probably mean implementing a category system for specific types of functionality for which only one plugin should be active for (e.g. "Calculator") and a ranking system as we have with KTrader (so the kalgebra runner could install at a higher rank than the default qscript one). before we go through all that trouble: is is there a way we can use KAlgebra from multiple threads without problems? it's perfectly fine to instantiate some state object(s) in each call to AbstractRunner::match, but they need to either not have any shared data with other classes (which may contain code executed in a different thread) or be thread safe. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
