Session Menu

Bug #422052
Comment #13

Comment 13 for bug 422052

Revision history for this message

Ted Gould (ted) wrote on 2009-09-03: Re: [Bug 422052] Re: Menu should list users if fewer than 6 are on the system

#13

On Thu, 2009-09-03 at 07:17 +0000, Martin Pitt wrote:
> Ted Gould [2009-09-02 18:04 -0000]:
> > the list is users
>
> OK, we talked about that.

Yes. The list of non-users is also an issue. :) That's currently a
structure inside of GDM User Manager.

In the future, it'd probably be nice if packages could add to that
list... so the apache package could blacklist an apache user if it was
to create one. Off-topic, sorry :)

> > where their icons are
>
> Shouldn't that be a file in the user's home directory? Or where are
> they saved?

There is two places. The home directory and a global directory. I'm
not sure if anyone is using the /usr/share/faces anymore, but GDM does
support it. Also, we need to set up file watches on these to notice if
the icons change and/or get added.

> Anyway, we certainly don't need the icons in the session applet, for
> they would be much too small anyway?

Yes and no. I'm not sure if it's a requirement today, it seems to
appear and disappear from the specs :) We could probably remove it if
it was the only issue.

> > whether they are currently logged in and switching to them if they
> > are selected:
>
> All the seat information (who/where/new display/display removed/etc.)
> and opening a new login screen are already provided over D-BUS by gdm,
> switching seat to an existing user is provided by ConsoleKit's D-BUS
> API.

Yes, it is using CK. It's not a trivial task as you have to go through
all the seats and sessions, but that is possible, and already done in
the GDM User Manager.

> > And I don't believe that GDM code has any protections in place for
> > large networks, which also would need to be added.
>
> What do you mean, if there are too many users? (Isn't that why it says
> "less than 6"?)

Yes, but one of the cases here is dealing with that intelligently.
Things like getent don't really have ways of saying anything other than
going through the whole list, and they're not naturally asynchronous.
All solvable, but something that should be done once and handled by one
person in the system.

> > I'm not in any way saying that this is impossible, but we shouldn't
> > minimize the problem.
>
> Well, we should minimize it in the sense of not providing duplicate
> APIs which already exist in a better place IMHO, and even less so
> block on getting those new APIs.
>
> Since we begin to get under time pressure, I would like to understand
> what the blockers are right now, since we I'd like us to concentrate
> on resolving them as fast as possible (with Robert, or me).

Yes, of course. It's more a goal of removing code duplication. I don't
really care whether the interface/watchers/updaters are in ConsoleKit or
GDM (or whatever). I just know that today the code is already
implemented in GDM and I don't want to just copy it so that we have more
than one person going through all of this.

--Ted

On Thu, 2009-09-03 at 07:17 +0000, Martin Pitt wrote:
> Ted Gould [2009-09-02 18:04 -0000]:
> > the list is users
> 
> OK, we talked about that.

Yes.  The list of non-users is also an issue. :)  That's currently a
structure inside of GDM User Manager.

In the future, it'd probably be nice if packages could add to that
list... so the apache package could blacklist an apache user if it was
to create one.  Off-topic, sorry :)

> > where their icons are
> 
> Shouldn't that be a file in the user's home directory? Or where are
> they saved?

There is two places.  The home directory and a global directory.  I'm
not sure if anyone is using the /usr/share/faces anymore, but GDM does
support it.  Also, we need to set up file watches on these to notice if
the icons change and/or get added.

> Anyway, we certainly don't need the icons in the session applet, for
> they would be much too small anyway?

Yes and no.  I'm not sure if it's a requirement today, it seems to
appear and disappear from the specs :)  We could probably remove it if
it was the only issue.

> > whether they are currently logged in and switching to them if they
> > are selected:
> 
> All the seat information (who/where/new display/display removed/etc.)
> and opening a new login screen are already provided over D-BUS by gdm,
> switching seat to an existing user is provided by ConsoleKit's D-BUS
> API.

Yes, it is using CK.  It's not a trivial task as you have to go through
all the seats and sessions, but that is possible, and already done in
the GDM User Manager.

> > And I don't believe that GDM code has any protections in place for
> > large networks, which also would need to be added.
> 
> What do you mean, if there are too many users? (Isn't that why it says
> "less than 6"?)

> > I'm not in any way saying that this is impossible, but we shouldn't
> > minimize the problem.
> 
> Well, we should minimize it in the sense of not providing duplicate
> APIs which already exist in a better place IMHO, and even less so
> block on getting those new APIs.
> 
> Since we begin to get under time pressure, I would like to understand
> what the blockers are right now, since we I'd like us to concentrate
> on resolving them as fast as possible (with Robert, or me).

Yes, of course.  It's more a goal of removing code duplication.  I don't
really care whether the interface/watchers/updaters are in ConsoleKit or
GDM (or whatever).  I just know that today the code is already
implemented in GDM and I don't want to just copy it so that we have more
than one person going through all of this.

--Ted