Bob: > 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?
Yes, this is why I changed the default to "false" so these do not appear. Setting this to "true" would change user's experience on Solaris. But this would make Solaris different than other Linux distros. I'll leave it up to the UI Spec people to decide which approach makes the most sense as a default. > 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. I'm happy to work with you to enhance GDM to support the sort of configuration you need. However I'll need to understand your requirements a bit more to know if an "#include" directive is the best approach. Brian > 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 >
