[Xcb] Re: [Xlibs] Re: Quick XCL, implemented
Christopher Blizzard
blizzard@redhat.com
Tue, 04 Nov 2003 11:42:57 -0500
This is a multi-part message in MIME format.
--------------050505070904050108050803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Jamey Sharp wrote:
>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:
>
That usually happens when the xremote stuff silently fails.
--Chris
>
>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 "$@"
>
>
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------
--------------050505070904050108050803
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Jamey Sharp wrote:<br>
<blockquote type="cite" cite="mid20031104162146.GF9434@sharp.ath.cx">
<pre wrap="">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:</pre>
</blockquote>
That usually happens when the xremote stuff silently fails.<br>
<br>
--Chris<br>
<blockquote type="cite" cite="mid20031104162146.GF9434@sharp.ath.cx">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">Mozilla uses pthreads. ... I'm betting you're not seeing something
thread-related.
</pre>
</blockquote>
<pre wrap=""><!---->
I believe you. I did think it would be a strange failure mode for a
threading problem.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">Also when we load plugins that use Xt ...
</pre>
</blockquote>
<pre wrap=""><!---->
I don't think it's getting that far. Fascinating issue though.
On 11/03 09:19AM, Jim Gettys wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 ...
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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 "$@"
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------
Christopher Blizzard
<a class="moz-txt-link-freetext" href="http://people.redhat.com/blizzard/">http://people.redhat.com/blizzard/</a>
------------
</pre>
</body>
</html>
--------------050505070904050108050803--