Hi, Hope I've succeeded in disarming my initial draft. Hope this mail just illustrates my concerns. I am upset: There are no GDM themes anymore? Are there screenshots of the new GDM? I'd absolutely hate it to be greeted by some gray and boring login screen. Seriously. To my uninformed knowledge the only new features of the new GDM are: * some D-BUS API * pretty GObject based code * accessibility First two features only serve the maintainer, third feature just a minority. So I wonder why I should be excited about the new GDM. Which of your changes makes it worth to accept such a massive regression like loss of customization? IMHO it is a big miss-perception that only geeks customize their desktop. Expect for office and geek desktops I've seen only few non-customized desktops. Also I wonder every distribution ships custom GDM themes, when customization of the login theme is unimportant? Ciao, Mathias Am Donnerstag, den 04.09.2008, 14:10 -0500 schrieb Brian Cameron: > Andre: > > This question seems to have created a lot of FUD, and I wanted to try > and give a more clear perspective on the situation. As the maintainer > of GDM for the past several years, I feel I have a good understanding > of the needs of GDM users, and what will cause issues. > > First of all, I don't think that the loss of gdmgreeter or the GDM > themes is a real issue. Some users will find it annoying that their > favorite theme can't be used, but if there is enough interest in > supporting such themes long-term, then we can imagine such users will > push for it to be rewritten to use the new infrastructure. This > probably isn't a huge amount of work. The old greeter just needs to > be updated to use a different IPC mechanism. However, there are > a few design issues that probably would need to be considered. Session > and language choosing has changed in the new GDM, so it might make > sense to revamp things like this when porting the old greeter. Also > making it GObjectified is perhaps a bit of effort. Users who really > love the old theming can probably just continue using GDM 2.20 if they > want. Such users probably are geeky and would know how to replace or > rebuild a module. > > Secondly, I do not think the loss of gdmsetup is that big of a deal. > Most configuration options in GDM can now be configured via > gconf-editor. There are still a few daemon configuration options in > /etc/gdm/custom.conf, but not the ones users typically want to modify > (except for perhaps automatic/timed login). I think that people can > probably live with using gconf-editor and their favorite ASCII file > editor for updating the configuration for now. The old gdmsetup > program had a real security flaw in that it needed root permissions > to run. It would be better if the GUI ran as the "gdm" user. So > it needs a rewrite anyway. > > That said, I think the two issues that are of real concern are the > fact that the new GDM does not support managing multiple displays > when each display has its own graphic card. The second issue is > that you can't run the XDMCP chooser from the login GUI. > > The need to manage multiple displays is commonly used in terminal server > environments. Distros who want to support terminal server setups out of > the box simply can't consider the new GDM. It is probably reasonable to > expect this regression could be fixed by GDM 2.26. At any rate, until > it is fixed some distros, like Sun, will not be able to include the new > GDM. I imagine some other distros that need to support terminal server > environments will likewise stick with GDM 2.20 until this regression is > addressed. Since this is an important feature for many users, I can't > imagine this regression will be broken for long. > > Users who want to be on the bleeding edge could try to support multiple > server environments using the GDM patch that makes gdmdynamic work with > the new GDM: > > http://bugzilla.gnome.org/show_bug.cgi?id=536355 > > Using GDM built with this patch, you could add multiple displays > via scripting rather than hardcoding the displays in the configuration > file. Using this sort of technique, you could do some interesting > things, like if HAL detects a hotplugged display, you can manage or > unmanage the display on the fly by just calling gdmdynamic. > > The fact that you can not run the XDMCP chooser from the login GUI > anymore is the other problem. That said, XDMCP is crufty and insecure, > so it might be reasonable to take the stance that it is now a second > class citizen and regressions are okay in this area. However, I believe > there are enough XDMCP users out there that I also can't imagine this > regression will be broken for long. > > I am not aware of any other regressions that I think are particularly > serious. Now that the documentation is mostly put together, and > there is some reasonable configuration migration support since the > new GDM still supports the /etc/gdm/custom.conf file for options > which make sense; I think GDM is in much better shape than it was > a few weeks ago. > > While these are just my opinions, I think that it is reasonable for > the release team to bless the new GDM with the understanding that > some distros won't update until some of the more important regressions > are addressed. The new GDM is appropriate for use on distros where > the intended audience isn't likely to want to run complicated setups > like terminal servers. Most distros that ship the new GDM would likely > also make available RPM's/binaries/whatever for the old GDM, so that > users who have such needs can backport to the old GDM for these > regressed features. > > Or, I could also understand if the release team felt that GDM needs > a bit more polish before its ready to go out the door. I would think > another release cycle would get us that much closer to addressing the > more serious regressions. > > It's really the release team's decision at this point. I don't think > there is enough time to address these remaining regressions in this > release cycle. The design considerations regarding how ConsoleKit > and GDM should interact regarding supporting multiple displays hasn't > been figured out in enough detail yet. > > Brian > > > > the release-team normally asks on d-d-l for comments on new modules and > > dependencies. > > In this case I'd like to ask for valuable feedback on gdm trunk. > > > > Among the release-team there are different opinions whether to use trunk > > or 2.20.x for GNOME 2.24 and hence different opinions on regressions > > (and the definition of that term) and missing or rewritten > > functionality. > > As far as I know, Fedora and Foresight ship trunk, while Ubuntu and > > Mandriva tend to ship 2.20.x. Opensuse releases in December so no real > > use in asking them. No idea about Debian. > > > > Don't know if providing links to former discussion threads might > > influence opinions. Feel free to ignore these links and to share your > > own non-influenced experience instead: > > http://mail.gnome.org/archives/release-team/2008-August/msg00021.html > > http://mail.gnome.org/archives/gdm-list/2008-July/msg00028.html > > http://mail.gnome.org/archives/release-team/2008-August/msg00072.html > > > > We'd like to have a decision made by this weekend so there's two weeks > > left for translators. Comments highly welcome, so you can't blame > > release-team only in the end. ;-) > > > > andre > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Mathias Hasselmann <mathias hasselmann gmx de> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil