Re: [gdm-list] List of useful GDM features/config options
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: gdm-list gnome org
- Subject: Re: [gdm-list] List of useful GDM features/config options
- Date: Tue, 29 Jan 2008 22:45:35 -0600
Matthias:
Not to be a party pooper, but I don't believe listing everyone
favourite options is going to be very effective. Every existing
option will have at least one proponent who says 'probably desirable'.
I think Hans and myself were highlight configuration options that
point to such clearly needed use cases.
Frankly, a lot of the options
in the current gdm configuration look like they happened that way...
Agreed. I believe the ones Hans and myself did not highlight
are these options. Though there is some room for debate, of course.
In short, I think the following use cases were highlighted:
- AutoLogin/TimedLogin for single and/or multiple displays
- XDMCP configuration
- Accessibility. Probably need the ability to configure
whether the ability to launch AT programs is on or off by
default.
- Init, PostLogin, PreSession, PostSession script hooks.
- Ability to configure GDM user/group/path/rootpath. I think this
just gives the sysadmin reasonable control over their system
- Ability to configure Xserver command for different displays
- Ability to specify commands used for various commands (e.g.
halt, reboot, shutdown)
- Ability to turn off face browser
- Ability to configure RetryDelay
- Configuration migration
What I'd like to see is discussed is the use cases that are supported
by the current options. Once we have an idea what those are, we can
look at the amount and kind of configurability that is needed for them.
In some cases, it may make more sense to move the configurability to
some other place. E.g. seat configuration will probably make more
sense
in ConsoleKit. And with Reboot/Shutdown being offered as a service
by ConsoleKit or hal, there is little reason for gdm to have its own
knobs for configuring that.
Oh, I agree. If it makes sense for a configuration option to move
to another component, then we should do that. That said, configuration
migration becomes more complicated if the options move all over the
place.
Brian
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]