Alan Coopersmith wrote: > Shane O'Connor wrote: > >> I think the important think (and the point Bob was making) is to have >> the same experience with both dtlogin and gdm > > > That's only possible by crippling gdm or putting a lot more effort into > dtlogin, but why?
No. My point was *configurability*. I believe Brian stated that gdm is configurable today to give the same "experience" as dtlogin wrt the shutdown/reboot options. So no work is required for gdm. My question is what should be the default, and how can it be altered with minimal system impact and minimal risk of stepping on customer/site configurations? My suggestion was the simple addition of an "#include" directive in the gdm.conf file to accomplish this, similar to what dtlogin allows for customizations of Xresources. That's presumably a minor modification to gdm to allow better system configurability. An example may help make this more concrete. Today, with dtlogin, if we need to disable the Remote Login Option at some point in the authentication process (for session mobility reasons) we can do so by configuring dtlogin to use our own Xresources file for the display/session, which can look like this: Dtlogin*remote_host_menu*sensitive: False #include "Xresources" By doing this we don't have to touch any user configuration and we are not touching files that might be clobbered by patches/upgrades in future. Sites can even override this option in /etc/dt/config/Xresources. Note that SRSS has no requirement to do this sort of thing in the current release, but we do need to do something similar to this in a future release to accommodate changes to the NSCM login architecture. I'm recently begun talking to Brian about it. -Bob
