[Xcb] Re: Quick XCL, implemented

[Jamey Sharp]

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

I should probably have described Mozilla's symptom, eh? It starts,
outputs nothing, creates no windows, and exits with status 1 a second
later. Looks like Debian's /usr/bin/mozilla might be interfering with my
testing some, since it modifies LD_LIBRARY_PATH, but I don't think
that's the problem...

I notice I'm having some trouble testing my patch due to a lack of X
apps on my laptop. I almost never run anything but xterm and Mozilla. :)
xfontsel and xcalc produce this output on my patched Xlib, and xfontsel
hangs:

Warning: locale not supported by Xlib, locale set to C
Warning: X locale modifiers not supported, using default
Warning: Unable to load any usable fontset

On 11/03 09:58AM, Christopher Blizzard wrote:
> Mozilla uses pthreads.  ...  I'm betting you're not seeing something
> thread-related.

I believe you. I did think it would be a strange failure mode for a
threading problem.

> There are some interesting things that Mozilla does do, though.  We do
> hunt around in the queue from time to time looking for certain events
> and removing them.

My current patch pulls all events out of XCB's queue and into Xlib's
whenever _XEventsQueued or _XReadEvents is called, so if what you're
doing causes those to run, then that should be fine.

_XFlush doesn't fill the event queue now, though. I can change that
easily if y'all tell me I should. I didn't do it because I couldn't
decide if that was part of _XFlush's contract. (If _XFlush should do it,
_XSend should do it too, right? _XReply too, maybe?)

By the way, I generalized "hunting around in the queue" for XCB. You
pass a predicate function to XCBEventQueueRemove or XCBEventQueueFind
(depending on whether you want to remove the event from the queue or
not), and it returns the first match or a null pointer if none. I need
to fix up the interface a little, but confirmation that it's useful
would be nice.

> Also when we load plugins that use Xt ...

I don't think it's getting that far. Fascinating issue though.

On 11/03 09:19AM, Jim Gettys wrote:
> Also note that Xt/Motif brings in other dependencies, on the Xlib
> locale implementation, Xmu, and the like, that GTK apps don't care
> about ...

I really do expect everything inside Xlib and extensions to work with my
patch, as long as it works in the fd.o source I started with. My
expectations seem to not be being met though.

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

> An easy way to check this out is to run a convenient Motif app; about
> the only one I personally run regularly any more is Acrobat reader
> (acroread).  Note that the X locale stuff isn't working this instant
> on fd.o Xlibs; we have to autofoo it yet.

Well, acroread crashes:

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 "$@"
--=20
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/p9IaNgAXSpyH6VcRAlaWAJ97SoS0VdbdNAcMS4FNMlhe/fHBYQCfZO9c
0zTW6zZoI3/ribql9VIEAeg=
=oal+
-----END PGP SIGNATURE-----

--FeAIMMcddNRN4P4/--