[lsb-discuss] LSB 3.2 discussion of X libraries / interfaces

[Wichmann, Mats D]

I was asked to summarize to the list some of the X library
discussion relating to LSB 3.2 or some future release,
since there were some new people listening on today's
confcall who may not have seen the earlier discussions.

Please take this as another invitation to run with the
discussion!

First off, the page I referred to where information on
things under serious consideration is being gathered is
here: http://www.freestandards.org/en/ProjectPlan32
(hint: if you plan to edit that page you'll save time by
entering it directly using https: instead of http:, that
way you won't have to navigate back after authenticating).

Based on requests from the FSG Accessibility workgroup,
we're taking a look at a set of X Extension libraries:

Xcomposite, Xdamage, Xfixes, Xrender

While nobody has raised any objection to these yet, and in 
fact they've been on our "A" list for a long time, they do 
still need to meet the criteria for inclusion which involve
specification, tests, etc. Extension libraries are a little
interesting to test as they don't make a lot of sense without
the extension (you can make sure the relevant QueryExtension
interface exists and returns something sensible but that's 
about it). But LSB does not require or specify an X server and
thus says nothing about the extensions themselves. That means
we may get into trouble we've gotten into before: in trying to
test that the ABI works correctly we will be stressing a 
component (the extension) that is not itself part of the LSB.
Just to bear in mind. Can tests sensibly be run against a 
suitably built/configured Xvfb (which is our answer to this 
problem otherwise)?

Also from A11y, there's a request to make sure the Shape 
extension v1.1 is required.  Shape, with interfaces in libXext,
has been in LSB, but is not specific as to version.

The other request I was pursing was to add a set of
Xlib multibyte character interfaces:
Xutf8DrawString
Xutf8TextExtents
Xutf8TextEscapement

I had originally responded that we had some Xutf8 interfaces,
but not all, in the current spec and maybe we should look at 
the rest, but got fairly strong pushback that this was the 
wrong way to go (and that possibly, the existing Xutf8 interfaces
were included in error). Here's one comment:

===
The problem is the UTF-8 interfaces all require huge translation tables
to get from UTF-8 to whatever font encoding is present on the system.
Having the low level protocol library responsible for transcoding text
is a *bad idea* on so many levels.

Applications interested in UTF-8 text APIs should be using Xft, cairo,
Gtk+ or Qt, all of which provide this encoding without requiring
Xlib-level iconv-ish support.
===

Of course, for an app which is not presently using Gtk+/Qt to
have to switch to doing so to get UTF-8 capability is a bit
heavyweight, and since cairo isn't in the LSB yet and isn't on
the list for this release, I've added Xft to the list of libraries
we should be considering.


Also a disclaimer:  I'm filling this stuff in so it gets
researched and recorded, but we don't have a resource 
committed (yet) to the steps to get these things in, nor
in fact a decision that they're going into LSB 3.2. The
discussion here will help drive that choice.

-- mats