[Chandler-dev] Proposal/Call for volunteers/Brain dump: Showing
reminders when Chandler isn't running
travis at osafoundation.org
Tue Aug 22 14:40:38 PDT 2006
I've been working a bit on this idea, and have an implementation of
option 1(see below) working fairly well. Details on its design and
current status can be found at :
CPU performance is all but unnoticeable, but it does appear to be a bit
of a memory hog. Interestingly, the degree to which it hogs memory
appears to depend on whether Chandler was running when the reminder
application was started.
I figured it might be nice to have some information on the memory
performance of this application, so I did a couple tests and posted the
The first test is a comparison of memory use of Chandler and the
reminder applet when
A) Chandler is started first and the reminder applet is started second and
B) The reminder applet is started first and Chandler is started second.
The second test is an examination of memory use at different points
during a step through of the initialization code of the reminder applet.
A couple caveats:
* The code has changed a little since I ran the step through. The
initialization steps are still basically the same.
* This is a single data point and should be taken with the requisite
grain of salt : )
* Memory usage information is taken from the top command, and is thus
dependent on the accuracy (or lack thereof) of the information provided
A couple conclusions:
* It looks like whichever application runs second consumes
considerably less resident and shared memory.
* Loading the repository is the largest single bump in memory use.
This appears to be less pronounced for resident memory.
Given this, I think it makes sense to revisit this conversation. With
this kind of memory use, does the prospect of having two repositories
open in separate processes seem reasonable? In an age of increasingly
cheap RAM, do we care?
Personally, I do care about memory utilization, especially for a
background process, but I think it would be a shame not to use the
elegant machinery provided by the repository in an application like this.
I'd like to propose a number of possible solutions, some of which may be
a rephrasing of Grant's ideas. Hopefully they'll spark renewed
conversation on this idea.
The ideas are listed in order of expected memory utilization.
1. A reminder application as it is currently implemented with the
repository and wx.
+ Flexible and extensible
+ Easy to implement
+ (?) Could use block framework?
- Memory hog
2. A reminder application using native notification frameworks (e.g.
GNOME's notification daemon) and the repository.
+ Flexible, but harder to maintain
+ Slightly less memory utilization because we drop wx, but still pretty
high (and possibly higher if the external
libraries are heavy)
- Harder to implement, Python bindings for notification systems may not
be available (python-notify, for GNOME notification daemon, will be in
- Could lose some Chandler specific features
3. A reminder application without the repository, but with wx.
- We will need to develop a new system to export reminders or find
something that does this for us (e.g. flat file system solution
- Less flexible
Of course, solutions like the use of native notification frameworks
could also be incorporated into 1 and 3.
These proposals focus mainly on the memory-consuming qualities of each
solution, but there are many more possibilities surrounding the "always
running Chandler" and "handshake at launch/quit" ideas mentioned below.
I'd be happy to put together some sort of chart comparing a number of
these if there is a desire for that sort of thing.
$0.02 welcome, and sorry this is so long :)
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
> 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
> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev