Re: GNOME Accessibility on by default, and Firefox
Willie Walker wrote: I think there's a few things to consider: 1) How to delay the creation of the accessible peers - we don't want to create them if nobody is interested. Related to this, how to delete any accessible peers if all assistive technologies go away. I guess making sure GAIL ( other ATK implementations), atk-bridge and AT not to do unnecessary ref is important. And un-ref all accessible peers when AT is quiting. 2) How to delay the emission of events - we don't want to emit them if nobody is interested. As with #1, how to stop the emission of events if all event-driven assistive technologies go away. If we don't create objects, the signals will not be emitted. And if objects are gone, there is also no signals. And of course we can tell atk-bridge not to emit all signals also. 3) How to do the above, yet also ensure that applications are discoverable to assistive technologies and vice versa. I think we can do this by a initialize function which only register the application. Li In order to accomplish this, I think *some* level of a11y support needs to be on, but it could be a simple rendezvous mechanism that doesn't require peers to be created for all objects in an application. Will On Sat, 2008-11-01 at 16:36 +, Steve Lee wrote: 2008/10/27 Li Yuan [EMAIL PROTECTED]: A way to do this in my mind is to create functions in atkmisc, to tell gail and other accessibility implementations to send out signal or not. If an AT is started, at-spi-registryd will call the function to tell applications now it is time to send out the signals. But this require modification in all accessibility implementations (Firefix, OpenOffice, Gtk+ applications, Java applications). What if that gets pushed down the stack a bit so the decision to actually send on the wire is made even though ATK/FFx etc still call and look for events? Would the over head of the function calls that test and return with no a11y be too much to bear? It would be localosed in one place and all appswould behave the same. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
I think there's a few things to consider: 1) How to delay the creation of the accessible peers - we don't want to create them if nobody is interested. Related to this, how to delete any accessible peers if all assistive technologies go away. 2) How to delay the emission of events - we don't want to emit them if nobody is interested. As with #1, how to stop the emission of events if all event-driven assistive technologies go away. 3) How to do the above, yet also ensure that applications are discoverable to assistive technologies and vice versa. In order to accomplish this, I think *some* level of a11y support needs to be on, but it could be a simple rendezvous mechanism that doesn't require peers to be created for all objects in an application. Will On Sat, 2008-11-01 at 16:36 +, Steve Lee wrote: 2008/10/27 Li Yuan [EMAIL PROTECTED]: A way to do this in my mind is to create functions in atkmisc, to tell gail and other accessibility implementations to send out signal or not. If an AT is started, at-spi-registryd will call the function to tell applications now it is time to send out the signals. But this require modification in all accessibility implementations (Firefix, OpenOffice, Gtk+ applications, Java applications). What if that gets pushed down the stack a bit so the decision to actually send on the wire is made even though ATK/FFx etc still call and look for events? Would the over head of the function calls that test and return with no a11y be too much to bear? It would be localosed in one place and all appswould behave the same. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Ang. GNOME Accessibility on by default, and Firefox
Hi all, This is an important discussion. Thanks Tom and Ian for confirming the user need for allowing smooth moving into, and out of, AT support! And you all seem to refer only to use cases concerning adult, relatively advanced and independant user scenarios. Widen that to school and home use for children, and for adult users with multiple impairments, causing more dependency on assistance, and it should be obvious that this is an real issue. Accessibility must be combined with usability, and this aspect must not lag behind in Unix/Linux compared to what's expected and normal in Windows and Mac environments. There seem to be some promising techy suggestion on how to handle this, but also quite a challenge in terms of work and dependencies :-/ Mats Lundälv Ian Pascoe [EMAIL PROTECTED] Sänt av: [EMAIL PROTECTED] 2008-10-26 13:21 Sänd svar till [EMAIL PROTECTED] Till gnome-accessibility-list@gnome.org Kopia Ärende GNOME Accessibility on by default, and Firefox Hi We seem so far to be inter mingleing both Gnome and Windows into this discussion. Could people please state which OS their comments apply to in the first instance? If I understand what Will has said, the current situation is very much akin to a chicken and egg one - we want AT to be dynamic, and only load when required, but for it to load when required it currently needs to be already loaded and running. I certainly agree with Tom's use case scenarios. When I'm using the PC and another family member wishes to use it, they get annoyed by the AT being active so disable it - I am unaware of how this impeeds on their experience. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
GNOME Accessibility on by default, and Firefox
Hi We seem so far to be inter mingleing both Gnome and Windows into this discussion. Could people please state which OS their comments apply to in the first instance? If I understand what Will has said, the current situation is very much akin to a chicken and egg one - we want AT to be dynamic, and only load when required, but for it to load when required it currently needs to be already loaded and running. I certainly agree with Tom's use case scenarios. When I'm using the PC and another family member wishes to use it, they get annoyed by the AT being active so disable it - I am unaware of how this impeeds on their experience. So, going back to Will's earlier mail, we need to know if all or part of the AT infrastructure can be loaded / unloaded dynamically, and if so what mechanisum needs to be set in place to allow this to happen. to an aside, if a user in Gnome has AT running, and a second user is switched to that doesn't have AT activated, does AT remain running in the background for the primary user or is it sent to sleep with the rest of that user's session until it is re-awakened? If not, would this be another use case scenario? My own thoughts, and I admit I have no technical knowledge here, would be to construct a small footprint watchdog style damon that runs, if the AT infrastructure is installed on a Gnome installation, and when AT is required, it loads up the necessary modules until such time that they are no longer required. A further case scenario that comes to mind as well is for those apps which do not support AT in any form, whilst they are the active window, the watchdog could unload the AT to ensure that response times are not impaired by the infrastructure too much - maybe give the damon a config variable that says how long the AT should remain running until they are unloaded in this case. This would mean that the damon would need to be able to interogate the app to see if AT was available of course. Two other related questions come to mind, can we accurately determine what impairment AT incurs on an app for a user not using AT; how quickly can the various modules be loaded / unloaded. My only concern through all of this is how much of the supporting infrastructure would need to be changed to allow this necessary, IMO, feature to be included, and could it be done gradually, or would it be big bang? Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Bolter Sent: 25 October 2008 14:04 To: gnome-accessibility-list@gnome.org Subject: Re: GNOME Accessibility on by default, and Firefox Jason White wrote: On Fri, Oct 24, 2008 at 05:22:35PM -0400, Willie Walker wrote: Note that I'm not necessarily encouraging or supporting the current you-get-it-or-you-don't behavior of GNOME. I'd much prefer NOT to have a gconf setting to enable accessibility, and I would prefer it to be a bit more dynamic. With the current architecture, I think we can get *close* to this with some extra work. To be clear, what I'm supporting is the proposal not to require a gconf setting to enable accessibility, without this resulting in performance-degrading events occurring when no assistive technology is active. Hi. I'm interpreting gconf setting as user preference here, but let's keep in mind that we can set a gconf flag automatically (for example from code in atspi, atk, or some bridge) based on platform events. e.g. gail_is_live, 1, or accessibility_is_live, 1. Is that an abuse of gconf? cheers, David ___ 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
Re: GNOME Accessibility on by default, and Firefox
Willie Walker wrote: So...to make a long story short, I'd guess most of the work needed is independent of CORBA/D-Bus and would live in the AT-SPI implementation for the toolkit (e.g., GAIL). Li Yuan would be a good person to help us understand the scope of this problem. A way to do this in my mind is to create functions in atkmisc, to tell gail and other accessibility implementations to send out signal or not. If an AT is started, at-spi-registryd will call the function to tell applications now it is time to send out the signals. But this require modification in all accessibility implementations (Firefix, OpenOffice, Gtk+ applications, Java applications). Li ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
So many discussions on this topic, so I thought I would also provide my opinion on this ;) On Windows, people don't care about such an Accessibility=on setting. They simply start their AT, and it works. And it doesn't mean that Accessibility would always be on, slowing down things even w/o any AT running. Well, we know a big difference is that Windows doesn't have a real accessibility framework, but I assume it will also work fine when you first start Lotus Symphony, and AFTER that Jaws to access Symphony using MSAA/IA2. If the MSAA/IA2 combo let's allow you to get all information needed w/o intercepting the app from the beginning, AT-SPI/ATK should also allow for that. If some API is missing, it should be added. And as a side note: We have a similar Accessibility=on issue with OpenOffice.org. OOo is not written in Java, but exposes Accessibility information via JAA. This means we must launch a Java VM with OOo, which is time and memory consuming, so we don't want to do that for all people, especially because it's not only about start-up, but also about runtime performance - the Java Access Bridge will always collect as much data as possible, even when no AT is running. So having such a setting in OOo is unfortunately necessary (until having IA2), but: AT users don't understand it. They don't expect that they have to enable something for Accessibility. Conclusion: Try to get rid of that setting, but w/o the implication that AT-SPI would always actively collect data even with no AT running... Malte. Jason White wrote, On 10/25/08 07:54 AM: On Fri, Oct 24, 2008 at 05:22:35PM -0400, Willie Walker wrote: Note that I'm not necessarily encouraging or supporting the current you-get-it-or-you-don't behavior of GNOME. I'd much prefer NOT to have a gconf setting to enable accessibility, and I would prefer it to be a bit more dynamic. With the current architecture, I think we can get *close* to this with some extra work. To be clear, what I'm supporting is the proposal not to require a gconf setting to enable accessibility, without this resulting in performance-degrading events occurring when no assistive technology is active. ___ 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
Re: GNOME Accessibility on by default, and Firefox
On Sat, Oct 25, 2008 at 08:25:55AM +0200, Malte Timmermann wrote: And as a side note: We have a similar Accessibility=on issue with OpenOffice.org. OOo is not written in Java, but exposes Accessibility information via JAA. This means we must launch a Java VM with OOo, which is time and memory consuming, so we don't want to do that for all people, especially because it's not only about start-up, but also about runtime performance - the Java Access Bridge will always collect as much data as possible, even when no AT is running. I thought OO.O eliminated that accessibility dependency on Java quite a long time ago. I remember reading that it now uses ATK directly. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
On Sat, Oct 25, 2008 at 09:50:04AM +0200, Malte Timmermann wrote: On GNOME - sure. On Windows, it's still JAA. Thanks. I haven't been tracking developments over in Windows land. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Jason White wrote: On Fri, Oct 24, 2008 at 05:22:35PM -0400, Willie Walker wrote: Note that I'm not necessarily encouraging or supporting the current you-get-it-or-you-don't behavior of GNOME. I'd much prefer NOT to have a gconf setting to enable accessibility, and I would prefer it to be a bit more dynamic. With the current architecture, I think we can get *close* to this with some extra work. To be clear, what I'm supporting is the proposal not to require a gconf setting to enable accessibility, without this resulting in performance-degrading events occurring when no assistive technology is active. Hi. I'm interpreting gconf setting as user preference here, but let's keep in mind that we can set a gconf flag automatically (for example from code in atspi, atk, or some bridge) based on platform events. e.g. gail_is_live, 1, or accessibility_is_live, 1. Is that an abuse of gconf? cheers, David ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Hello, Jason White wrote: On Thu, Oct 23, 2008 at 09:54:03PM -0400, David Bolter wrote: Are there any objections to all this? For what it's worth, there's strong endorsement from me. All that the user should have to configure is whether to start her or his chosen assistive technology by default. Activating the accessibility infrastructure should be entirely a matter between the Gnome environment and the AT. We should not forget GDM. Supposing that the accessibility infrastructure has been modified to automatically run only when it is needed; will it behave the same way at the GDM login screen? Cheers Francesco ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
I agree too. When using an assistive technology to have a11y support enabled, but if you disable the AT disable it in order to improve performance for non AT users. I don't know if this is possible to enable/disable on the air without restarting the session. Regards, Javier. El jue, 23-10-2008 a las 00:53 -0700, T.V Raman escribió: I think this is a good idea. Performance matters to everyone, and the last thing you want as someone who depends on accessibility is for the rest of the world to perceive accessibility as something that slows things down for everyone else. David Bolter writes: Hi all, Firefox (and other apps) provides accessibility support conditionally. This means that on GNOME it always runs a little slower for everyone, and eats up extra resources. I wonder if we could have GNOME accessibility turned on, but a separate setting that Firefox can check on GNOME to tell it if the at-spi is actually being used by a client? This matters because people outside our circle make choices about browsers based on performance... and I think we want the most accessible one to win ;) cheers, David ___ dev-accessibility mailing list [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-accessibility ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Ang. Re: GNOME Accessibility on by default, and Firefox
I strongly support this too. It would smoothly remove one of the awkward issues presented to the user when starting an application like GOK - and which we discussed eralier this week. Mats Lundälv Jason White [EMAIL PROTECTED] Sänt av: [EMAIL PROTECTED] 2008-10-24 09:04 Till gnome-accessibility-list@gnome.org Kopia Ärende Re: GNOME Accessibility on by default, and Firefox On Thu, Oct 23, 2008 at 09:54:03PM -0400, David Bolter wrote: Are there any objections to all this? For what it's worth, there's strong endorsement from me. All that the user should have to configure is whether to start her or his chosen assistive technology by default. Activating the accessibility infrastructure should be entirely a matter between the Gnome environment and the AT. ___ 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
Re: GNOME Accessibility on by default, and Firefox
Hi All: There are a lot of things to think about here. From the internals point of view, we can think about the following: 1) The accessibility gconf setting: this says whether or not accessibility has been requested for the session. Right now, this tends to be used by GTK+ just to say whether or not to load the accessibility modules and start the AT-SPI registry. We've been trying for a long time to not require this setting and just always have the support turned on. But, there are performance and stability issues that prevent us from doing this, some of which might be addressed by making things more dynamic. BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. 2) ATK and the ATK bridge: the ATK is a utility toolkit for use by applications and graphical toolkits to create an accessible representation of widgets: ATK peers are created for application/toolkit widgets and ATK events are issued for application/toolkit events. The bridge provides the communication with the outside world. That is, the bridge is the thing that currently speaks CORBA and which we are moving to D-Bus. Note that ATK and the ATK bridge are not required for an application to participate in the AT-SPI infrastructure; they merely make it easier to do so. So, GTK+, OOo, and Gecko all use the ATK and ATK bridge. Java, on the other hand, currently has its own bridge and speaks CORBA directly (I've argued that Java should use ATK via JNI to help normalize things somewhat and make it less dependent upon the AT-SPI transport). 3) The AT-SPI registry. This provides the rendezvous mechanism between applications and assistive technologies. When an application starts, it lets the registry know it exists so that assistive technologies can discover it. An application also issues events to the registry, which then delivers them to assistive technologies. When an assistive technology starts, it lets the registry know the event types it is interested in. Like the ATK bridge, the communication with the registry is dependent upon the IPC mechanism being used (i.e., CORBA or D-Bus). 4) GAIL: this provides the accessibility implementation for GTK+, creating ATK peers for GTK+ widgets and causing ATK events to be issued. It is designed to loaded as a GTK+ module at GTK+ initialization time and is currently not designed to be unloaded/reloaded over the course of an application's lifetime. Modifying it to be more dynamic might be rather difficult, and this is independent of the IPC mechanism in use. That is, I don't believe its behavior matters whether we use CORBA or D-Bus. From the assistive technology point of view, we can think of the following: 1) Assistive technologies that mostly examine object hierarchies. GOK tends to be this type of assistive technology. Accerciser fits into this category as well. These kinds of ATs might work with the just wakes up model, especially if one queries from the top of the object hierarchy down. However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. 2) Assistive technologies that mostly listen for events. Orca tends to fit into this category. I believe GOK also needs to listen for events, however, so it knows where to enter text and which UI needs to be grabbed. These kinds of assistive technologies might be more difficult to support the just wakes up model since they tend to depend upon receiving events from the application in order to learn that an application exists. Given these, I'm not sure it's really feasible to completely shut off accessibility in an application and dynamically turn it on when an assistive technology appears. That is, I think something probably needs to live in the application to at least support a rendezvous with an assistive technology. I also believe the main performance issues we face are the ATK peering of objects and event notification: we don't want unnecessary ATK peers to be created and we don't want unnecessary events to be issued. As such, I think we at least need the ability for assistive technologies to discover applications that are already running and to be notified when new applications start. From there, we could investigate generating ATK peers and issuing ATK events on an on demand basis. So...to make a long story short, I'd guess most of the work needed is independent of CORBA/D-Bus and would live in the AT-SPI implementation for the toolkit (e.g., GAIL). Li Yuan would be a good person to help us understand the scope of this problem. Will On Oct 23, 2008, at 9:54 PM, David Bolter wrote: Hi Aaron, Replying to a message from Aaron which didn't have the lists cc'ed. As Steve has brought up separately, this might indeed fit into the D-BUS
Re: GNOME Accessibility on by default, and Firefox
BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. Afaik we do just use the gconf setting, which is the problem. Then we start creating accessible objects, firing extra events, doing extra processing for DOM mutations, lalala. What other check should we use before turning it on? To be clear, if the gconf setting is not set, then no accessibility support will be enabled in Firefox. Is that right? If so, I'm confused. By enabling accessibility, the user is saying they want accessibility enabled. But, it seems like the argument being made here is that even if the user enables accessibility, they really don't want it. I think I might have missed the actual use case (I've been out of the country for the past week). Can you describe why someone would call to order pizza and then complain when it is delivered? Seems to me they should not have ordered it in the first place. ;-) However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. ... Any time any app asks for even the root accessible object for a given window, that window receives a signal. This may be the case on Windows, but I don't believe it is the case for GNOME. Will ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Here is my understanding of this thread that I have been quietly watchig from the sidelines. WHat is being asked for is something closer to the windows model. In other words if accessibility is needed by an AT app like orca then it is started and runs. However if it is not needed it is not being used. THis can be important on a computer used by many people where one wants accessibility and one does not. In windows you simply shut down the screen reader and the lag it introduces goes away which is not the case in Gnome as far as I can tell. Ideally of course there would be no difference between having an AT program running and not but given that there is extra proccessing involved that isn't likely to happen. DOn't know if that is a correct reading but it is my understanding. Tom On Fri, Oct 24, 2008 at 04:23:51PM -0400, Willie Walker wrote: BTW, I'm not sure about the details of what the Gecko implementation does, but it would surprise me if it *always* loaded the accessibility modules regardless of the gconf setting. Afaik we do just use the gconf setting, which is the problem. Then we start creating accessible objects, firing extra events, doing extra processing for DOM mutations, lalala. What other check should we use before turning it on? To be clear, if the gconf setting is not set, then no accessibility support will be enabled in Firefox. Is that right? If so, I'm confused. By enabling accessibility, the user is saying they want accessibility enabled. But, it seems like the argument being made here is that even if the user enables accessibility, they really don't want it. I think I might have missed the actual use case (I've been out of the country for the past week). Can you describe why someone would call to order pizza and then complain when it is delivered? Seems to me they should not have ordered it in the first place. ;-) However, *something* needs to already be awake so that an assistive technology can discover the top level application object in the first place. ... Any time any app asks for even the root accessible object for a given window, that window receives a signal. This may be the case on Windows, but I don't believe it is the case for GNOME. Will ___ 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
Re: GNOME Accessibility on by default, and Firefox
On Fri, Oct 24, 2008 at 05:22:35PM -0400, Willie Walker wrote: Note that I'm not necessarily encouraging or supporting the current you-get-it-or-you-don't behavior of GNOME. I'd much prefer NOT to have a gconf setting to enable accessibility, and I would prefer it to be a bit more dynamic. With the current architecture, I think we can get *close* to this with some extra work. To be clear, what I'm supporting is the proposal not to require a gconf setting to enable accessibility, without this resulting in performance-degrading events occurring when no assistive technology is active. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Steve Lee wrote: 2008/10/22 Aaron Leventhal [EMAIL PROTECTED]: There is no need for an enable a11y flag in the OS. Just the fact that something asks us for an accessible object wakes us up. We really need lazy instantiation like that under Gnome. If the AT is loaded and starts asking us for objects, then we can wake up. Ding! Yes, of course. The user should NOT have to state they want AT support for accessibility turned on when the fact that they are using an AT that want's it is enough. Ditto any desktop features that rely on AT-SPI. So we just need to get rid of the need to logout/in after turning it on/off and add a protocol for AT's to request it and for it to to be enabled turn when an AT fires up. Does the D-BUS port give us this capability? Yes. For current AT-SPI we can't do this without creating new APIs. I think we need to think about putting this feature into DBus porting work. Li We can perhaps defines some system messages for a11y? ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Hi Aaron, Replying to a message from Aaron which didn't have the lists cc'ed. As Steve has brought up separately, this might indeed fit into the D-BUS AT-SPI migration work. It doesn't seem terribly complex to add this small thing that will have nice benefit (like what T.V. points out). @Will Walker, we could maybe touch on this Monday night at 10 ;) Are there any objections to all this? cheers, David Aaron Leventhal wrote: In Firefox, there's a lot of code that doesn't need to run, and a lot of objects don't need to be created, when a11y isn't needed. Please, add lazy instantiation for accessibility. Would it fit to do this in the D-BUS AT-SPI migration project? - Aaron On 10/22/2008 8:35 PM, David Bolter wrote: This is a common pattern. I hear it is also true for other things in FF like dom mutation events only fire if there is a listener... makes a lot of sense. A tree should only fall in the forest if someone is listening.grin D Aaron Leventhal wrote: Mario, on Windows we use lazy instantiation. There is no need for an enable a11y flag in the OS. Just the fact that something asks us for an accessible object wakes us up. We get a WM_GETOBJECT event -- and before that a11y is not loaded. We really need lazy instantiation like that under Gnome. If the AT is loaded and starts asking us for objects, then we can wake up. - Aaron ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
GNOME Accessibility on by default, and Firefox
Hi all, Firefox (and other apps) provides accessibility support conditionally. This means that on GNOME it always runs a little slower for everyone, and eats up extra resources. I wonder if we could have GNOME accessibility turned on, but a separate setting that Firefox can check on GNOME to tell it if the at-spi is actually being used by a client? This matters because people outside our circle make choices about browsers based on performance... and I think we want the most accessible one to win ;) cheers, David ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
David Bolter [EMAIL PROTECTED] writes: Hi all, Firefox (and other apps) provides accessibility support conditionally. This means that on GNOME it always runs a little slower for everyone, and eats up extra resources. I wonder if we could have GNOME accessibility turned on, but a separate setting that Firefox can check on GNOME to tell it if the at-spi is actually being used by a client? This feels broken. What if I have accessibility enabled, my screen reader not started, but firefox already open? By enabling accessibility, I told the system already that I will want to use it. But with such a sneaky check, my screen reader would not be able to access firefox since it has decided to not use AT-SPI... Or did I miss something in this mail. It reads like the check you propose is kind of automatic, if it were a permanent gconf setting, it would just duplicate the Accessibility-enabled setting, wouldn't it? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer URL:http://debian.org/ .''`. | Get my public key via finger mlang/[EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- URL:http://delysid.org/ URL:http://www.staff.tugraz.at/mlang/ ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
Mario, on Windows we use lazy instantiation. There is no need for an enable a11y flag in the OS. Just the fact that something asks us for an accessible object wakes us up. We get a WM_GETOBJECT event -- and before that a11y is not loaded. We really need lazy instantiation like that under Gnome. If the AT is loaded and starts asking us for objects, then we can wake up. - Aaron ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: GNOME Accessibility on by default, and Firefox
This is a common pattern. I hear it is also true for other things in FF like dom mutation events only fire if there is a listener... makes a lot of sense. A tree should only fall in the forest if someone is listening. grin D Aaron Leventhal wrote: Mario, on Windows we use lazy instantiation. There is no need for an enable a11y flag in the OS. Just the fact that something asks us for an accessible object wakes us up. We get a WM_GETOBJECT event -- and before that a11y is not loaded. We really need lazy instantiation like that under Gnome. If the AT is loaded and starts asking us for objects, then we can wake up. - Aaron ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
