Difference between revisions of "Improve error handling/reporting"
Jump to navigation
Jump to search
(Created page with '* Classifying log levels ** debug 10 (cannot be accessed by setting loglevel) ** log(info) 20 ** warning 30 ** critical 50 *the QT signal handling is currently unused but I assu…') |
|||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Dave's comments = | |||
*the | * The buttons in the messages window should all be aligned to the right-side of the window so that resizing doesn't add space between them. | ||
* | * We need to go through the code to make sure our messages adhere to a format that makes this work. | ||
** For some of the invalid pipeline messages, they start with a '-' which makes them look weird in the new gui. | |||
** We need to redo a bunch of the existing gui messages (like those that use QMessageBox.critical directly...). | |||
* | * Colorcodes work | ||
** | ** I'm not sure we need more than red and black, but I like red for critical. | ||
** | |||
> * The MessageBox that displays error messages is similar to the one used for "Invalid pipeline" messages in | |||
> gui.vistrail_controller. Do you think it works? | |||
* How to display multiple error messages | |||
** On startup, I only see the last error as a MessageBox. It would seem that when we get multiple errors, we should display them in a format more like the messages windows. | |||
** On the Mac, you can't resize this box. Is it possible to make this larger and resizeable? | |||
* "copy message" works. | |||
** We could also use Qt's QDesktopServices.openUrl to have a "Send to VisTrails..." button that generates a message with all of the necessary information and a given address (maybe something like vistrails-debug@sci.utah.edu?) and allows the user to send it via their email client. | |||
* To get more informative messages I allow the logging functions to accept multi-line messages where the first line is the short message and the rest are used as detailed information. Do you think this is a good idea? | |||
* Logging accepts multiline messages where the first one is the summary and the rest is a more detailed message. | |||
** Another way is to get developers to think about this correctly by adding specific arguments to the function call so that there are two arguments (message, expanded_msg). For backward compatibility, we can default expanded_msg to None and use the multi-line heuristic to break up the message in that case. | |||
Latest revision as of 19:33, 23 November 2010
Dave's comments
- The buttons in the messages window should all be aligned to the right-side of the window so that resizing doesn't add space between them.
- We need to go through the code to make sure our messages adhere to a format that makes this work.
- For some of the invalid pipeline messages, they start with a '-' which makes them look weird in the new gui.
- We need to redo a bunch of the existing gui messages (like those that use QMessageBox.critical directly...).
- Colorcodes work
- I'm not sure we need more than red and black, but I like red for critical.
> * The MessageBox that displays error messages is similar to the one used for "Invalid pipeline" messages in > gui.vistrail_controller. Do you think it works?
- How to display multiple error messages
- On startup, I only see the last error as a MessageBox. It would seem that when we get multiple errors, we should display them in a format more like the messages windows.
- On the Mac, you can't resize this box. Is it possible to make this larger and resizeable?
- "copy message" works.
- We could also use Qt's QDesktopServices.openUrl to have a "Send to VisTrails..." button that generates a message with all of the necessary information and a given address (maybe something like vistrails-debug@sci.utah.edu?) and allows the user to send it via their email client.
- To get more informative messages I allow the logging functions to accept multi-line messages where the first line is the short message and the rest are used as detailed information. Do you think this is a good idea?
- Logging accepts multiline messages where the first one is the summary and the rest is a more detailed message.
- Another way is to get developers to think about this correctly by adding specific arguments to the function call so that there are two arguments (message, expanded_msg). For backward compatibility, we can default expanded_msg to None and use the multi-line heuristic to break up the message in that case.