[haiku-bugs] Re: [Haiku] #1245: implement notification service and API
- From: "plfiorini" <trac@xxxxxxxxxxxx>
- Date: Wed, 23 Jun 2010 18:10:41 -0000
#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.
Other related posts:
