[LightDM] [PATCHES] Multiple prompts in a single PAM conversation round

[Christian Seiler]

Hi,

> You shouldn't strictly need the signal to handle multiple prompts - you
> just append a new prompt each time liblightdm-gobject generates a signal
> and remove them all when you have responded to all the prompts. (This is
> what Unity Greeter does). A group of prompts is guaranteed to be signalled
> in a row in the same thread.

I just looked at the Unity greeter and yes, if you do it like that, i.e.
always generating the prompts dynamically like that, then you don't need
that signal. But if you want to display the prompts sequentially, as the
current GTK greeter does, then I'm not sure whether you can be sure that
will work properly in all cases.

> It doesn't seem like a bad idea to add the signal for "end of prompts"
> though if that helps greeters to implement multiple prompts.

That's why I was adding that.

> Ideally we
> wouldn't need it and the API would have been designed to handle multiple
> prompts properly - that was a design mistake I made early on*.
> *And a good case for fixing with an API break in the future.

I played around with that a bit locally before writing to this by
passing a GSList (of the same struct I use in the GTK greeter now) in
the GObject bindings and a QList in the Qt bindings. (As an additional
signal compared to the previous ones.) The problem here is that as far
as I can tell, it's non-trivial to pass these kinds of data structures
in both frameworks: in glib you seem to have to declare the signal
argument to be a gpointer (at least that's what Google told me, I've
never done anything with glib before), which doesn't seem to be quite
right to me (although it works). And in Qt you have to do some meta-type
registration. (And I haven't found a sane way to make it possible for
the Qt signal to be connected to a slot in QML, which is what the KDE
greeter uses...)

Maybe one could just store the current list of prompts in the greeter
object itself and then provide a) an accessor to that structure and b) a
signal that a new set of prompts has arrived.

> If you do
> use the signal note that the greeters will need to depend on the latest
> lightdm - this may delay distribution.

For this reason my GTK greeter patch detects whether this signal exists
(also at run time!), so that deploying it against an old version of
liblightdm-gobject isn't be a problem. Just that it doesn't support
multiple prompts in that case.

Anyway, for now I have adjusted the commit message (since you showed me
that it isn't absolutely *required* to have that signal for multiple
prompts to work) to better reflect what the patch does and submitted a
merge request as you told me to in your email.

Regards,
Christian