From: Brian Cameron <Brian Cameron Sun COM>
> I think a better solution to this problem would be to pop-up a dialog
> asking the user if they really want to shutdown/reboot the machine.
> This is what is done on Windows if you are logged in as multiple users
> and select Shutdown, for example.
>
> It might be a bit confusing if the menu choices seem to appear and
> disappear based on whether someone is logged in via XDMCP or such.
I guess it could be configurable. Via a key in the Security section of gdm.conf
we could enforce that the power state of the machine can't be changed (if at
least one user is logged in) or it can be changed but the user is warned. It
would also be interesting to let a priviliedged user (via a password) do it
regardless of the configuration option.
> I think you aren't so much concerned in the number of users, but the
> number of displays that GDM is currently managing.
I don't see why. I could open several flexiservers but have no one logged
in. That situation should still allow anyone to turn off the machine without
warnings.
> You can tell how many displays are connected by looping over the
> "displays" variable in the daemon. Note the functionality of how
> GDM_SUP_ATTACHED_SERVERS is implemented in the gdm_handle_user_message
> function. This gdmflexiserver command does what you want.
Yes, thanks. It seems I can get the logged in users with something like:
for (li = displays; li != NULL; li = li->next) {
GdmDisplay *disp = li->data;
if (disp->logged_in)
nusers++;
}
> > We also should keep in mind what kind of users are we talking about. We can
> > distinguish between at least 3 kinds:
> >
> > 1. users that logged in such a way that gdm wasn't involved (this would require
> > reading utmp I guess)
> > 2. users that logged using gdm but remotely.
> > 3. users that logged using gdm locally.
> >
> > Dealing with just cases 2 and 3 would be OK.
>
> You probably also care about flexible servers started by gdmflexiserver
> and running on different VT's, or perhaps you are considering these the
> same as #3.
To keep things simpler I guess we can just count the number of users as I
said above, which counts all #2 + #3 users AFAICT.
Anyway, after playing with the code for most of today I was able to get the
greeter to do what I want, but still... I mean, gdm's architecture is quite
broken IMHO. Let's see, we have:
1. "Opcodes for the highly sophisticated protocol used for daemon<->greeter
communications" + interruptions (and writing and reading to FDs)
2. "primitive protocol for controlling the daemon from slave or gdmconfig or
whatnot"
3. "The user socket protocol."
Which is already too many comunication channels for the same set of apps and
still, to halt and reboot we are using _exit() and waitpid()!
I understand that gdm manages a complex task and that probably many people
already touched the code (probably implementing their own ways to communicate)
but this makes it very difficult to change anything in a sane way. I'm afraid
that gdm is badly needing a major redesign, probably using newer technologies
like dbus and hal and with a single, powerfull interface between all the
pieces. I would like to help even if I don't know much about all these APIs
yet. Are there already any plans to engage in such a task?
Rui (the wishfull thinker)
Attachment:
pgpTHCuxNcHpw.pgp
Description: PGP signature