Opened 15 years ago

Closed 15 years ago

#365 closed defect (wontfix)

wxGUI: ** (python:3840): WARNING **: IPP request failed with status 1280

Reported by: msieczka Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: wxGUI Version: svn-develbranch6
Keywords: Cc:
CPU: All Platform: Linux

Description

For some days now GRASS 6.4 SVN has been printing a following warning o the terminal, once a second or so:

(python:3840): WARNING : IPP request failed with status 1280

This makes using CLI troublesome.

Once I close wxGUI the wrning is gone.

Debian testing amd64.

Attachments (1)

gui_print.diff (2.9 KB ) - added by glynn 15 years ago.
patch for printing in wx GUI

Download all attachments as: .zip

Change History (13)

in reply to:  description ; comment:1 by glynn, 15 years ago

Replying to msieczka:

For some days now GRASS 6.4 SVN has been printing a following warning o the terminal, once a second or so:

(python:3840): WARNING : IPP request failed with status 1280

Googling for "IPP request failed" indicates that this is generated by libgnomeprint polling CUPS when no printer is available.

It might be possible to ensure that this doesn't occur if you don't use any features related to printing. Unfortunately, once you do, there isn't much that we can do about it. glib provides a mechanism to override the default logging handler, but neither wxWidgets nor wxPython appear to use this or expose it to applications.

in reply to:  1 ; comment:2 by msieczka, 15 years ago

CPU: x86-64All

Replying to glynn:

Googling for "IPP request failed" indicates that this is generated by libgnomeprint polling CUPS when no printer is available.

In my case the culprit seems to be that CUPS was disabled (as I don't usually use any printers anyway). Once I turned CUPS service on, in spite of no printers configured, the warning is gone.

It might be possible to ensure that this doesn't occur if you don't use any features related to printing. Unfortunately, once you do, there isn't much that we can do about it. glib provides a mechanism to override the default logging handler, but neither wxWidgets nor wxPython appear to use this or expose it to applications.

So basically when CUPS is disabled/not installed on a machine, GRASS terminal will always be borked like this?

in reply to:  2 ; comment:3 by glynn, 15 years ago

Replying to msieczka:

So basically when CUPS is disabled/not installed on a machine, GRASS terminal will always be borked like this?

Modifying PrintOptions to create the wx.PrintData object on first use may mean that the problems won't arise unless you select any of the items from the print menu on the map display, histogram or profile windows (presumably, you're not likely to select those items if your system isn't set up for printing).

You can test whether this is the case by commenting out the lines:

        self.printData = wx.PrintData()
        self.printData.SetPaperId(wx.PAPER_LETTER)
        self.printData.SetPrintMode(wx.PRINT_MODE_PRINTER)

in PrintOptions.__init__ in $GISBASE/etc/wxpython/gui_modules/disp_print.py.

I can't test it, as my version of wxWidgets is built without Gnome support, so I don't get these warnings.

in reply to:  3 ; comment:4 by msieczka, 15 years ago

Replying to glynn:

You can test whether this is the case by commenting out the lines:

        self.printData = wx.PrintData()
        self.printData.SetPaperId(wx.PAPER_LETTER)
        self.printData.SetPrintMode(wx.PRINT_MODE_PRINTER)

in PrintOptions.__init__ in $GISBASE/etc/wxpython/gui_modules/disp_print.py.

Doing the above prevents WARNINGs, but also completely disables all printing functionality. Choosing any tool under "Print display" has no effect.

in reply to:  4 ; comment:5 by glynn, 15 years ago

Replying to msieczka:

Doing the above prevents WARNINGs, but also completely disables all printing functionality. Choosing any tool under "Print display" has no effect.

That's to be expected; it wasn't intended as a fix, just a way to confirm the source of the warnings.

I'll commit a proper fix. However, once you choose any of the print related menu options, there doesn't appear to be much that we can do about any warnings that libgnomeprint decides to generate.

In particular, the wx.PrintData() object has to be persistent so that any settings made via the "Page Setup" are used for printing. Hmm; I suppose that we could add a "Reset" option to remove any references to the wx.PrintData() object, although that won't help if wx keeps its print-handling thread running anyhow.

by glynn, 15 years ago

Attachment: gui_print.diff added

patch for printing in wx GUI

in reply to:  5 ; comment:6 by glynn, 15 years ago

Can you try the attached patch?

in reply to:  6 ; comment:7 by msieczka, 15 years ago

Replying to glynn:

Can you try the attached patch?

It helps. No warnings until I select a tool from "Print display". Once I do however, the warnings start cropping in 5 seconds intervals.

in reply to:  7 ; comment:8 by glynn, 15 years ago

Replying to msieczka:

Can you try the attached patch?

It helps. No warnings until I select a tool from "Print display". Once I do however, the warnings start cropping in 5 seconds intervals.

Do they stop if you select the "Reset" option?

In any case, that's all that we can do. Committed as r34380 (7.0).

in reply to:  8 ; comment:9 by msieczka, 15 years ago

Replying to glynn:

Do they stop if you select the "Reset" option?

Nope.

In any case, that's all that we can do. Committed as r34380 (7.0).

Much better anyway. Thanks!

in reply to:  9 comment:10 by glynn, 15 years ago

Replying to msieczka:

Do they stop if you select the "Reset" option?

Nope.

In that case, I'll remove the Reset option, as it serves no purpose.

comment:11 by cmbarton, 15 years ago

I think we should change this to fixed (as much as possible) or wontfix, because it seems that nothing else can be done. It only arises if CUPS is disabled with Gnome printing it seems. It should also be merged with the couple of other reports about CUPS and Gnome printing, as they all seem related.

comment:12 by cmbarton, 15 years ago

Resolution: wontfix
Status: newclosed

No one has responded since last December. Changing to wontfix because there is nothing we can do in the wxPython GUI to improve this further.

Michael

Note: See TracTickets for help on using tickets.