[BRLTTY] Low-level BrlAPI questions

Aura Kelloniemi kaura.dev at sange.fi
Sat May 8 16:31:38 EDT 2021


On 2021-05-08 at 22:07 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Dave Mielke, le sam. 08 mai 2021 15:46:41 -0400, a ecrit:
 > > [quoted lines by Samuel Thibault on 2021/05/08 at 20:05 +0200]
 > > 
 > > I personally think that that one (display size) shouldn't be marked as an array.

 > Ok.

 > I however eventually digged back into the git log, and this isArray
 > was really introduced to determine, as documented, whether there is
 > to be possibly several values, or always one. That's notably used in
 > the Python bindings to know whether it shall return, when one value
 > is returned, an array of one value or directly the value. That's
 > contradictory with what you wrote above. I don't think we want to
 > distort the original aim of the field, and keep it as is is. Which
 > indeed means that if isArray is not 1, count cannot be 1.

As far as I know, all currently public API bindings that support parameters
and utilize parameter property information are internal to BRLTTY. From the
perspective of a binding writer, I wish that there is a clear and
non-ambiguous mechanism of determining the number of elements in a parameter
value.

My opinion (if you are interested) is that count should tell the number of
elements, always, unless the number is variable in which case count could be
set to a special value, like 0 or -1. isArray should tell whether the data
type is an array, rather than the values being conceptually separate – e.g. in
Python the value would probably be a tuple, if the property's count > 1 and
isArray == 0.

 > Actually I don't know what count is used for, we don't use it in the
 > client library or the server. Do you remember why you introduced it?

I would like to use count for allocating the right amount of memory, and
isArray for determining the data type for the memory contents.

-- 
Aura


More information about the BRLTTY mailing list