[Xcb] Re: Quick XCL, implemented

Jamey Sharp jamey@minilop.net
Tue, 4 Nov 2003 22:57:04 -0800

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 11/04 07:25PM, Jim Gettys wrote:
> On Tue, 2003-11-04 at 11:21, Jamey Sharp wrote:
> > Well, acroread crashes:
> >=20
> > Warning: locale not supported by Xlib, locale set to C
> > Warning: X locale modifiers not supported, using default
> > Fatal System Error: Raise at top of Exception Stack
> > /usr/bin/acroread: line 7:  1229 Aborted /usr/lib/Acrobat5/bin/acroread=
> Exactly: for the moment, you can link the locale files into the new
> location.

OK, that symlink helps a lot. xfontsel and xcalc output no errors now.

Ah. xfontsel and acroread were infinite looping due to a big bug in XCB.
Did I mention that making Xlib use XCB is a really good thing for XCB?

I had allocated a 256kB read buffer in XCB, and then couldn't handle
response packets bigger than that. acroread tried:

XGetImage(d=3D0, x=3D0, y=3D0, width=3D500, height=3D375, plane_mask=3D0xff=
ffffff, format=3DZPixmap)

xfontsel tried:

XListFonts(pattern=3D"-*-*-*-*-*-*-*-*-*-*-*-*-*-*", maxNames=3D1)

Both produced replies that were... just a wee bit too large. I've fixed
this, and tested both apps with a 4kB buffer, and both work. I've never
been so happy to see Acrobat Reader on my screen.

mozilla still dies, though. *sigh*

Ooh, new test case: xine dies too. Apparently it tries to open two
connections, and the second time around the DISPLAY variable has gotten
reset to ""...

> > It looks to me like Gtk+ 1.2 uses the X locale stuff when setting
> > window titles... am I wrong?
> Wouldn't surprise me.

Yup, dillo sets its window title the way I expect now that the symlink
is in place. Yay!
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (GNU/Linux)