Re: [gdm-list] GDM trunk will be used for GNOME 2.24.

[Brian Cameron <Brian Cameron Sun COM>]

Peter:

Agreed.  The solution you suggest is in the works.  By solving the
problem in gnome-settings-daemon, the solution should work the same
way in both the GNOME session and in GDM, so it will be a huge
improvement over what existed before (a GDM-only solution which was
typically turned off by default, and even when turned on it would
leave the user unable to use their session after navigating the login
screen without additional manual configuration).

Brian


> Gil - while Brian cites some specific problems with having all assistive 
> technologies running always by default (especially on new or public 
> systems), the basic concept behind your suggestion is very valid.
> For example, you don't have StickyKeys turned on by default (where a 
> single press of the shift or other modifiers starts out being sticky), 
> but you do have keyboard accessibility support turned on by default and 
> the system sensing that five presses of the shift key in sequence (with 
> nothing else pressed in between) interpreted as a signal to turn 
> StickyKeys on.  Gamers who find this interferes with their game play 
> turn this feature off.  Similarly SlowKeys sensing is turned on while 
> the feature is off (and a Shift key held for 8 seconds turns SlowKeys 
> on; again something gamers/graphic designers may then turn off for their 
> sessions).
>
> Applying that approach to your suggestion, we would have as on by default:
> - the Assistive Technology support libraries
> - well known/publicized gesture listeners ready to turn various AT apps on
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect & Principal Engineer,
> Sun Microsystems, Inc.
>
>
> > Gil:
> >
> > > Just thinking about it ...
> > >
> > > Wouldn't it be reasonable to enable everything the first time the user
> > > logs in and the if no accessible technology has been used ask if they
> > > have to be turned off by default (and with a little explain about how to
> > > re-enable them)?
> >
> > From a usability standpoint, starting GDM with the magnifier by default
> > would probably make it hard to use for people who don't need to use
> > the magnifier.
> >
> > Also, this sort of solution wouldn't work well in situations where
> > multiple users use the same machine.  Some users may need AT programs
> > while other users may not.  So, it would be problematic if the first
> > user said "No, I don't need them", and messed up the login process for
> > the next user who does.
> >
> > Brian
> >
> >
> > > El dl 22 de 09 de 2008 a les 10:31 -0700, en/na Peter Korn va escriure:
> > > > Brian, all,
> > > >
> > > > Do we have a "chicken-and-egg" situation here?  Why do all that is 
> > > > necessary in GDM if we don't yet feel that accessibility on the 
> > > > desktop is sufficiently stable to have it on by default from the 
> > > > GNOME community? (so goes one argument)  At the same time, if we 
> > > > aren't quite there yet in login, then we need system administration 
> > > > help to set up the initial login, so we can have system 
> > > > administration help to turn it on at the desktop (and leave that 
> > > > problem unfixed until later).  Lather-rinse-repeat.
> > > >
> > > > Meanwhile some distros are leapfrogging GNOME & the core community 
> > > > that introduced accessibility and made it a core value by enabling 
> > > > users to turn accessibility on with a gesture in their LiveCD, and 
> > > > then the installation process turns it on for that user on the 
> > > > desktop.  But this is a hack.  And users don't have the experience 
> > > > of full and independent accessibility in GNOME; they rather instead 
> > > > have it (and have it differently) in some distros.
> > > >
> > > > We should fix this.  And component by component, we shouldn't play a 
> > > > game of chicken, insisting that some other component fix it first.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Peter Korn
> > > > Accessibility Architect & Principal Engineer,
> > > > Sun Microsystems, Inc.
> > > >
> > > >
> > > > > Will:
> > > > >
> > > > > > While I disagree with Brian's assessment (I think he tends to lean 
> > > > > > more to the 'it's OK as long as an able-bodied sysadmin can 
> > > > > > configure the system for the disabled user' side than the 'let the 
> > > > > > user be independent' side), I'll support the decision nonetheless.
> > > > > I agree with you that "let the user be independent" is best.  However,
> > > > > I was just highlighting that GDM's a11y has never matured to the point
> > > > > where it was turned on by default (much like the situation with the 
> > > > > rest
> > > > > of GNOME not having a11y turned on by default).
> > > > >
> > > > > Therefore, I was just highlighting that the new GDM is pretty much
> > > > > as good as the old GDM in terms of a11y.  The main area of regression
> > > > > is that you can not launch a11y on-demand when a11y is turned on.
> > > > >
> > > > > The ability to launch a11y on demand is really only useful if the
> > > > > GNOME desktop also supports this feature (which it currently doesn't).
> > > > > Being able to navigate the login screen independently is not very
> > > > > useful if you still need someone to help you set up your user
> > > > > session.  Another use case where the "on-demand launching" feature is
> > > > > useful is in terminal server situations where many users may be
> > > > > sharing the same server.  However, the new GDM doesn't support that
> > > > > anyway, and the release team seems okay with that.  So I don't think
> > > > > these a11y issues are a real blocker.
> > > > >
> > > > > This is why the long term goal is to make a11y "on-demand" launching
> > > > > a part of gnome-settings-daemon so it works the same in both GDM and
> > > > > the user session.  Then I think we will have gotten to the point where
> > > > > we all have been pushing to get.
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > > > Vincent Untz wrote:
> > > > > > > Le lundi 22 septembre 2008, à 09:46 -0400, Matthias Clasen a écrit :
> > > > > > > > On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper <ak-47 gmx net> 
> > > > > > > > wrote:
> > > > > > > > > The release-team is going to use gdm trunk for GNOME 2.24.
> > > > > > > > >
> > > > > > > > > Note that most release-team members have mixed feelings.
> > > > > > > > > Entire discussion would have been less frustrating if gdm 
> > > > > > > > > developers had
> > > > > > > > > been more responsible to the concerns shared in discussions. 
> > > > > > > > > Maybe just
> > > > > > > > > my point of view.
> > > > > > > > >
> > > > > > > > > Translations of gdm trunk are in a good shape.
> > > > > > > > >
> > > > > > > > > Distributors: Old gdm is still available in case you hit a 
> > > > > > > > > regression.
> > > > > > > > I'm surprised by this turn of events, after Vincent decreed that 
> > > > > > > > we'd
> > > > > > > > go with 2.20 on Friday...
> > > > > > > See
> > > > > > > http://mail.gnome.org/archives/release-team/2008-September/msg00251.html 
> > > > > > >
> > > > > > >
> > > > > > > Vincent
> > > > > > _______________________________________________
> > > > > > gdm-list mailing list
> > > > > > gdm-list gnome org
> > > > > > http://mail.gnome.org/mailman/listinfo/gdm-list
> > > > > _______________________________________________
> > > > > desktop-devel-list mailing list
> > > > > desktop-devel-list gnome org
> > > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > > > _______________________________________________
> > > > gnome-i18n mailing list
> > > > gnome-i18n gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list