freedesktop.org single sign-on project
lemma at confuego.org
Fri Oct 3 07:53:50 BST 2008
On Friday 03 October 2008, Aaron J. Seigo wrote:
> > What do you think about the general itinerary I should take? Do you think
> > adopting keyring is a "no-go" or a valid option once certain
> > circumstances are met?
> which certain circumstances are you thinkg about?
Pretty much the same you brought up:
* KDE interface
* integrates smoothly (GUI parts)
* probably ask them to strip GNOME out of the name :)
* possibility to provide binary compatibility with applications using the
wallet interface (so we don't have to provide 2 daemons as long as KDE4 is
> > Personally I think having a common daemon should be the way to go. I
> > wouldn't object to keyring and I'd even help working on it and getting it
> > to where we need it.
> what dependencies does it bring other than glib when built from source?
> what dependencies does it bring other than glib when installed from binary
> packages on major distributions?
According to configure.in it looks for:
- glib (gthread, gobject, gio)
- gtk for the gui part asking for the password (this is an askpass binary of
- pam (for a pam module auto-unlocking the wallet on login)
Some of those dependencies are optional. I'm also not proposing to jump at it
right away. I have some features I'd like implemented first (like being able
to unlock the wallet with a smartcard or a fingerprint). I'm also not 100%
sure if everything will work out fine. But trying to work it out will be more
comforting if I know if anyone really wants the results.
> > I am however concerned about the hit-by-a-bus factor
> > (KDE-wise)
> do you know how many people work on the daemon currently?
According to what I know and commit logs I'd say 2 or 3 working actively.
> > and the fact that it might be hard to gather people to code on
> > it in KDE as it's written in C/glib and unrelated to Qt.
> yes, you can count on very few people being interested ... but it's not
> like everyone has piled onto kwallet either, right? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel