HumanizedMessage -functionality

[Marc Englund]

We _really_ want humanized messages for notifications ("Your stuff has been saved", "Knurflat deleted"). (demo)

In practice the natural place to implement this would be in Window, which actually has two possible - mainly unused - candidates in the API: setDescription() and setComponentError().

Component error would be the perfect match, but there are some issues: this is not an error. But ErrorMessage? also contains an INFO error level, which is usually not an error, indicating that the ComponentError/ErrorMessage? is poorly named.

Otherwise ErrorMessage? could be a match: we have UserMessage? already, we could implement a HumanizedMessage? that would extend UserMessage? to indicate that the message should dissappear humanely - in the future all components could support this.

Solution

• implement HumanizedMessage? extends UserMessage? + setDelay()
• implement in IWindow
• at some point, implement in other components

Really consider:

• rename API, e.g Error -> Message(/Notification)? setComponentMessage(Message msg)

Problems

• Humanized messages should dissappear automatically, should probably do so serverside as well (too sticky error messages general problem in TK)?
• Many simultanious messges should be shown in the same notification - but should the programmer be responsible for compositing (automatic would be better, but how)?

[Marc Englund]

Solution 2

• scrap setComponentError()
• implement showComponentNotification() instead:
  • "show", not "set" = not sticky, no need to remove serverside later, readd instead if reason for notification persists
  • multiple notifications could be automatically composited
• refactor (simplify) ErrorMessage? hierarchy
  • ErrorMessage? -> Notification
  • Notification.setDelay(int msec), -1 == user must close

[Marc Englund]

Solution 3

• keep comopnent error as-is
• implement Window.showNotification(caption,message,delay)