14:05:32 <API> #startmeeting
14:05:32 <Services> Meeting started Thu Jun  5 14:05:32 2014 UTC.  The chair is API. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:32 <Services> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:05:50 <API> #topic Progress towards 3.14
14:05:59 <API> #info bug 730118
14:05:59 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730118 normal, Normal, ---, gnome-shell-maint, NEW, GtkTreeView very slow since 3.12
14:06:16 <API> #info not a lot of moving forward on the but
14:06:23 <API> #info I asked to test my patch and nobody did it
14:06:40 <API> #info Jasper made some questions about the solution, I replied
14:07:04 <API> #info not clear if they are willing to apply it on gnome-shell, or if they prefer to move it to at-spi2-core
14:07:18 <API> #action API will try to ping Jasper on IRC, to have a conclusion
14:07:34 <API> #info bug 730505
14:07:34 <Services> 04Bug http://bugzilla.gnome.org/show_bug.cgi?id=730505 normal, Normal, ---, at-spi-maint, UNCONFIRMED, Draft for atspi tests
14:07:43 <API> #info API made a new review of the patch
14:08:37 <API> #info the major question is about why they use a custom solution to get, load and execute the tests (based on gmodule) and not the GTest utility methods already available on glib
14:08:45 <API> #info that are already in use for clutter and gtk+
14:08:49 <API> done
14:08:51 <API> thats my part
14:08:56 <API> questions, doubts?
14:09:02 <mgorse> Thanks for that review
14:09:07 <API> mgorse, no problem,
14:09:11 <API> at this stage
14:09:22 <API> I'm just catching the evident stuff
14:09:47 <mgorse> I'm pretty sure there are a bunch of at-spi bugs that need my attention. Writing myself a note to look at them this weekend
14:09:48 <API> when we get a mature patch, I would ping you for a final review, just to ensure that everybody agrees
14:10:00 <API> yes, for that reason
14:10:05 <API> focusing on the testsuite now
14:10:10 <API> more when is a draft
14:10:15 <API> is not a priority
14:10:22 <API> so you could focus on actual bugs
14:10:35 <API> we will bother you when it loses the draft status
14:10:41 <API> btw, and related to the test suite
14:10:53 <API> I was thinking that another possible use
14:11:02 <API> could be testing the cache
14:11:18 <API> I mean, ideally tests should be repeteable
14:11:31 <API> it would be good to check if it is possible to add some kind of time measures
14:11:43 <API> and then add tests to check the time to get some stuff
14:11:49 <API> and compare cache vs non-cache
14:12:16 <API> probably that is too early at this stage, as we are still on the first version of unit tests
14:12:27 <mgorse> We'd need to mimic the use case of an AT such as orca for that to really be useful
14:13:09 <mgorse> ie, getting the name or parent would take longer without the cache, and the amount of time that saves would depend on the number of times we get the name and parent relative to doing other things
14:13:14 <API> yes, it would be needed to do something
14:13:21 <API> like get an orca log
14:13:28 <API> from a user
14:13:36 <API> and extract the calls
14:13:56 <API> so the specific test would be something like "execute normal user log"
14:14:40 <API> anyway this is a wild idea based on the fact that someone is adding tests
14:15:03 * patryk_ reading
14:15:04 <API> if there is any easier way to do that, ie, directly with orca
14:15:12 <API> joanie, ?
14:15:20 <API> opinions?
14:15:32 <joanie> Orca can be used with and without caching
14:15:41 <joanie> and I could create all the "user logs" you'd like
14:16:10 <patryk_> API, thanks for the review
14:16:10 <mgorse> Actually, that's a good point, that orca already logs times for processing events
14:16:39 <joanie> it would be easy enough for me to test this
14:16:46 <joanie> but feel free to do it yourself
14:16:48 <API> joanie, it would be possible to repeat exactly the same user interaction with orca?
14:16:53 <joanie> of course
14:17:13 <API> ok, then my  idea was just a uninformed rant
14:19:34 <API> joanie, so at some time, would it be possible to get some (two or three) usual user interaction logs and their times?
14:19:35 <patryk_> API, what about this test framework, those which I had used is "check" from ubuntu repos
14:19:49 <joanie> of course
14:19:54 <API> joanie, ok, thanks
14:20:11 <patryk_> should I change it to this one which is used in glib?
14:20:48 <API> patryk_, well, right now, the patch has a lot of custom code
14:20:56 <API> do you mean that you copied that code from ubuntu repos?
14:21:13 <patryk_> no, I hadn't
14:21:36 <patryk_> I had used unit test framework named check
14:21:48 <patryk_> which is in ubuntu repositories
14:22:27 <patryk_> ofcourse I can change framework to clutter
14:22:47 <API> well, is glib
14:23:09 <API> I used clutter as a example of module using glib g_test  methods
14:23:31 <API> in any case, I mentioned it just to know if there was a specific reason
14:23:37 <API> I will take a look to check
14:23:44 <API> and then add a new comment on the bug
14:23:46 <API> is that ok?
14:23:53 <patryk_> yes :)
14:24:32 <API> ok
14:24:40 <API> so, going back to the topic of the meeting
14:24:40 <patryk_> I had used it because I had some expieriance with it previously
14:24:50 <API> patryk_, ok
14:24:55 <API> so, going back to the topic of the meeting
14:25:12 <API> anyone else want to share something on the current topic?
14:25:57 <patryk_> I had one more
14:27:15 <patryk_> You mentioned something about testing cache by orca, can you explain, I do not understand that clearly
14:27:15 <API> patryk_, go on please
14:27:26 <API> at-spi2 uses a cache
14:27:34 <API> as far
14:27:36 <API> as we know
14:27:46 <API> it was added because when at-spi2 was started
14:27:46 <patryk_> yes, I know:)
14:27:53 <API> there was concerns about performance
14:28:06 <API> as initial investigation concluded that DBUS was slower that CORBA
14:28:13 <clown> !
14:28:13 <API> (at-spi1 was written on CORBA)
14:28:27 <API> so developers added a cache to improve that
14:28:30 <API> but
14:28:45 <API> there is no registry saying at all that the cache is really helping to improve the performance
14:28:48 <API> and at the same time
14:29:07 <API> the cache is making the design and the inter-operability more complex
14:29:15 <API> on the last weeks
14:29:26 <API> we were talking about checking if the cache is helping or not
14:29:51 <API> that is the reason I suggested about using this new testsuite
14:30:03 <API> but joanie already mentioned that orca already supports
14:30:13 <API> running user interactions+time measures
14:30:23 <API> so that would be quickier and more efficient
14:30:34 <joanie> yeah, I can do some tests later
14:30:46 <API> patryk_, does this explanation answer your question?
14:30:53 <joanie> and see if in real-world use cases there is a major difference
14:30:58 <patryk_> yes, thanks a lot
14:31:24 <patryk_> now it is clear
14:31:33 <API> ok
14:31:37 <mgorse> Fwiw, my guess is that there will be, although there are probably better ways of handling it that are less error-prone. But doesn't hurt to actually test
14:31:52 <API> mgorse, yes, probably there will be an improvement
14:32:20 <API> the question is if the improvement is big enough to justify a so error-prone
14:32:24 <API> solution
14:32:31 <API> having said so,
14:32:35 <joanie> but potentially I could obtain those results by reducing the calls in Orca
14:32:36 <API> moving to next tpic?
14:32:46 * joanie nods re moving
14:32:47 <API> joanie, yeah
14:32:49 <API> or at orca
14:32:54 <API> or at at-spi2-atk
14:33:10 <API> I mean that probably there are places to improve the communication
14:33:19 * joanie nods
14:33:24 <API> ie: that event flood from gtktreeview will not be solved by caching
14:33:35 <API> but by a better event dispatching
14:33:56 * joanie nods again
14:34:03 <joanie> floods suck
14:34:38 <API> as nobody is raising the hand to add more info on this topic
14:34:42 <API> #topic W3C updates
14:34:48 <API> joanie, clown ?
14:34:51 <clown> hi there!
14:34:56 <joanie> hey there!
14:34:59 <joanie> :)
14:35:02 <clown> I'll start...
14:35:17 <clown> #info First working draft of spec and implemantation mappings for 1.1 is on track for June 12
14:35:34 <clown> #info I need to make a few more edits to the mappings re:  changes to ATK/AT-SPI requested last Dec/Jan., and I plan to finish that by tomorrow.
14:35:59 <joanie> yay
14:36:13 <clown> #info reminder:  the ARIA working group agreed to these changes last Dec/Jan, but only if they were done in the 1.1 timeframe.
14:36:33 <clown> #info New:  in 1.1, listbox items and tree items no longer support aria-checked.
14:37:18 <clown> #info at the last UA telecon, some of use started wondering if there truly were no examples of check-able listbox items (for e.g.).
14:37:33 <clown> #info Some are still invesitgating.
14:37:44 <clown> done, if not questions, do you have anything to add joanie?
14:37:50 <clown> *no questions
14:37:51 <joanie> nothing to add
14:37:59 <API> ok thanks
14:38:02 <API> no questions from my side
14:38:27 <joanie> clown: though I did find potential checkable listbox items
14:38:47 <joanie> that's going to be a fun topic to bring up
14:38:48 <clown> yes, and bryan sent email recently about an example he found
14:38:57 <clown> but, I haven't looked at it yet.
14:39:25 <clown> in related thread on another email list, Alex is suggesting ditching 'undefined' for aria-checked.
14:39:40 <clown> it used to mean "this accessilbe is not check-able".
14:39:59 <joanie> now it means?
14:40:28 <clown> But, since aria-checked is only avaiblable on checkboxes, radio buttons, menuitemcheckboxes, radiomenuitems, it seems redundant since all those are inherently check-able.
14:40:57 <joanie> ah
14:41:03 <clown> If aria-checked is brought back to support listbox items, then it will be necessary to indicate that some items are not check-able.
14:41:36 <clown> and one would want to have an notion of aria-checked being undefined for those cases.
14:41:37 <API> heh, we have a similar issue with atk
14:42:04 <joanie> but we added STATE_CHECKABLE to ATK
14:42:07 <API> we have state-checked and state-checkable
14:42:10 <API> yes
14:42:19 <clown> right.
14:42:20 <API> but the thing is that recently we are adding a lot of -able states
14:42:25 <API> if my memory is correct
14:42:41 <clown> you are probably representing various "affordances" (sorry for the UI speak).
14:42:43 <API> at some point we talked that the need of adding so many -able states is strange
14:42:58 <joanie> it's needed
14:43:02 <API> that probably atk should have something to specify which states an accessible can have
14:43:08 <API> without the needed of adding -able states
14:43:35 <clown> well, there are object properties.  *quickly hides from joanie*
14:43:37 <clown> :-)
14:43:42 <joanie> heh
14:43:47 * joanie shakes her fist
14:43:50 <API> probably one option would be have a atk_object_get_current_states, and an atk_object_get_possible_states
14:44:06 <joanie> that might work
14:44:09 <API> so if get_possible_states returns CHECKED, then means that is CHECKABLE
14:44:22 <API> but as I said, we talked about this a long time ago
14:44:31 <API> dont' remember our conclusion (if any)
14:44:32 <clown> i know that java a11y had a state-set object associated with an accessible.
14:44:56 <clown> but, that was even longer ago.
14:45:39 <API> #action API will try to find the discussion about -able states on atk/at-spi
14:45:48 <API> in any case, those were my comments/random rant
14:45:53 <API> so anything else in this topic?
14:47:54 <API> no replies, I will assume a no
14:48:06 <API> #topic Miscellaneous time
14:48:15 <API> (skipping marketing as jjmariin is not here)
14:48:22 <API> so something miscellaneous to comment today?
14:48:29 <joanie> I've got one for clown
14:48:30 <API> (nothing from my side)
14:48:41 * clown is listening
14:48:50 <joanie> So I'm working on fixing the presentational children of tables and lists for webkit
14:48:56 <joanie> and I have it mostly working
14:49:03 <joanie> but it raised a question
14:49:12 <joanie> if you have a presentational list item child
14:49:16 <joanie> we want the text
14:49:24 <clown> yup.
14:49:24 <joanie> but do we want the list marker as well?
14:49:30 <joanie> on the one hand, yes, it's on the screen
14:49:34 <clown> eewwww.
14:49:40 <joanie> on the other hand, what is the use case for this?
14:50:03 <joanie> I'll probably include the marker, though it will be a sad hack
14:50:03 <clown> the odd thing is that the list marker is not in the DOM text, but is added by the browser (depending on the list styles).
14:50:14 <joanie> right
14:50:17 <clown> At least, that's true in fire fox.
14:50:59 <joanie> so whether or not to include the list marker for presentational children is something I don't have an answer for
14:51:04 <clown> And in an actual list, it's desirable to expose the list markers (bullets, numbers, whatever) to AT.
14:51:06 <joanie> because I don't know why a web devb would do it
14:51:11 <joanie> right
14:51:31 <clown> Here's my thoughts (rough).
14:51:50 <clown> List markers are subject to certain CSS rules.
14:52:15 <clown> In fact, web devs can remove them, even from actual lists, with CSS.
14:52:45 <clown> *If* they are using a list purely for presentation, it's their job to use the appropriate CSS to remove the markers.
14:53:23 <clown> Otherwise, it looks dumb from a non-AT perspective — all the styling is set to be a non-list, except the list markers are still there.
14:53:35 <clown> That must look wrong.
14:53:55 <clown> And, if they do remove the list markers using CSS, the browser doesn't add them any more.
14:54:06 <clown> And the markers should not appear in the a11y tree.
14:54:19 <clown> Conclusion:  it's the web developer's job.
14:54:26 <clown> done.
14:54:29 <joanie> :)
14:54:30 <clown> (for now).
14:54:41 <joanie> but let's say the web dev leaves them in because he/she sucks
14:55:04 <joanie> I'm thinking of the regression test I'm going to have to write for the patch I'm going to submit
14:55:32 <joanie> though I'm tempted now to go sans list marker
14:55:47 <joanie> why add a sad hack that shouldn't be needed if the content creator does the right thing (tm)
14:55:48 <clown> I suppose we could make a rule that if list items are presentational, browsers should no expose the list markers at the a11y level.
14:55:58 <clown> But, you'd have to get the browser vendors to all agree....
14:56:07 * joanie nods
14:56:23 <joanie> maybe we can bring this up at the next UAIG meeting
14:56:37 <joanie> anyhoo, that's all my misc time stuff
14:56:39 <clown> yes, and perhaps even at the main meeting.
14:56:48 * joanie nods
14:56:50 <clown> Good question, joanie.  Made me think.
14:56:57 <API> "you'd have to get the browser vendors to all agree"
14:57:02 <API> seems easy
14:57:15 <joanie> it might be
14:57:26 <API> good to see you so optimistic
14:57:28 <API> having said so
14:57:28 <joanie> I can see what safari does
14:57:36 <API> anything else? closing meeting?
14:57:39 <clown> Oh, I have one for joanie, and possible you API
14:57:49 <API> clown, shoot then
14:57:55 * joanie ducks
14:58:12 <clown> After the changes to the UAIG mappings for ATK/AT-SPI are done, various browsers will be "non-conformant".
14:58:20 <clown> Someone has to open bugzillas agains them.
14:58:25 <clown> *against
14:58:57 <joanie> webkitgtk will be largely compliant already
14:58:59 <clown> Example:  in aria 1.0 role="article" was mapped to ROLE_DOCUMENT_FRAME.
14:59:04 <joanie> though I noticed not for listboxes
14:59:18 <clown> in aria 1.1, it becomes ROLE_ARTICLE.
14:59:25 <joanie> I can do the webkitgtk changes
14:59:34 <clown> I'm sure FF is still doing ROLE_DOCUMENT_FRAME.
14:59:44 <clown> cool, joanie.  That's good.
15:00:20 <joanie> #action Joanie will file bugs in the webkit bugzilla for the needed ARIA 1.1 changes.
15:00:27 <joanie> #info She'll probably fix them too.
15:00:36 <clown> The nice thing is that there are test cases from testing 1.0 that would show the bug due to the new mappings.
15:00:47 <joanie> cool
15:00:59 <joanie> clown: perhaps you and I could work on that as well?
15:01:25 <clown> btw, I have spoken to david bolter about this, and he was generally welcoming:  please file bugs.
15:01:36 <clown> "clown: perhaps you and I could work on that as well?"
15:01:43 <clown> yes, perhaps.
15:01:47 <joanie> heh
15:01:51 <clown> :-)
15:01:52 <joanie> we'll figure it out
15:01:55 <clown> "time permitting".
15:01:59 * joanie nods
15:02:03 <clown> yah, we'll figure it out.
15:03:00 <API> ok, thanks everybody
15:03:10 <API> if nobody objects, now is a good moment for closure
15:03:18 <patryk_> one more thing :)
15:03:22 <joanie> hehehehe
15:03:23 <clown> is that a lambda function, API?
15:03:32 <API> patryk_, yes?
15:03:33 * clown please ignore the clown
15:03:47 <patryk_> I had question not related to testing :)
15:04:07 <patryk_> My friend is working on accessibility in enlightment
15:04:11 <API> go ahead, but short please, we are alrady over time
15:04:19 <patryk_> and he asks about atspi-constants.h
15:04:39 <patryk_> it is ABI stabile?
15:04:44 <API> sincerely, for a toolkit
15:04:44 <patryk_> or not
15:04:55 <API> it would be easier to just add ATK support
15:04:59 <API> well
15:05:18 <API> to provide the accessible objects as ATK objects
15:05:23 <API> and then use the atk bridge
15:05:37 <API> if not, they would need to create a new at-spi bridge
15:05:48 <API> like the already existing atk-bridge or the qt-at-spi
15:05:57 <API> on qt that made sense
15:05:59 <mgorse> Is Enlightenment glib-based? I can't remember
15:06:03 <patryk_> yes, he creates, but based on  atspi-constants.h enums
15:06:13 <API> because they already had their own accessible objects
15:06:17 <API> <mgorse> Is Enlightenment glib-based? I can't remember
15:06:20 <API> no afair
15:06:22 <API> <patryk_> yes, he creates, but based on  atspi-constants.h enums
15:06:26 <API> I don't follow
15:06:36 <API> is he adding atk objects but using atspi-constants.h?
15:06:37 <patryk_> he creates his own bridge
15:06:46 <patryk_> but it is not based on glib
15:06:56 <API> ah ok, he is creating his own bridge
15:07:07 <patryk_> by to be compatible with accessiblity clients
15:07:08 <mgorse> Those enums should be stable, anyhow
15:07:30 <API> <patryk_> by to be compatible with accessiblity clients
15:07:36 <API> compatible with accessibility clients?
15:07:48 <API> I don't see why creating their own bridge would help with that
15:08:09 <API> could you elaborate?
15:09:03 <patryk_> yes, in enlightment, he implement atspi
15:09:49 <API> yes, creating your own at-spi bridge is one of the options
15:09:51 <patryk_> and he uses constants from At-spi2-core
15:09:55 <API> if you don't want to use atk
15:10:01 <patryk_> correct
15:10:03 <joanie> but why not use ATK?
15:10:07 <API> but I don't see how that improves the compatibility with accessibility clients
15:10:14 <patryk_> to be glib independent
15:10:45 <joanie> and I assume it means there will be another dependency for users (yet another bridge)
15:11:20 <patryk_> I do not know details, he just asked me If atspi-constanst.h is ABI stable
15:11:41 <API> patryk_, if the problem is being independent of glib
15:11:42 <joanie> doesn't at-spi2 require glib?
15:11:53 <joanie> i.e. an accessible environment will have glib
15:11:54 <API> not sure why he is worried about atspi-constants
15:12:08 <API> joanie, but going extreme
15:12:17 <patryk_> because he uses enums from it
15:12:29 <API> patryk_, but that file is also glib based
15:12:35 <API> well, afair
15:12:38 * API looking
15:12:47 <API> oh well
15:12:49 <API> is mostly C
15:12:59 <API> I mean, it doesnt use anything from C
15:13:02 <API> and it is true
15:13:09 <API> I think that qt-at-spi is also using it
15:13:29 <mgorse> Changing those enums would cause problems for C programs that use libatspi, anyhow
15:14:10 <API> in any case, as joanie mentioned, using libatspi2 directly would include a dependency to glib
15:14:23 <API> although it would be possible to just copy that header
15:14:39 <patryk_> but there is not libatspi usage, only atspi constatns
15:14:42 <API> and start to do the proper wrapping on DBUS to avoid the glib dependency
15:14:46 <patryk_> which is only set of enums
15:14:51 <API> patryk_, yes what I mean
15:14:55 <API> is that qt-atspi
15:14:59 <API> doesn't use a lot of libatspi2
15:15:05 <API> afair, that enums file
15:15:11 <patryk_> it is the same as qt-aspi but in Enlightment
15:15:15 <API> but they decided to avoid copy that document
15:15:19 <API> and just add the dependency
15:15:22 <patryk_> so it is named elm-atspi
15:15:30 <API> so I guess that on elightment
15:15:36 <patryk_> the same does he
15:15:39 <API> they plan to just copy the relevant headers
15:15:50 <API> and do the wrapping to avoid the glib dependnecy
15:16:32 <API> is more work that just creating ATK objects, but I guess that avoiding the glib dependency is really mandatory
15:16:51 <API> having said so
15:16:57 <joanie> end the meeting
15:16:59 <API> patryk_, did mgorse replied your question?
15:17:00 <joanie> :)
15:17:08 <patryk_> yes
15:17:42 <API> ok, so
15:17:44 <API> #endmeeting