wilderjds/kwin - kwin - gitea-jacopods

Author	SHA1	Message	Date
Martin Gräßlin	b0e892e359	[kwin] Add a new EffectLoader The EffectLoader is a subclass of AbstractEffectLoader delegating all methods to instances of: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader It's used by the EffectsHandlerImpl and replaces the complete Effect loading mechanism we so far found in it. This also means that KLibrary is no longer needed to load the Effects as the PluginEffectLoader uses the KPluginTrader, which removes lots of deprecated functionality. REVIEW: 117054	12 years ago
Martin Gräßlin	6622c97601	[kwin] Add a PluginEffectLoader This is a specialized subclass of AbstractEffectLoader to load binary effect plugins. It used the KPluginTrader to find all candidates to load. The loader is able to detect incorrect ABI versions through the pluginVersion() and uses the methods exposed by the new KWin::EffectPluginFactory to check whether the Effect is supported and should be enabled by default. The unit test for this loader comes with two plugins: one is able to be loaded and provides a supported and enabledByDefault method which can be tweaked during the test to get all the conditions we want to test for. The second plugin uses an incorrect plugin version and thus cannot get loaded.	12 years ago
Martin Gräßlin	42ff5e0c08	[kwin] Move finding of scripted effect source file to ScriptedEffect New ScriptedEffect::create(KService::Ptr). This is a preparation for adding the ordering directly to the Effect.	12 years ago
Martin Gräßlin	ba12fe3cc0	[kwin] Add a ScriptedEffectLoader This implementation of the AbstractEffectLoader is able to to load the scripted KWin Effects. It uses KServiceTypeTrader to find all the candidates to load.	12 years ago
Martin Gräßlin	0fd9a1eeee	[kwin] Introduce a new Effect Loading mechanism Effect loading gets split by the kind of effects KWin supports: * Built-In Effects * Scripted Effects * Binary Plugin Effects For this a new AbstractEffectLoader is added which will have several sub-classes: * BuiltInEffectLoader * ScriptedEffectLoader * PluginEffectLoader * EffectLoader The EffectLoader will be what the EffectsHandlerImpl is using and it just delegates to the three other types of loaders. Thus the handler doesn't need to care about the different kinds of effects. The loading is supposed to be completely async and the EffectLoader emits a signal whenever an Effect got loaded. The EffectsHandlerImpl is supposed to connect to this signal and insert it into its own Effect management. Unloading is not performed by the loader, but by the EffectsHandler. There is one important change which needs to be implemented: the ordering cannot be provided by the loader and thus needs to be added to the Effects directly. So far only the BuiltInEffectsLoader is implemented. It's not yet integrated into the EffectsHandlerImpl, but a unit test is added which tries to perform the various operations provided by the loader and the BuiltInEffects. The test should cover all cases except the Check Default functionality which is only used by Blur and Contrast effects. This cannot be mocked yet as the GLPlatform doesn't allow mocking yet.	12 years ago