[BRLTTY] Low-level BrlAPI questions

[Samuel Thibault]

Aura Kelloniemi, le mer. 14 avril 2021 22:13:45 +0300, a ecrit:
> On 2021-04-14 at 14:27 -0400, Dave Mielke <Dave at mielke.cc> wrote:
>  > I might as well throw in my opinion: To me, it's the region size that should define the cell count, and it's the exact cell count that matters. Text and masks can be padded/truncated as necessary to fit the cell count. And, to me, a region size of 0 could mean from begin to the end.
> 
> I agree.

That is actually what we currently have, see the
BRLAPI_WRITEARGUMENTS_INITIALIZER documentation:

“
regionBegin = regionSize = 0; (update the whole display, DEPRECATED and will
be forbidden in next release. You must always express the region you wish to
update)
”

We warned about forbidding that because we don't really want the
andMask/orMask to be only *implicitly* of size cell count. Think what
would happen if the display happens to get resized in the middle of all
of this.

>  > Using the text size to define the cell count is imprecise.
> 
> yes, and it should not be used for that purpose, basicly because of UTF-8.

Right, it's complex to determine the number of actual characters.

But we do not want to pad by default, since existing applications may
have been using it to perform partial updates.

We could introduce a flag to specify that truncation/padding is desired.

We could either

- add a flag field to brlapi_writeArguments_t, which requires bumping
  the soname ABI compatibility *and* protocol version.

- just apply the flag (as a high bit) to the regionSize field. Older
  servers will simply reject it with an invalid value exception.

>  > What a user typically wants to do is to write some text without worrying
>  > about anything other than having it written. He/she expects the interface
>  > to worry about things like truncating, padding, wrapping, etc. It's kind of
>  > like expecting an HTML writer to need to know the precise rendering width.

I don't think we are at the HTML writer level, and rather at the text
rendering level. I don't think we want applications to be fine with
their text being silently truncated by default, notably...

>  > As I see it, there really should be no need at all for a simple client
>  > writer to ever need to ask the size of the display.
> 
> How would you achieve that? The client needs to implement scrolling, because
> even the shortest messages don't fit on every braille display without
> wrapping.

That's the problem, yes. In BrlAPI we followed the Xorg/wayland way: the
server provides the rendering information, and the client can then
manage rendering as it sees fit.

> Well of course it is possible to develop a client library, which provides
> facilities for reading contiguous texts, for example,

Yes, just like gtk provides one.

Sébastien Hinderer wrote:
> I think when we wrote BrlAPI (and later, too), we had the idea that a
> higher level library could be developed on top of what exists to do the
> kind of things you describe

Yes, it just has never materialized.

> Whether that kind of facilities should be made available at such a
> low-level, or whether it's fine to have an intermediate layer, that I
> don't really know.

I believe it'd better be at an intermediate layer, to keep the BrlAPI
protocol as simple as possible.

Dave Mielke, le mer. 14 avril 2021 15:52:18 -0400, a ecrit:
> To see how I think it should be done, you may wish to have a look in the Java bindings at WriteArguments#check().

But it is assuming that it can get the size of the masks. You cannot
have that in C. That's why the C version just documents that their size
is regionSize.

Samuel