ax_dump testsuite/tools output format

56 views
Skip to first unread message

Alexander Surkov

unread,
May 17, 2021, 10:56:42 AM5/17/21
to Chromium Accessibility
Hi. I was working lately on output format unification for platform tree formatters. There's some discrepancy between point/size/rect structure formats. In particular, mac uses point={x: num, y: num} and size={w: num, h: num}, while blink/win use point=(num, num) and size=(num, num), which makes mac format explicit but more bulky.

Do you have any preferences on which format should be used?

Here are examples for your reference:

Thanks!
Alexander.

Alexander Surkov

unread,
May 18, 2021, 9:46:27 AM5/18/21
to Chromium Accessibility, Dominic Mazzoni, Nektarios Paisios, Aaron Leventhal
Hey. There's also an issue about lists formatting. Mac sticks with JS style, i.e [item1, ..., itemN], see [1], while win/blink use (item,..,itemN) to format coordinates, see [2] and linux use () as well for arrays, for example, headers=('First', 'Second), see [3]. Using parentheses for coordinates formatting looks classic, JS style looks more regular for lists. Considering we have Value::Type::DICTIONARY and Value::Type::LIST only to describe all structures, it'd be nice to stick with the same format for all dictionaries and with the same format for all lists to avoid any special cases, so if we use {} for a dictionary, then we can't use () to describe coordinates described by a dictionary, and if we use [] for a list, then we can't use () for coordinates if they are described by a list. So

1) how do we expose a dictionary, mac way { key: value }, linux way: ( key: value )
2) how do we expose a list, mac way: [item1, item2], win/blink (coord1, coord2), linux: (item1, item2)

I would avoid creating any special support for coordinates (similar to what we have now), it complicates code and increases testing scenarios. It'd be nice to handle it in a unified way.

Any thoughts? Any preference?


Dominic Mazzoni

unread,
May 26, 2021, 12:51:00 PM5/26/21
to Alexander Surkov, Chromium Accessibility, Nektarios Paisios, Aaron Leventhal
No really strong preference for coordinates. I feel like x coordinates before y coordinates is super common, so I'd probably vote for not including x=, y=.

I'm fine with something like:
location=(0, 300) size=(300, 150)

To be super compact, we could try:
bounds=(0,300 size 300x150)

I definitely prefer brackets [] since that's how arrays work in almost all languages, and similarly {} for dictionary-like things.

I'd be fine with coordinates looking like a dict if that simplifies the syntax, so maybe bounds={x: 0, y: 300, width: 300, height: 150}. However, it's important that they're in that order. I wouldn't be happy if we used a generic dictionary outputter that sorted the keys and we got bounds={height: 150, width: 300, x: 0, y: 300} - I'd find that a lot less readable.

Alexander Surkov

unread,
May 26, 2021, 3:33:43 PM5/26/21
to Dominic Mazzoni, Chromium Accessibility, Nektarios Paisios, Aaron Leventhal


On 2021-05-26 12:50 PM, Dominic Mazzoni wrote:
No really strong preference for coordinates. I feel like x coordinates before y coordinates is super common, so I'd probably vote for not including x=, y=.

I'm fine with something like:
location=(0, 300) size=(300, 150)
If there's a strong support for this syntax or any other special syntax for coordinates/size/bounds then I think we could use specialized dictionaries, for example, dict { location/size/bounds: dict { x: v1, y: v2, w: v3, h: v4 } } to store location/size/bounds. If we have common formatting, then it's not the issue, we just should make sure we use a common procedure to create such structures.


To be super compact, we could try:
bounds=(0,300 size 300x150)

It is short indeed, feels fancy but might be ok. Apparently there's no standard way for the rect structures. I suppose the most common one is (x, y, width, height) but it has no semantics.

This is also a special case for parsers if somebody wants to parse. Does chrome://accessibility need any special support for those?


I definitely prefer brackets [] since that's how arrays work in almost all languages, and similarly {} for dictionary-like things.

I'd be fine with coordinates looking like a dict if that simplifies the syntax, so maybe bounds={x: 0, y: 300, width: 300, height: 150}. However, it's important that they're in that order. I wouldn't be happy if we used a generic dictionary outputter that sorted the keys and we got bounds={height: 150, width: 300, x: 0, y: 300} - I'd find that a lot less readable.

We do support ordered dictionaries, so, for example, mac exposes bounds={x: 0, y: 300, width: 300, height: 150} right.

So the easiest way to unify formatting is to not have special cases for sure, but it's still doable and should be ok if all the logic is in between tree formatters and readers, i.e. nobody is going to parse output or use dictionaries.

Also I'm not sure if we have to take the decision now considering how easy to rebaseline all expectations. I guess we could take the easy way and then improve it later?

Dominic Mazzoni

unread,
May 27, 2021, 7:28:07 PM5/27/21
to Alexander Surkov, Chromium Accessibility, Nektarios Paisios, Aaron Leventhal
On Wed, May 26, 2021 at 12:33 PM Alexander Surkov <surkov.a...@gmail.com> wrote:

We do support ordered dictionaries, so, for example, mac exposes bounds={x: 0, y: 300, width: 300, height: 150} right.

So the easiest way to unify formatting is to not have special cases for sure, but it's still doable and should be ok if all the logic is in between tree formatters and readers, i.e. nobody is going to parse output or use dictionaries.


I hadn't thought about parsing. I'd be happy with an ordered dictionary like {x: 0, y: 300, width: 300, height: 150} - it's readable and easy to parse. 

Also I'm not sure if we have to take the decision now considering how easy to rebaseline all expectations. I guess we could take the easy way and then improve it later?

Agreed.
 
Reply all
Reply to author
Forward
0 new messages