[Chandler-dev] Proposal/Call for volunteers/Brain dump: Showing reminders when Chandler isn't running

Grant Baillie grant at osafoundation.org
Tue Jul 25 16:32:00 PDT 2006


On 19 Jul, 2006, at 10:55, Jeffrey Harris wrote:

>>> 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).
>> Yes, that should work.
>
> I'd lean towards option 1).  A flat-file system is probably the  
> cheapest way to get a reminder widget up and running with low  
> resource consumption, so I'm not opposed to starting there, but I  
> can imagine this background process having:
>
> - a hotkey that essentially pops up the current Chandler preview area,
> - a quick-entry widget, or
> - maybe just run the appropriate server to accept quick-entries from
> XML-RPC
>
> Since we're already committed to handling merges well, it seems  
> like we might as well take advantage of the existing investment...

Yeah, I'm inclined to go this way, too. At least, I think I could  
write the periodic repository refresh code faster than I can write  
the flat-file system. Hopefully, no Chandler user will be crazy  
enough to try run the app on some wacky lock-free filesystem :0.

--Grant




More information about the chandler-dev mailing list