[Pythonmac-SIG] scripting iCal

has hengist.podd at virgin.net
Mon Nov 29 11:37:16 CET 2004

David Reed wrote:

>>from appscript import *
>>from datetime import date, timedelta
>>today = date.today()
>>tomorrow = today + timedelta(1)
>># To get a list of today's events in calendar 1:
>>print app('ical.app').calendars[1].events.filter((its.start_date >= 
>>today).AND(its.start_date < tomorrow)).get()
>># To get names and descriptions of today's events in 'Home' calendar:
>>ref = app('ical.app').calendars.filter(its.title == 
>>'Home').events.filter((its.start_date >= today).AND(its.start_date 
>>< tomorrow))
>>print zip(ref.summary.get(), ref.description.get())
>Thanks. I had tried appscript but hadn't figured it out either.


>The above works fine except it doesn't pick up events from other 
>days that repeat on the current date.

Tsk. I rarely use iCal, so wasn't aware of this. But I've checked 
and, yes, start and end date refer to the original event as defined 
by the user. iCal's designers obviously didn't think through the 
implications when the event is also set to repeat. (Like I say, 
iApps' scripting implementations are notoriously second-rate, hardly 
the showcase you'd expect.)

Only solution I can see is to get the start dates of all events and 
do the math yourself. It's slower and less convenient but at least it 


from appscript import *
from datetime import date, timedelta

today = date.today()
ref = app('ical.app').calendars[1].events
print [r for r, d in zip(ref.get(), ref.start_date.get()) if not 
(d.date() - today).days % 7]

>Is there documentation that I could look at that shows me what calls 
>I can make on the various objects?

No, aete [Apple event terminology] resources don't carry this info 
(sdefs, their eventual replacement, will have  limited information on 
which commands work on each class), and most applications have little 
or no additional documentation on their scripting interfaces. Yes, 
this sucks.

>I'm guessing there's a way to change the filter to pick up repeating 
>events, but I don't know where to look.

No, application object references - actually simple relational 
queries - always follow a standard structure.


An Apple event interface isn't like COM where you just chuck a bunch 
of raw function calls out in the wild; it's a complete 
View-Controller layer with its own interaction rules: the Apple Event 
Object Model defines a standard system for referring to objects and 
the application developer defines the commands and classes they wish 
to present (which may or may not bear any resemblance to the internal 
data structures in the application's Model layer). It's a good system 
in itself, but the quality and quantity of support for it in both 
first- and third-party applications varies wildly.

On a good day, you can do everything you want with a few references 
and commands; on a bad day you have to grab raw data and process it 
yourself; on a really bad day you're reduced to using GUI Scripting 
to manipulate the app (ugh!); and at worst it's impossible. Some 
application developers do a good-to-excellent job of implementing - 
and even documenting(!) - Apple event interfaces (e.g. Finder, 
InDesign, Entourage), but there's a lot of companies/developers out 
there who don't bother, or just don't seem to 'get it', or just bodge 
an quick-n-ugly AE wrapper around whatever existing APIs they already 
have (e.g. Word & Excel 2004). C'est la vie.

Third-party language bridges like appscript can save you the pain of 
having to deal with the ugly, underpowered can-o-worms that is the 
AppleScript language, but they can't do anything to address the 
deficiencies of individual applications. Feel free to submit feature 
requests/bug reports/etc. to Apple and application developers: the 
more they hear from folk, the more likely they are to pay attention.



More information about the Pythonmac-SIG mailing list