Bug 378814 - Consider switching to the GSignond stack
Summary: Consider switching to the GSignond stack
Status: REPORTED
Alias: None
Product: KAccounts
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Иван Туманов
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-15 14:45 UTC by Corentin Noël
Modified: 2023-03-29 18:46 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
kde: Backport-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Corentin Noël 2017-04-15 14:45:52 UTC
Hi there,
I'm Corentin Noël, responsible of the Online Accounts integration at elementary.
Since a few years now, we are using the GSignond daemon on elementary, a GLib-based alternative of the Signond daemon as we are not willing to introduce a Qt dependency on our system just for one daemon.
Signond has been mainly developed by Canonical for Ubuntu, with the recent Unity events, the developers of Signond have been laid-off.

You seem to be the last desktop environment that still use Signond, and I think that it would be a better idea to switch to GSignond.
The switch can be really easy for you, both are very compatible, you mainly just have to use the libgsignond library instead of libsignond on the daemon-plugins side, and use libgsignon-glib instead of libsignon-glib.

I'm open to changes on any side and would be very pleased to have more cooperation with you on Online Accounts integration.
Comment 1 Martin Klapetek 2017-04-15 19:56:45 UTC
Hey Corentin,

thanks for getting in touch!

I think we're pretty much in the same boat but opposite
streams - we'd prefer to keep using the Qt daemon and Qt
libraries, rather. For us it's much easier to work with
and also fix bugs in a Qt codebase, which is our primary
language after all.

I agree that the Canonical situation is a very unfortunate
one but given that the Qt daemon is working well for our
needs, I don't really see the need to switch techs.

My understanding is that GSignond is not actually compatible
with the Signond, is that correct? If that's the case, I would
really wish that these two are brought together more closer,
to be compatible and interchangeable. Then we could both keep
our native daemons while having fully cross-desktop accounts.
Comment 2 Corentin Noël 2017-04-15 20:03:42 UTC
Of course that's another possibility, as the libsignon library is talking to the daemon with D-Bus it should be possible to have two existing Daemons (Qt and GLib).
From what I've heard the two projects have diverged regarding this D-Bus API and thus are not really interchangeable right now. It would be great to be able to move toward a common D-Bus API though. My main reasoning was to reduce the amount of duplicate effort, so it's also possible to just keep libsignon-glib but try to make the two daemons compatible, this might require changes in both sides but at least one library get removed (libgsignon-glib in this case).
Comment 3 Martin Klapetek 2017-04-15 20:09:10 UTC
> It would be great to be able to move toward a common D-Bus API though.

I'd be happy to try and help out with that (though my time is
quite limited).

We can't really get rid of the Qt libs though because we need
a Qt layer on top to be able to use it in a sensible way from
our KDE/Qt apps.
Comment 4 Corentin Noël 2017-04-15 20:13:48 UTC
One other possibility is to have:
 * libgsignon : GLib library to integrate with a Signon daemon
 * libsignon : Qt library equivalent
Both talking to the same daemon (so that GLib apps and Qt apps can share the credentials)

I don't know if you're using libsignon-glib right now, I've seen a libsignon-qt but can't locale the source anywhere and it's not referenced in your wiki too.
Comment 5 Corentin Noël 2017-04-15 20:14:29 UTC
I'm `tintou` on #accounts-sso in freenode if you want to talk directly
Comment 6 Иван Туманов 2019-04-21 01:49:38 UTC Comment hidden (spam)
Comment 7 Иван Туманов 2019-04-21 01:50:24 UTC Comment hidden (spam)