[Xcb] Re: Quick XCL, implemented
Jamey Sharp
jamey@minilop.net
Tue, 4 Nov 2003 08:21:46 -0800
--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/--