#1245: implement notification service and API ----------------------------------+----------------------------------------- Reporter: wkornewald | Owner: stippi Type: enhancement | Status: in-progress Priority: normal | Milestone: Unscheduled Component: Kits/Application Kit | Version: R1/Development Keywords: | Platform: All Blockedby: | Patch: 0 Blocking: | ----------------------------------+----------------------------------------- Comment(by axeld): I would consider the icon optional, at least I could imagine a nice animation there instead, or even no icon at all. If you don't want to let people mess with the style, write a style guide for how notifications should look like, or how BViews should behave in this case - but I wouldn't artificially limit the interface with eventually not so future proof decisions. If the title etc. are mandatory, they should be arguments of the constructor. OTOH, I think at least the title can be derived automatically if none is given (ie. just the application name by default). What would be SetApplication() for? be_app should always be the sender in the context of the client. I would understand the use of a BNotification class better if it could be updated live later on, ie. when I have already published it, and then call SetProgress(), the view is updated directly. I'm not sure if Notify() should be part of BRoster at all. I guess I would just make it a method of BNotification instead (and name it Send() or Publish() or something like that). -- Ticket URL: <http://dev.haiku-os.org/ticket/1245#comment:19> Haiku <http://dev.haiku-os.org> Haiku - the operating system.