Hi I presume that DBus is not launched early enough to act as a transport mechanisum? I wonder if into these current discussions thought should also be made too to other desktop environments? If DBus is launched at GDM, then buy using this we aren't setting up yet another hash to achieve a result.
As a end user, I would like all the work I've done to setup accessible GDM to be carried over to the desktop, thereby giving me accessibility straight away from first log in. I may have need to then add additional refinements to my session profile that I may not want in GDM. For instance as a visually impaired user, I would want Orca to speak to me whilst I'm navigating around the log in screen, but once into the actual desktop I may want high contrast theme with magnification as well as speech. So, I believe what is needed is a damen that gets launched as part of the Gnome startup, which will receive from GDM the AT data. It will then look at the user's Session profile, and if no AT is selected it will instigate the same AT as the GDM had. If the user has set up further preferences, like in the scenario above, it will then dump the GDM data and let the normal startup work. >From a software viewpoint, maybe when GDM launches the session, it does so with a particular flag set. As the session starts if this flag is set it will then launch the damon which will either accept the data from GDM over DBus, or access the GDM profile, if it sees that that user has no AT set in their profile already. Otherwise, it will shutdown. Ian -----Original Message----- From: gnome-accessibility-list-boun...@gnome.org [mailto:gnome-accessibility-list-boun...@gnome.org]on Behalf Of Francesco Fumanti Sent: 04 November 2009 17:03 To: Willie Walker Cc: Jon McCann; gnome-accessibility-list@gnome.org; Brian Cameron Subject: Re: Carrying over ATs from GDM to GNOME session (brainstorm) Hi, Willie Walker wrote: >>> An issue which the carry over solution would solve is the very >>> awkward method by which a11y needs to be enabled for the desktop. >>> Unlike gdm, which will have a11y enabled by default, the user session >>> has a11y disabled by default. So, if you can get an AT running >>> during an inaccessible session, you really need to hope that the AT >>> sets the a11y gconf flag and offers you with the ability to log out. >> >> It makes 100% sense to me for the setting of >> /desktop/gnome/interface/accessibility to carry over to the user >> session. If the user launched an AT program in the login program, then >> it would make sense for GDM to just go ahead and set this key for the >> user session before starting it, for example. > > This would be a big plus. The existing login/set_a11y/logout/login > process is reasonable, but certainly not compelling. +1 >>> The carry over would help ensure that the a11y gconf flag is set for >>> the user if it is needed, making the user session accessible. >>> Imagine also that I needed high contrast large print inverse to log >>> in. It sure seems awkward to have to go through the theme selection >>> process all over again once I login. I think the carry over solution >>> would be a much more pleasant out of the box experience. >> >> Right. Although, providing keybindings and mouse dwell gestures to set >> the a11y theme also seems a reasonable solution to avoid this sort of >> setup. > > I'd like to shoot for the star that says "Compelling" on it rather than > "Reasonable". "Reasonable" usually ends up meaning "the minimal > compromise we make to push a clunky solution." I think we need to hear > more from our end users about what they think would be compelling. Indeed, I am not a friend of mouse gestures to start the onscreen keyboard during GDM. Do we want to provide a solution only for the users that are initiated, or do we also want to make it accessible for new users? (I don't expect the average user to go and search for documentation; and the help system shipped with the installation is not usable for a user needing assistive tools until he has solved his accessibility problem.) From the point of view of a pointer user: In GDM 2.28.x (probably also 2.26.x) it is possible to find out only by looking at the screen that assistive tools are available, because of the accessibility icon. Moreover, due to the accessibility dialog, he does not have to hunt for an onscreen keyboard: it is only one click away right in front of his eyes. And finally, GDM remembers the setup and automatically starts the onscreen keyboard each time I get to the login screen. :-) Personally, for pointer only users, I perceive the new GDM as a big improvement in confront of the old GDM. Unless I am making a mistake, Ubuntu Karmic is the first Ubuntu version that is accessible out-of-the-box for pointer only users able to click. Remarks: - I am only talking about an installed Ubuntu Karmic; I don't know whether a pointer only user will be able to go through the installation process without help. - I have named Ubuntu Karmic instead of GNOME 2.28 because I don't know for sure how well gok will perform for pointer only users; Ubuntu Karmic replaced gok with onboard. GDM 2.28.x (and GNOME 2.28.x and Ubuntu Karmic) are not accessible out of the box for pointer only users not able to click. >>> I'm not 100% sure, but I think one of the more useful ones is the >>> dwell gesture provided by MouseTweaks. So, that can be resolved by >>> putting the MouseTweaks applet in the panel and hope/assume that the >>> user has some way of moving the mouse when they approach one of these >>> public kiosks. >> >> If MouseTweaks can solve the problem, that would be awesome. > > It would be nice. We really need to hear from users about whether this > would work or not. If it does, then the worry about mouse gestures > might be for naught. That would leave us with worrying about keyboard > gestures (which can be solved using the existing keyboard shortcuts > mechanism) and switch-based gestures. You are trying to solve the problems by differentiating between different needs instead of talking generally about "keyboard and mouse gestures"; that is great as it is probably the better approach with regard to the user. Concerning pointer users that are not able to click without a software click: I think that if the dwell click applet is installed by default on the panel in GDM and if the dwell click applet is also installed by default on the panel in the GNOME session, a GNOME desktop (GDM session and GNOME session) would also be accessible for pointer only users not able to click. (assuming the availability of an onscreen keyboard) In fact, he will be able to left click, double click, drag click and right click; he will be able to type. Is there anything that a user that does not need any assistive tool can do what the pointer only user user is not able to emulate through his assistive tools? But who knows what use cases can exist that we have not imagined and that breaks what we think to be a solution. That is why I add "I think that" or "Unless I am making a mistake" to my sentences about solutions. >>> Francesco's solution of offering a checkbox seems like it might work >>> and be rather simple. >> >> I worry this approach would be prone to error. Users may not realize >> they need to set or unset the checkbox - especially if they launched an >> AT program via a keybinding rather than the a11y dialog. > > Rather than two non-UI designers designing this, I think we need to pull > in the thoughts of UI-designers and end users about solutions that would > work. Yes, the thoughts of UI-designers could be helpful. +1 Cheers Francesco _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
