[haiku-development] Re: Notification Server?
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 24 May 2007 12:04:58 +0200 CEST
Here's an idea that might not have been mentioned:
Have the notification class (Blurt ;) create attributed files in
~/Notifications/, or something like it*, (Application Messages?)
instead of directly targetting the popup window thing.
This would enable queries, possibly simplify filtering and allow
multiple frontends to (co-) exist, and without removing any of the
possibilities already mentioned in this thread.
This would solve the problem of additional logging, which one might
want sometimes, and partially solve the problem of a user missing a
popup due to being away temporarily, or if one dismisses a popup too
quickly.
The files would be given a notification filetype, by the class, and a
set of relevant attributes (already mentioned in this thread), Tracker-
visible, including an upper time limit attribute that clearly states a
point in time where the notification file can be safely thrown away.
(You would of course be free to do so at any time, as would the
application. The app could keep a reference, or the object, and remove
the notification should it no longer be relevant. I suppose the class
itself could do some garbage collection when posting new
notifications.)
If one isn't especially interested in the notifications, one can just
ignore the folder, avoid queries on the filetype and turn off whatever
frontend one's got. There could be a default frontend, InfoPopper-like,
I suppose, if that's what people want, and a prefs panel for it.
A front-end should not delete notifications unless they have timed out,
or the user somehow explicitly asks** for deletion, to avoid stepping
on the toes of a possible other front-end, or custom user queries.
There could be a boolean attribute to be set by a front-end, which
would indicate that the user has acknowledged notification and wishes
to not see the notification again (in any other front-end), except in a
full log list. This way all front-ends have a chance to share the user
request to not be shown this notification again. Deletion is an
alternative, of course, but that could be too "definitive".
I suppose the notification message should be an attribute. BFS would
index the first 255 bytes IIRC (and the other attributes as well),
which should be enough for a message outline.
The notification class could optionally offer to fill the body of the
file with a BMessage that could host rich data, replicants, whatever.
Futureproofing this somewhat. The message would be up to the
applicaton.
*One might want to use a folder out of harms way, below
~/config/ somewhere, to avoid confusing people who simply
don't want to know.
** It would clutter the UI to also offer this choice in a popup.
/Jonas Sundström.
Other related posts:
