The actual notification process could be tailored for each OS: Growl for OS X, pop-up dialog for Windows, etc
The program could even check to see if chandler is running and if so open a simple connection to give more value-added services.
As for how to start the program, each OS provides an area that if a program is listed it will be started when the user logs into the system.
On Jul 5, 2006, at 9:08 PM, Grant Baillie wrote:
One commonly found Calendar feature that we'd like to implement is the ability to have reminder dialogs for events be displayed even when the Chandler GUI isn't visible (see https://bugzilla.osafoundation.org/show_bug.cgi?id=5407).---
Presumably, this would be something users could turn on and off, lest we be accused of propagating some kind of CPU-hogging virus :). It's unlikely we'll have time to do this in the α4 time frame, but I'd like to request comments and/or propose some ideas for how we could get this done.
Also, since I'm somewhat of a Mac guy, and solving the issue will probably require different behaviours on Windows & Linux, it would be good to enlist the help of people who know the other platforms well. For instance, there may be OS-specific services that I'm not aware of that could be helpful here. The main technical stumbling block that I see is one that probably has a platform-specific answer:
+++ How do we make sure that some kind of background process or app runs whenever the user is logged in?
[[For instance, on the Mac, you can add a "background" app to the user's list of login items; in 10.4 (Tiger) there may be a way to leverage launchd. I know there's a Service facility on Windows you can use to launch background processes, though I'm not sure if this would be the right thing to be using. What's the story with Linux? Probably there are mechanisms in KDE/Gnome... ]].
Assuming that issue has been resolved, I can see at least four different options:
1) Have two separate processes, the app and a background daemon/service, that both access the user's repository. The way I understand things (Andi, correct me if I'm wrong), both processes would need to poll (via the repository view refresh() API) to detect when changes have occurred. It turns out Chandler does this already (in a wx idle event callback), while the reminder process could presumably just check every minute (if it's not displaying any UI).
2) Have two processes, but have the background daemon not use the repository at all. (Maybe we're worried that people will try to store their repositories on volumes that don't support file locking, or something). Instead, the two communicate via a config file and/or named pipes or something (insert sound of two hands waving profusely here).
3) Along the lines of 2, have two processes, but have them handshake at launch/quit so that only one is running (and responsible for displaying reminders) at any given time.
4) Have just one process, today's Chandler, but add the ability for it to switch between full UI & background (reminder-only) mode. So, if background mode is in effect, and the user launches Chandler, a little plastic garden gnome waves a sparkly wand and tells the background process to display the full UI. Similarly, when you "quit" the full UI app, it goes back into background (stealth) mode. (This is easier, so the gnome gets a break).
Further options, or opinions as to what you think will or won't work, would be appreciated.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
Bear
Build and Release Engineer
Open Source Applications Foundation (OSAF)
[EMAIL PROTECTED]
http://www.osafoundation.org
[EMAIL PROTECTED]
http://code-bear.com
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
