VisTrails Home

Improve error handling/reporting

From VisTrailsWiki

Revision as of 13:33, 23 November 2010 by Tommy (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 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.
Personal tools