[ge-talk] Notification Server?

[Simon Taylor]

I'm now favouring a very simple system standard thing to display 
something on receipt of a BMessage. I agree that the standard 
configuration should be in the app, because the display can be better 
customised. For example if I have a calendar app I might want to set the 
default length of time before a meeting to send the notification. This 
should be dealt with in the app, the system should just be responsible 
for displaying the message.

However there could be some communication on the settings - so the 
pop-ups could contain a drop down to disable a particular category of 
events which would then be reflected in the app's preferences. I prefer 
this to the "filtering at the post office" approach as the app is more 
directly aware of what information the user is receiving.

Chris Peel wrote:
> Some crucial points:
> 
> 1. Users who don't want notifications can turn off the  
> notification_server to save on resources

I don't like this as the app is taken out of the loop - it can post 
messages but can't assume the user has seen them.

> 2. The end user decides which notifications are displayed through  
> management of a config file used by the notification_server

See above - doing this in the app enables settings to be tailored for 
the specific application. There should be an API to disable categories 
from the notification server-display windows, however.

> 3. Point (2) give two huge benefits:
> 	- End applications just need to send notifications; they don't need  
> to manage them (the server will do this)

See above - I think it's better if the app is in control. "management" 
just includes adding a check box to preferences and an if statement 
around the message sending code. The bulk of the work of writing a class 
to display messages in a consistent place on the screen, to hide them at 
appropriate times, to offer multiple options for displaying them 
(pop-up, deskbar icon change, deskbar ticker, etc) would still be 
provided by the system.

> 	- The user has ultimate control over what their PC is telling them,  
> which is how it always should be

Yup. The service should be able to force certain messages not to be 
displayed. It may be that this means it is necessary to have a 
"post-office" filter as a last resort - but "good" apps should just not 
send unwanted messages in the first place.

> 4. A preferences applet can be written to manage the  
> notification_server config

Yes, common display-style options for the popups could be set system-wide.

> 5. A little app that sits in the Deskbar's shelf (or as a replicant  
> anywhere else?) can be used to manage the notification_server (start/ 
> stop/restart/etc.)

Seems a bit unnecessary. Other servers don't have that.

> Any good?
> 
> I'd love to do something like this myself but I'm no C++ coder so  
> instead would be very willing and able to (a) contribute ideas,  
> suggestions, etc. (b) bug-test, (c) host the product (could be called  
> 'Snarl for BeOS' :D)...

It would be a standard system component of Haiku, that's the reason it's 
being discussed here...

> If anyone thinks it's worth pursuing I can put some slides together  
> showing all this in more detail...
> 
> Chris
> 

Simon