[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