[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More XError woes

From: John W. Eaton
Subject: Re: More XError woes
Date: Wed, 02 Apr 2014 11:10:02 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 04/01/2014 05:42 PM, Michael Goffioul wrote:
On Tue, Apr 1, 2014 at 4:31 PM, John W. Eaton <address@hidden
<mailto:address@hidden>> wrote:

    On CentOS 5.8, I noticed that there are still some XError messages
    coming to the command window.  They seem to be related to missing
    icons for menus.  The attached change seems to eliminate them.

    I'm also still seeing messages like this

       Warning: X Error: BadDrawable (invalid Pixmap or Window parameter) 9
         Major opcode: 62 (X_CopyArea)
         Resource id:  0x0

    in the terminal window where I start Octave.

    I know that we redirected these messages from the command window by
    dup-ing stderr prior to launching the GUI, so at least these are not
    cluttering the GUI command window, but I'm wondering whether we can
    eliminate them simply by defining some default Icons or making some
    other change to Octave.  Unfortunately, I'm not sure how to find out
    exactly which widgets are responsible.  Does anyone know how to
    determine that?  If I set a breakpoint in XError, I can get a
    traceback, but it's not very helpful to me because the object is just
    a generic pointer to QWidget at that point, not a specific type of

Oops, I was wrong about that change fixing things.

I forgot that the problem was only happening after plotting something. Then when I tested after making the change, I forgot to plot something before opening a menu. Oops.

But now I think I've found why these messages are coming to the command window in the GUI instead of to the command window in the GUI even though we redirected them. The problem is that Qt and FLTK both set their own custom X11 error handlers, so the FLTK one is overriding the Qt one and the FLTK handler is sending messages to stderr, which at that point is hooked up to the command window in the GUI.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]