KWallet plugin logic implementation inside frameworks
Valentin Rusu
kde at rusu.info
Wed Nov 21 19:30:46 UTC 2012
On 11/21/2012 01:28 PM, David Faure wrote:
>> Second issue (and proposal): where should go the kwalletdefaultplugin?
>>
>> This plugin actually contains the old KWallet API implementation, the
>> one which calls the kwalletd.
>> I think the best place for kwalletdefaultplugin should be
>> kde-runtime/kwalletd. This way, this plugin will get installed at the
>> same time as the daemon it communicates with.
> In a different subdirectory of the same framework, as Jon said.
>
> If the plugin doesn't exist in 4.x, then there's no merging issue,
> though, you
> can put it in the framework already.
> He's right about the existing kde-runtime code though, it would be
> best not to
> touch that one yet. I guess this might make it difficult for you to
> test the
> whole thing, though... Unless the daemon is mostly unchanged, for now?
>
The daemon *will* stay unchanged. There's no need for touching it.
Letting it where it is will not prevent me to test the plug-in logic,
especially the "daemon not found" case
--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)
More information about the Kde-frameworks-devel
mailing list