[Accessibility] Accessibility minutes for 18 Jan 2006

Tue Jan 24 08:05:29 PST 2006

01/18/06 Accessibility meeting             

Gunnar Schmidt
Olaf Schmidt
Bill Haneman
Janina Sajka
John Goldthwaite
Doug Beattie
Earl Johnson
Peter Korn        

Janina is having computer problems so no agenda for today.   The minutes from the prior meeting were just distributed prior to the meeting so we’ll hold them for review and approval next week.

Janina called several studios. Some were as low as $35 but most were 75 to more than a $100.  So with domain knowledge, $100 is easily justified. We approved Janina’s invoiced amount at $100 per hour.

Topics for today- Sign on to KDE open desktop initiative.  Finish Keyboard. AT-API.     

Peter- ODF meeting was scheduled for next week but has been postponed.  With change in administration, the tenor of meeting is changing.  
Janina- any follow up on the RFC?
Earl- no new comments.  I authored a reminder email and sent it to Janina for review.
Peter- Did we send it to any of the MacIntosh accessibility lists? - should send to Mac visionary, technical lists - 
Peter will send message to these lists.
Earl- will send out reminders this weekend.  We’re getting close to the end of the comment period, less than 2 weeks.

Janina- is there objection to signing on to the open desktop letter? No objection, so Accessibility has signed on to the letter.  
Olaf- I will let Aaron know.

Janina- Missing some key people to continue the discussion from last week on balancing what we can achieve on AT-SPI vs. completion of the keyboard spec as George was outlining.  
Earl- The plan was to wait until after comment period and work with Bill to get raw content.  Then I’ll edit it into XKB spec.  I’ll talk with Bill about a schedule.  Bill and Earl will work on details offline.
Olaf- talking about the XKB ABI and the test case for that, the functionality described in the spec is more than xkb by itself.  You need XKB to implement that but it is only a small part of what is demanded in specification.  So why would the testing be at the XKB layer?  Is it easier to test?  The keyboard spec describes a lot of functionality which is not provided by XKB itself.
Bill- two aspects to the specification- functional spec which we have created and the ABI spec. which is independent.

Olaf- so the ABI would be used by those who would implement the specification?
Bill- No neccessarily, The ABI is there not just for those who implement; if the spec is implemented by the platform, it doesn’t matter how it is implemented, though you are correct in saying its 99% chance it is implemented using the ABI.   It is there so that other clients such as assistive technologies at are independent of the Access X functional spec, can rely on the ABI being there. For example an on-screen keyboard can get sticky keys and get notifications, etc.  They are related but the relationship is implied, the could be satisfied independently.
Olaf- Okay, also need to see how applications using the API interact with the desktop environment. If you start GOK on KDE, it will turn on sticky keys and set Gnome settings. Then if someone goes to the KDE settings, I’m not sure they get the correct information.
Bill- I think they do, the way GOK is written, if the Gnome settings are not available, Gok will interact with sticky keys directly.
Olaf- depends on how the KDE code is implemented, it needs to detect that there is a change.
Bill- if it is the only agent that interacts with XKB, then that is correct. Your desktop environment has to be listening to XKB notifications as well as directly calling XKB.
Olaf- what if there are several applications, each insisting on their own XKB settings.
Bill- right, that isn’t something we need to directly specify, just make an implementation note- clients shouldn’t assume they are the only application running. That is a universal software problem.
Olaf- describing the functionality only has the advantage that, for example, MacIntosh could support the spec.  So the test cases for XKB are an optimal path for using X using..
Bill- I disagree, why would XKB prevent MacIntosh from complying?  
Olaf- is the XKB ABI tied to X?
Bill- yes, but MacIntosh uses X server.  
Olaf- Okay, I didn’t know that,  say why wouldn’t Microsoft support the spec?
Bill- Microsoft can’t support LSB unless they provide a bunch of libraries
Olaf- they might want to support the accessibility specification.
Bill- XKB client ABI could in theory could be implemented by whatever Window calls display environment.  Do think it will happen anytime soon, but no reason
Olaf- okay, let’s say imbedded Linux or any system that doesn’t have X. What we could do is specify the XKB compliance. If you are using X to implement this, then you need to
Bill- I think we could do to say- if they have a keyboard
Earl- If Windows want to support the spec., they are going to be required to include XKB on the platform to make the spec?  It that case it (doesn’t?) makes sense to include XKB if it is meeting the functional specs in a different way.
Bill- I disagree, Windows has to support any ABI component we are specifying as part of LSB. But Windows doesn’t support any of LSB, so what difference does it make. The History of LSB has been about entirely about ABI compliance.  This ABI portion of the spec is entirely consistent with what FSG and LSB have always done.  The Functional spec is what is abnormal and may meet with resistance. The ABI is what they require as part of any spec.
Olaf- If, for example, you have a Linux PDA using tutopia or whatever, does the LSB spec say you need to have an X server?
Bill- you need to have a client library that conforms to an ABI
Olaf- which is the X ABI
Bill-no, the XKB ABI
Gunnar- which is a small part of X ABI
Bill- but we are talking about the client ABI, being a layered client/server architecture X has a number of ABI’s.  It has a protocol ABI, etc., we won’t be specifying protocol.  We’re just saying there will be client binding that look like this.  The underlying protocol could be something other than the official X protocol or it could be tinyX or imbedded X,  it could be some other frame buffer port.  
The purpose of ABI specs, my understanding is that the ABI spec is to provide assurance to the application that it will able to dynamically link and run on a conformant platform.  So a binary Linux executable for an assistive technology that  uses XKB, can drop code in and it will run.  Doesn’t mean there has to be a complete Xserver, has to look as if there is an Xserver from the point of view of application. Has to see libc and core libraries, must be present and functional.   Can I write an application for the platform; will it run?

Olaf- I totally agree, apps that wish to run of system if spec, need to know what function calls to use, etc. Only question is current keyboard access spec doesn’t address this aspect of applications at all. It says which functionality must be provided to the user of the desktop. It would possible to split this into two parts, the part for the application and the part for the user. For our conformance test, we need to tests of both. It might be possible to pick out the functional part, the ABI doesn’t make sense because you have a completely different system anyway. If it is too much hassle to divide into parts, then its possible to provide such an ABI on Imbedded Linux without bringing in all kind of X stuff then that’s not an important thing more me.
Doug - the LSB was set up to be modular.  They have base specs, but have others for desktop and imbedded.  That will vary based on what they can provide. We can have a Base spec of our own and additional modular ones based on other things being there from LSB.
Olaf- this is why I asked, there is a LSB spec for Imbedded Linux isn’t there?
Doug-  base spec. is there. It has been designed since 2.0 to be modular so that other things can be added, or in the case of imbedded device have things taken from it. It will grow over time, it is a living document that allows modularity. 
Olaf- are there any X ABI’s specified for the Imbedded version?
Doug- I’m not sure on the Imbedded, on core piece the ABI is there for the server.  For desktop, other pieces are added.
Olaf- Isn’t the core used for everything?  
Doug- the core is there for the sever, for desktop there are other little piece that get added on.
Olaf- if there already some X ABI’s in the core, then wouldn’t change so much to add a few of the.  On other had, I don’t know if need X ABI on the server.
Doug- I’ll find the link to the X lib’s that are in the core so that you can take a look at them. 

Janina- So Earl, is the decision that we are going ahead with the ABI spec?
Earl- You mean the ABI?  I think so but we need to be sensitive to the right way to present it. 
Olaf- I have no objection to going forward with that.  We just need to see what we need for server, desktop and imbedded and whether in needs to be modular or one big piece.
Earl- So, will proceed as planned with an eye toward addressing that issue.
Janina- any sense of how long it will take?
Earl- no.  

Janina- The other agenda for the year is AT-SPI, that is the other reason to talk about when a face-to-face might be most useful.  We had suggested to meet in July at the developer forum in Ottawa. Developers conference is Monday, July 17 and 18 so we would go a couple of days before or after it.  
Bill- that time is possible for me.
Peter- should be reasonable for me also.  July sounds like it is a good candidate.
Janina- Good, I don’t have anything else today, see you next week, same time.  We do have audio now, so we have that for review.
Doug- I sent out the link to the info on the 3 platforms    

John Goldthwaite
jgoldthwaite at yahoo.com
828 885-5304

---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 Photo Books. You design it and we’ll bind it!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/accessibility/attachments/20060124/9285b7c8/attachment.htm