wxGUI: Ignore stderr of the GUI #3049
Conversation
When GUI is started by the init (grass.py) script, error messages comming from wxGUI are now ignored. The messages can be inspected by setting GRASS_DEBUG. There is many GTK critical messages which seem very critical, but are harmless for the end user and we had little luck in fixing them, perhaps because we are using GTK only through wxPython and not directly. Complains about the messages far outnumber complains about non-functional widgets on GTK, so hiding the messages not relevant to the end user by default makes sense. Other programs typically don't face this issue as they are not started from terminal or they use daemon process for the main process, so it's unclear what is the common practice except for the result being no messages are typically visible to the end user.
|
Q: GUI should probably reflect |
|
Unfortunately |
…riable GRASS_DEBUG
OK, makes sense, done. That's indeed expected when debugging GUI (although you are likely to use g.gui in that case anyway). I tested that and it works as expected. I'm keeping |
I didn't do any test, but I think it needs to be solved from the caller process, so g.gui really needs to be done separately. Maybe we want to keep g.gui with stderr for some (limited) time. It is the more advanced or less standard way of using the GUI anyway, so perhaps we want the exposure to the messages there. I hope at least some can be solved. |
|
The code is ready to be merged and the change seems to have support. |
|
Is this PR still up to date, and appropriate to merge? |
github-actions
bot
added
Python
|
This PR was previously reviewed and approved and was once ready to merge. Is there anything that should block merging this now? A refresh of the CI was triggered with the new required checks in place since then. |
|
@lindakladivova Does this come break what you are working on? Does this seem right to merge for you, since you are actively in the GUI side of the codebase? |
From my side, this PR looks okay but I was not actively present during its implementation, maybe @landam / @wenzeslaus should merge it? |
When GUI is started by the init (grass.py) script, error messages coming from wxGUI are now ignored. The messages can be inspected by setting GRASS_DEBUG. There is many GTK critical messages which seem very critical, but are harmless for the end user and we had little luck in fixing them, perhaps because we are using GTK only through wxPython and not directly. Complains about the messages far outnumber complains about non-functional widgets on GTK, so hiding the messages not relevant to the end user by default makes sense. Other programs typically don't face this issue as they are not started from terminal or they use daemon process for the main process, so it's unclear what is the common practice except for the result being no messages are typically visible to the end user. * React to GRASS GIS environment WX_DEBUG besides system environment variable GRASS_DEBUG
When GUI is started by the init (grass.py) script, error messages comming from wxGUI are now ignored. The messages can be inspected by setting GRASS_DEBUG.
There is many GTK critical messages which seem very critical, but are harmless for the end user and we had little luck in fixing them, perhaps because we are using GTK only through wxPython and not directly. Complains about the messages far outnumber complains about non-functional widgets on GTK, so hiding the messages not relevant to the end user by default makes sense. Other programs typically don't face this issue as they are not started from terminal or they use daemon process for the main process, so it's unclear what is the common practice except for the result being no messages are typically visible to the end user.