#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: | Blockedby: Patch: 0 | Platform: All Blocking: | ----------------------------------+----------------------------------------- Comment(by plfiorini): Replying to [comment:19 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. OK - I'm working on a patch that doesn't have any icon set by default. Notification windows color should be enough to know the urgency of the message (ie a red window indicates an error). > If the title etc. are mandatory, they should be arguments of the constructor. Only the notification type is mandatory and it's already an argument of the constructor. It should be tested to see what happens if the notification doesn't have any title, though. > 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. In my (yet to be published) patch, SetApplication() was renamed to SetGroup() and Application() to Group() to explain its meaning. Groups are not going to be mandatory as they were in the original InfoPopper implementation. Grouped notifications will appear in the same group box, it's useful if an application sends a bunch of notification at the same time. > 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. It's possible, this is why we have SetMessageID(). By default a notification has a NULL message ID but if you set one, subsequent calls to BNotification::Send() will update live. This is InfoPopper legacy, maybe it's better to remove SetMessageID() and MessageID() and let BNotification generate a system-wide unique identifier each time the BNotification is created. > 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). Done, it's now BNotification::Send(bigtime_t). -- Ticket URL: <http://dev.haiku-os.org/ticket/1245#comment:21> Haiku <http://dev.haiku-os.org> Haiku - the operating system.