[Pythonmac-SIG] scripting iCal

David Reed dreedmac at columbus.rr.com
Mon Nov 29 14:06:51 CET 2004


On Nov 29, 2004, at 5:37 AM, has wrote:

> David Reed wrote:
>
>>> #!/usr/local/bin/pythonw
>>>
>>> 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.
>
> Specify?


I just hadn't figured out what to do with the return value (ref in your 
example above). I see now.

>
>> 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 
> works:
>
> #!/usr/local/bin/pythonw
>
> 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.
>
>
> Notes:
>
> 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.
>

Thanks for all your help. I'm coming from the Unix world (Linux and 
Solaris) not Windows so I'm not familiar with COM or AppleScript at all 
- just getting started. I'll look into calculating the recurring values 
myself.

Thanks,
Dave



More information about the Pythonmac-SIG mailing list