I use a text widget to display message types. Each line contains a single message type, a newline, and no other data. When I detect a problem in a message I display its message type in color. Red for serious error, yellow for warning, etc..
I saw the segmentation violations when I displayed two message types using the same color, one immediately following the other. When I added a space and newline in default foreground and background, the segmentation violations stopped.
Like I said it isn't easy to reproduce the problem. To reliably cause the problem requires interaction with other programs that attach to the same shared memory. (The other programs are only reading from the shared memory... honest). If the window is moved before messages are received, the crash won't occur as reliably.
Bill
Jim Buzbee wrote:
I'm trying to track down the source of a color problem I'm having and I'm
starting to think it may be in Gtk. Here's my situation. I working on an a
x86 (Little Endian) processor but my graphics card is "broken" in that it
insists on treating its frame buffer as Big Endian. I have successfully
applied patches to my Xserver to account for this behavior and now most apps
display fine (32 bit mode). Some apps however, have the red and blue colors
still swapped. For example, If I run Netscape, all is well. If I run Mozilla,
all the blues are red and all the reds are blue. If I run "xv -root image.jpg"
the image is color-correct, If I run "Esetroot image.jpg" the reds and blues are
swapped.Anyone have any insight? Are there some assumptions in the Gtk library about
byte ordering?Thanks,
Jim Buzbee
Echostar Technologies--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
-- Bill Smith wsmith@gi.com 215-323-2074 There are 2 Bill Smith's working at GI. * Please use correct email addr, and phone #. *