Hello, On Monday, 11 July 2016 21:58:34 CEST Thomas Pfeiffer wrote: > On 07.07.2016 19:50, Kevin Ottens wrote: > > There's two sides to that problem in fact, use from applications and the > > service provided by our workspace. > > > > I think that for applications the answer is neither KSecretService nor > > KWallet, etc. For the goal of making it easier for our applications to be > > shipped on more platforms, what we want in fact is to port them away from > > anything platform specific to something like QtKeyChain: > > https://inqlude.org/libraries/qtkeychain.html > > > > This way, the actual storage becomes a workspace decision. That could keep > > being KWallet if improved, or KSecretService, or a simple D-Bus service > > wrapping libsecret... For sure it would at least simplify things on the > > KWallet/KSecretService side, they wouldn't need to be frameworks anymore > > (QtKeyChain or equivalent would play that role) just to expose a D-Bus API > > (likely the Secret Service one in the end). > > Oh, indeed, that would absolutely make sense! Deploying and using > applications which use KWallet outside of Plasma must be a pain right now.
Never tried, but I'd suspect it is indeed. > So how do we make that happen? Deprecate the KWallet framework and recommend > to use QtKeyChain instead, and then in parallel decide which bakcend to use > for QtKeyChain in Plasma? Probably something like that yes. Note that I'm not sure how active the QtKeyChain project is right now, so that might be something to evaluate I guess. > >> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secre > >> ts-> api-0.1.html> > > 0.1 being outdated, you probably want to link that one: > > https://standards.freedesktop.org/secret-service/ > > Ah yes, indeed. > > > Hope that somewhat made sense and helps. > > It made sense to me at least :) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
