JS: PB pink slipped by IBM, puts the future of IA2 somewhat in question.
PB: I think I'll stick with the IA2 group until I get a new job, then figure out if it's aligned or not. If it isn't, we can see who might want to take over. Got one person unoficially thinking about it; would need to think more and talk to his company. Until then, I'll be happy to continue driving the ia2 effort.
JS: I think I speak for all of us when I say I hope we don't lose you; not many people qualified to work on a11y and bring products to end users. In terms of IA2 status, we have fairly general agreement in our community that would be okay to move licensing from LGPL to a bsd-like license. I think we have consensus around that and that it's relatively doable; don't need a lot of peoples' permission. Our attourney, Karen Kopenhagen(sp?), needs to get in touch with people at Sun, since they did some OpenOffice accessibility. She is aware of who to contact but has been ill for the last couple weeks. Continuing conversation with MS also on hold; the ball is in our court. Seems to be the consensus from the LF accessible office.
MD: Right now I'm working on dogtail and making sure it runs acceptably.
WW: Are you proposing a migration for 2.28?
MD: Yes, but reference counting looking a little dodgy.
WW: Who will pick up the ball when the funding is over?
MD: Not sure; will try to help but it won't be nearly as much as I have been.
WW: With KDE, what will they do for a11y solutions? Try to use GNOME assistive tech, or writing their own?
MD: The KDE guys seem amenable to replacing their a11y architecture with atspi-dbus
JS: That's some good news.
WW: What I'm nervous about is that it's great they want to replace it but we could end up in a situation where KDE moves to atspi-dbus but may not be quite the same as what we have in GNOME
MD: The QT bindings I've done are simplistic at best. They'll only get done properly when I'm funded full-time to work on that. Still months away. I would've thought that, even though we don't have this problem with QT, it would still be a factor(?). We should make sure the two are the same.
WW: We need to keep on with the big goal that KDE and GNOME use the same stuff.
JS?: Funding up in a couple months?
MD: Less than that, for working on atk-bridge anyway. Middle of March.
WW: Need to figure out how to move forward on the GNOME side.
MD: Issue with ref counting, cspi (can't go forward in GNOME without cspi).
WW: Can you write a message on the desktop list for gnome? We could talk about it on gnome a11y, but probably won't hit enough people who will be involved in making the transition. Desktopfirstname.lastname@example.org. If you could start a discussion there now, it would be great. Then we can start figuring out how we're going to manage this.
MD: We had a big discussion on g-a-devel about the lifecycle problem that Michael Meeks talked about a long time ago. We're not doing any object referencing in dbus. Some objects don't reference their children. We need to get a solution, and I don't really know what it is.
WW: Would prefer that, for the time being, the API remain as close to the CORBA as possible. If we change the API, then we have both an API change and an IPC change, so debugging will be harder.
PD: One of the things I was observing is that, with a CPU scheduler or X or a compiz issue, I was starting to think about this kind of situation. I haven't looked at where the problem lies, maybe none of this would happen. The old computers dedicated scheduling to critical threads to the operating system: keeping up the timer tick, etc. If you put Linux now with 100% cpu usage, your mouse and windows may not keep up. Not sure if it's in one place or multiple places. The kernel people probably don't want to change the scheduler; the X people probably don't want to change X. In a11y, you don't want not to get feedback.
JS: The context of your interest is magnification, right?
PD: I use magnification all the time. Interactivity isn't where it should be.
WW: I'm not sure it's something we can address in this organization as part of this group. A whole bunch of things coming together. One place to start might be logging a bug with the person highest on the food chain. If you're using Orca and things not working very quickly with Orca, log a bug with Orca.
PD: You could think that it's a problem with Compiz, but maybe it isn't; could be a bug with the scheduler. Might have to go up and down the food chain to find the problem. If you don't do that, I'm not sure how you can easily resolve it. If you put in bug reports and performance problems, you can get a lot of results back from Google from people reporting problems.
WW: May not get the response time you've been looking for. We're asking a lot out of the machines. There are areas where things can improve.
PD: I wonder if it's a design fault. If you do it in hardware or look at old machines, they used to look at hardware towards updating video cycles. Could just be poor design.
WW: It might be. Place to start would be to log a bug, get a very specific use case.
PD: I've seen people dancing around the problem. Machines are vastly faster than what they used to be before. if you program it wrong, no machine can keep up.
WW: If you give people more cycles per second, people will find a way to use them. People will make things spin and grayscale and shading, and all of those things will chew up cpu time. The place to start is to come up with a clear use case where you're running into, the exact applications and hardware configuration and OS configuration and what you're doing.
PD: I remember the old Linux. Didn't used to lag. They just have certain threads created for critical processes. I'm not sure if it's that simple. Could be there's many things wrong rather than just one.
JS: Doesn't seem we have the answer even in the group.
??: Need to figure out who's to blame before we can deal with the issue.
WW: Which magnification are you using? You need to start a conversation with the compiz folks.
PD: Depends on video drivers and a lot of things. It'll go round and round and round.
WW: That's a simple configuration compared to other things. Compiz has a bug-reporting system. Under that, there's the composite extension and the X server and Nvidia drivers. You're not likely to see changes in X or the Nvidia drivers, but you may see changes in Compiz and Visum(sp?).
PD: If you have a multiuser scheduling system, it's like a batch system. You have to have multiple threads or you can't get your i/o out.
WW: We're not going to solve this problem in this group. This is the wrong spot to try to solve this problem.
BT: We talked about the Firefox and OpenOffice issues with a gail and at-spi patch. Seems to be resolved now. As far as our team progress, we'll be feature complete next week. We'll have a 1.0 release in the next four weeks. That will include the entire UIA spec. Other than that, we're just pushing forward on it.
WW: About that bug in the gnome bugzilla report, what are your thoughts?
BT: (didn't record)
WW: Where we have multiple toolkits, we need to figure out who is on top. We're passing parameters by setting environment variables.
BT: That's really bad.
WW: It is. We'll keep hashing it out in the bug. We'll try things out in the bug report; maybe have a face-to-face.
JS: Redesign of web pages on LF site. Moving to Drupal. Have a beta out. Email went to the a11y list. I'm sure Gregory will get involved in that with the developers and designers. I'd highlight this for other folks to note. They are looking for feedback. Since it's our working environment for our spec and our spec for the world, we might want to take a look. If you don't have the email, let me know and I'll forward it. david Ames is the webmaster for the LF.
JS: That's all I have. Hopefully next week, Karen will be here and we'll be able to talk about finding grant funding for getting to Akademi/GUADEC.
WW: What are the plans for CSUN?
JS: Good point. Should we ask who among us is going?
WW: Haven't booked my flight, but I'm giving two talks, so I'm planning to be there.
JS: I'm not going unless the W3C asks us to be there.
BT: We're looking into it. Not sure yet.
JS: It's too late for presentations already. It's a great place for a11y all under one roof, but it might be a somewhat slimmed-down CSUN.