Accessibility: Team Meetings 2008 Jun 18

Meeting Log

<@calvin> 

T minus 1 minute

06:59

 

-!- mgorse [\~mgorse@130.57.22.201] has joined #mono-a11y

07:00

-!- mode/#mono-a11y [+o mgorse] by sandy

<@calvin> 

alrighty, let’s get started

same plan as normal, but before we get started, does anyone have anything that needs to be brought up?

07:01

I guess not, I’ll ask again at the end of the review, so bring it up then if you do

07:02

Let’s work down through iteration five in the order that people are listed

sandy: that puts you first

<@sandy> 

okay

well, I ended up making very little progress on my planned tasks

instead I did other things :-)

07:03

I spent a lot of time with the winforms guys getting our patch accepted into the mcs project

so that’s done

I set up a parallel mono environment and changed our MD solutions/projects to have all GAC references

so anybody builing the Uia2Atk stuff is going to need to have parallel mono set up

07:04

which I guess I’ll talk about later

Also, I am working on changes to how our assemblies in Olive are deployed, based on a conversation I had with miguel the other day

finally, I’ve been working on makefiles to help decriptor et al get started on packages

UIAutomationWinforms has makefiles that I think are in good shape, with good integration to the MD projects

07:05

however, I had to turn off reference synchronization, so if you’re working in that project and need to modify references, you’ll have to do it in the MD project and also in the makefiles (bummer, but it’s due to a known MD bug)

I still need to finish the makefiles

next iteration…

I plan to get all of this infrastructure stuff done and also finish the testing and new providers I was supposed to do this iteration

07:06

I’m not adding any new tasks, just carrying everything over that I didn’t finish

done

<@calvin> 

sandy: great, I’ll have you cover the parallel mono and our assembly deployment after we go through all of the status

MarioC: go

07:07

<@MarioC> 

ok.

In this iteration I decided to start implementing ComboBox provider, so, basically this implementation took the three different patterns used with this provider

this involved changes in our winforms architecture to support items in Root controls

07:08

anyway, the implementation is almost finished, I need to test MS behavior with our implementation and write a lot of tests.

TextBox provider isn’t yet finished. I’m missing the Scroll pattern.

07:09

now, next iteration

Finish Combobox, Finish TexBbox and write a wiki-page about the winforms-architecture implementation.

07:10

s/TexBbox/TextBox

done

<@calvin> 

MarioC: sounds good, and I still have an outstanding issue with Microsoft about building and maintaining our hierarchy, but my main contact is out of the office

07:11

Hopefully I can get a response on that soon

ok, i’m up

I was on FTO last week and had a lot of catch up to do earlier this week so I didn’t make much progress on the List control

07:12

I plan on carrying that over for this next iteration and really hound Microsoft to get some answers with the UIA spec and how they’ve implemented their stuff

done

knocte: go

<@knocte> 

ok

07:13

I’ve finished tests on the combobox and created gail tests for radio button which pass there but still not pass in the bridge because I have the implementation in progress,

but it seems to be easier thanks to the class hierarchy rearchitecture I recently committed about this (checkbox and radiobutton inherit from an abstract class togglebutton that inherits from non-abstract class button, which is a hierarchy a very similar structure as gail)

07:14

(BTW I also rearchitected the class hierarchy on inheritance of the Component interface in order not to implement it in the toplevel item and to make all items implement it correctly; thanks also to sandy, we can now see the region coordinates of each widget when clicking on them on accerciser)

07:15

<@calvin> 

nice! I saw that

<@knocte> 

I got stuck also on the combobox implementation because I had doubts about how to query the children but MarioC told me recently that it was now possible in the provider so I guess implementing it now will be really straightforward

I also came out with an idea for unit-testing the events (which seem to be a field we haven’t almost explored in the bridge, even in past iterations), so bgmerrell has helped providing me with a python app which monitors AT-SPI events received on a particular AT-enabled program

07:16

so what I plan for the next iteration is:

a) Finish implementation of ComboBox and RadioButton, making tests pass

b) Start looking at how to integrate the brian’s atspimon.py (and maybe tweak it a bit to show the output in a certain way)

07:17

c) Set up my parallel mono env

and

d) start looking at the next item in my iteration: spinner, to do tests and implementation (although maybe I’m replacing it with the Window class, as it’s already started and maybe this way I can finish all things I’ve planned for this iteration)

07:18

done

(sorry, maybe I was too long) :)

<@calvin> 

knocte: do you think the only way we’ll be able to unit test the events is all the way through at-spi?

07:19

<@knocte> 

calvin: I’m not sure, but I haven’t come out with any other idea, as the events are implemented in the backend as signals

 

-!- jpallen [\~jpallen@ariadne.provo.novell.com] has quit [used jmIrc]

<@knocte> 

maybe I can come out with a signal catcher in C# from the ATK side, I didn’t think about that

<@calvin> 

this might be subject we can discuss after the meeting, but I’d like to see us not involve at-spi.. it just feels like it’s outside the scope of a unit test

<@knocte> 

ok

07:20

<@calvin> 

knocte: thanks, and no, that was not too long

ok, bgmerrell: go

 

-!- jpallen [\~jpallen@137.65.132.2] has joined #mono-a11y

<@bgmerrell> 

This iteration: I spent most of my time working on the test harness. Most of the work was related to creating useful logs and cleaning up tests.

07:21

I also reviewed some style guidelines that Calen created for us, then changed some code and files around to match those guidelines.

Then I spent yesterday writing the app that monitors and logs atspi events

Next iteration: I think will mostly be spent learning more about Strongwind with Calen.

07:22

I do have some other tasks if I get time: looking into orca tests (which keeps getting pushed as we’re working on the Strongwind stuff more right now), writing more documentation for testers, updating the non-opensuse vms that i’ve been neglecting, and updating the test plan to reflect the new stuff we’ve done

done

07:23

<@calvin> 

bgmerrell: have you started to look at any of the packaging? rolling anything out, or is the stuff still not quite there for you to use?

<@bgmerrell> 

calvin: afaik it’s not ready yet

07:24

decriptor is keeping me well informed though

<@calvin> 

ok

Ray: go

<@Ray> 

ok

last iteration, I was starting to learn IronPython,

it consumes me a few days,

07:25

till now, I have implemented three samples (form, fontdialog, progressbar) for cutting my teeth.

and commit them into uia2atk/test/samples/

I’m not sure if someone could review my QA works.

decriptor has created an account on OBS for us to build our stuff.

07:26

so we could talk about more on that.

in the next iteration, I’ll continue to implement the control samples.

done. :)

<@calvin> 

Ray: sounds good, is there no current build/packaging work to be done in the next iteration?

07:27

<@Ray> 

not sure, the one thing I want to ask,

shall we upgrade the main 3 distros have upgraded already, do we need to upgrade these 3 platforms we based on? Fedora 8 to 9, openSUSE 10.3 to 11.0, Ubuntu 7.10 to 8.04 ?

<@calvin> 

Yes, we’ll need to do that, but I would wait until they are released

07:28

<@decriptor> 

calvin: wait a couple hours and I think they’ll all be released :P

<@calvin> 

We don’t need to switch to any beta or pre-releases

heh

<@Ray> 

ok, sure

done

07:29

<@decriptor> 

and depending on how you look at it they are all in reality released (mostly meaning 11)

<@calvin> 

ngao: hmm, I don’t see you listed in the iteration at all

<@Ray> 

decriptor: yep :)

07:30

<@ngao> 

calvin: actually i’m in front of Ray :)

<@bgmerrell> 

Ray: fyi, the Ubuntu and Fedora test VMs in the lab have been updated

<@calvin> 

ngao: Are you looking at Iteration 5? I don’t see you in there

<@Ray> 

bgmerrell: thank you very much for your big efforts. :)

<@bgmerrell> 

Ray: i will probably update openSUSE this iteration

<@calvin> 

ngao: oh, sorry, I’m looking at the current iteration

07:31

ngao: ok, I found you… why don’t you go now

<@ngao> 

ok

I determined the value of IDs, ran nunit on Vista in the last iteration

07:32

i’ve finished GridPatternIdentifiers

and Test

i need to finish StatusBar Test

07:33

and start to implement CheckedListBox

done

<@calvin> 

ngao: nice, so CheckedListBox is planned for this iteration?

<@ngao> 

yes

07:34

<@calvin> 

alright!

ok, mgorse, sorry, it looks like I skipped you too, let’s have you go now

<@MarioC> 

ngao, don’t forget to revamp your classes to our latest changes in the winforms-implementation

<@mgorse> 

ok

I’ve been testing and debugging my cspi work

It now passes events on (although I’m not sure about keyboard/mouse events)

and it can find an app through the registry and load in a tree of objects from it

Next iteration I’m going to continue testing/debugging and work on the hypertext, editableText, and table interfaces

done

<@calvin> 

mgorse: very nice indeed!

07:35

Calen: go

< Calen> 

okay, turn me

i have finished “test coding standard” wiki page.

have updated winforms application samples base on coding standard and also have updated Test_Plan_WinForms_Controls wiki page.

i have been writing and learning a Strongwind test against gtk application(treeview control) as practice. it can be run but still have some problems & questions should be solved by discuss with Brian.

07:36

so i will have worked with Brian to discuss some details about Strongwind test tomorrow.

and i will continue to practice strongwind test against gtk application

done

<@calvin> 

Calen: thanks

decriptor: ok, now I’m pretty sure I don’t see you on the iteration, am I just not seeing it again?

07:37

<@decriptor> 

nope not there yet

I’ll try and make sure I’m on the iteration list for this next round

<@calvin> 

decriptor: ok, you want to cover what you did and have planned?

<@decriptor> 

OBS link: <A HREF=”https://build.opensuse.org/project/show?project=home%3Auia2atk”>https://build.opensuse.org/project/show? project=home%3Auia2atk</A>

07:38

I created that ‘user’ on OBS for joint build stuff, so if anyone needs access let me know (all built stuff should show up on the software.opensuse.com/search page

some of it is still broken, so… working on that

07:39

I’ve been talking on and off with the mono build guys and looking at monobuild to see if we want to use their system as well. They have some test stuff built into their build system

07:40

someone just gave me a suse packagers manual, so I’m making my way through that as well.

for this next time around, hoping to be able to have UIAutomationWinforms and UiaAtkBridge building

07:41

I’m also hoping to have a script in place to automate this stuff…. Work with ray and packaging for different distros namely deb based stuff

07:42

done

<@calvin> 

That sounds really good, hopefull we can start using the builds to roll things out to the test machines

ok, did I skip or miss anyone?

<@decriptor> 

calvin: hopefully

once the uia stuff is in a buildable state, that shouldn’t be too hard

07:43

<@calvin> 

sandy: do you want to briefly cover the parallel mono environment stuff and then the plan for how the assemblies are going to be deployed?

<@sandy> 

sure thing

okay, so I’ve updated this wiki page: Accessibility:_B uildingProviderSide

I plan to keep instructions there

Basically, anybody who is actually going to build our code needs to have some mono stuff from svn installed

07:44

and the safest way to do that is by installing Mono into a completely separate area, and having a completely different environment that you run whenever you want to use that mono installation

the instructions for doing that are here: Parallel_Mono_Environments

07:45

whoops

anyway, I’ll fix that link later

<@knocte> 

heh

07:46

<@sandy> 

once we have packages for the UIA stuff, Olive, and Winforms, people will be able to run our stuff using those packages instead of building it all in a parallel enviornment

but developers will probably want to keep doing everything in the parallel env

<@knocte> 

I wonder if it would be possible to have a parallel env in which you could use our uia stuff, the bleeding edge gtk-sharp,… but *current stable* mono rpms

maybe using symlinks?

07:47

<@sandy> 

knocte: could be

I don’t know

* decriptor 

its fixed

<@sandy> 

setting up a complete parallel mono environment only takes about 30 minutes

plus time spent reading instructions

if you have any questions, I’d be happy to help out

<@knocte> 

that would make things become easier (for example, solving the issue about MD and MonoAddins)

<@MarioC> 

knocte, you can… you don’t need to install mono/mcs, only your development releases

07:48

<@sandy> 

the only problem is that we *do* need System.Windows.Forms

<@knocte> 

MarioC: how?

<@sandy> 

and the easiest way to do that is to install mono/mcs

<@knocte> 

sandy: oh, that’s right! but maybe we can build only MWF separately?

<@MarioC> 

knocte, it’s the same… skip installing mono/mcs, that’s all

<@knocte> 

but as sandy mentions, MWF depends on mcs, and mcs depends on mono, so…

07:49

<@sandy> 

knocte, MarioC, everyone: No matter what, we MUST install and run MonoDevelop from the parallel environment

this is based on the recommendation of the MD developers

<@MarioC> 

in our case we “need to” install because of UIA

<@sandy> 

so we’re not going to have a very minimal install anyway

<@MarioC> 

and we are using latest MD that “needs” latest mono

so… as sandy says, we need mono/mcs anyway

07:50

<@knocte> 

sandy: oh yeah you’re right, unless we could tweak it to launch things under the other mono env

ok

<@sandy> 

it won’t be long before we have a tarball release containing the new SWF, anyway

07:51

so people will be able to install mono/mcs from a stable tarball instead of from SVN

<@decriptor> 

SWF?

<@sandy> 

Winforms

<@calvin> 

sandy: what about the assembly details? (something miguel recommened?)

<@sandy> 

calvin: well, that’s nothing that really needs to concern everyone, but I’ll explain

07:52

<@Ray> 

decriptor: SWF == System.Windows.Forms  :)

<@sandy> 

Miguel wants the UIAutomation* assemblies from Olive installed separately from the 3.0 assemblies in Olive

before, we would install Olive, and our stuff would show up in the GAC, with symlinks in $prefix/lib/mono/3.0

07:53

with my proposed patch, when we install Olive, our UIAutomation* assemblies will still get installed into the GAC, with symlinks in $prefix/lib/mono/a11y, and a mono-uia.pc file will be installed that references UIAutomation* and WindowsBase, allowing people to compile with -pkg:mono-uia (and also allowing our assemblies to show up in MD’s references dialog)

07:54

calvin: the thing I’m a little confused about is how this Olive stuff should get packaged, though

clearly we can package our UIAutomation* stuff in Olive separately

07:55

but it would depend on WindowsBase

I’m just not sure what this is supposed to look like from a packaging standpoint

but I guess that’s not really my problem :-)

<@decriptor> 

:P

ray and I were talking a little bit about that last night

07:56

<@calvin> 

heh, perhaps I’ll walk over and have a discussion with Miguel about this

<@Ray> 

sure

<@decriptor> 

calvin: I’d walk over myself, but well that might take too long :P

<@calvin> 

I’m guessing the reason he wants us packaged outside of Olive is due to the fact we’re very Linux specific, and Olive will go on many platforms including windows

< jpallen> 

so, before we adjourn, i have a question: when are we going to have some completed controls that we can start testing? :)

<@sandy> 

calvin: there are allowances for such things in the makefiles, though

07:57

<@knocte> 

jpallen: I think they could be tested already if QA devs set up their mono env as well

07:58

<@calvin> 

jpallen: I think the issue we are waiting for on testing is the packaging and rollout… the tests should just fail on part of the controls aren’t there

< jpallen> 

ah

07:59

so we’re waiting on decriptor? ;-)

<@decriptor> 

:(

<@calvin> 

jpallen: we have a number of issues that still need to be corrected to get 100% complete controls (in the bridge, the hierarchy, and other issues we discussed above)

yep, it’s all on decriptor

heh

<@decriptor> 

no pressure :)

<@calvin> 

jpallen: I think the changes we’ve been making in the build system (that sandy discussed) will help with that

08:00

< jpallen> 

ok. so can we be ready by the end of this next iteration?

<@calvin> 

decriptor: can you be sure to put in Iteration 5 and 6 your plans and when you think that stuff will be ready to roll?

<@decriptor> 

sure can

08:01

<@calvin> 

decriptor: and as jpallen suggested, the end of this iteration would be best! :)

<@sandy> 

I guess I’ll prioritize the makefile stuff again

and put pressure on the olive guys to review and accept my changes

<@bgmerrell> 

the problem with tests just failing on parts of controls that are not there is that in many cases the expected results of some action depend on the previous action succeeding.

Strongwind, by default, just bails as soon as one action fails.

08:02

<@decriptor> 

let me know about the olive stuff

<@calvin> 

bgmerrell: true, but at least we can start getting some test results

bgmerrell: even if they are all FAILED

<@sandy> 

the sooner we see failing tests the sooner we can fix them :-)

fix our stuff, I mean

<@calvin> 

sandy: oh, you didn’t mean rig the tests?

08:03

<@sandy> 

:-P

<@calvin> 

heh

ok, I think that wraps this up

<@sandy> 

Assert.Pass

<@calvin> 

please go into Iteration 5 and get your stuff updated

Thanks everyone

<@sandy> 

thanks cap’n

08:04

<@MarioC> 

sandy, can I takeover the ListBox provider?

<@bgmerrell> 

Well, what i’m saying is that if i have some app and checking a checkbox fails, Strongwind justs throws a stack trace and goes on to the next test

<@sandy> 

MarioC: that would be great, if you have time

especially since ngao plans on doing CheckedListBox

<@MarioC> 

sandy, I need to… because ComboBox uses it…

<@sandy> 

MarioC: oh, sorry! :-/

08:05

I didn’t realize I was blocking you

* sandy 

begins shame spiral

<@calvin> 

bgmerrell: I understand, but when it throws a stack trace, that is reported as a failure right?

<@bgmerrell> 

calvin: right, but a failure for the whole test, not just that action.

<@MarioC> 

sandy, Ok, I’ll update the schedule.

<@calvin> 

bgmerrell: well, I’m not sure I understand, if this is going to be a problem, isn’t it always going to be a problem, even when we think we have things done all the way?

08:06

<@MarioC> 

done

<@bgmerrell> 

calvin: well, i think it’s the best way to do things. but if we’re trying to test components we know aren’t implmented completely i just don’t think we’ll get very far into the test, but i guess that’s fine for now

08:08

<@calvin> 

bgmerrell: I think for most cases, you’ll find that the controls will check fine, but you may not get the events you expected or something like that… for the most part, the actions and such will work, that’s the easy part

08:09

 

-!- Ray is now known as Ray

brb

08:11

<@calvin> 

bgmerrell: another example, you might have a menu.. the menu works, but if you remove the menu or try to dock it somewhere, that won’t quite work (although I’m not sure we have menu done at all)

but what I’m saying is the fringe cases are the things you’ll find aren’t quite working, that’s why the controls are not 100% done

<@bgmerrell> 

calvin: well, i just remember trying to test the click action for the button control manually and was having pretty rough time testing a single action. maybe something has changed since then.

08:12

<@calvin> 

bgmerrell: I think the problem there was the environment… but we’ll never know until those tests begin to be executed

08:13