For the past three years Google has run an outstanding summer program for students interested in becoming involved with open source software development. Summer of Code offers students a chance to develop relationships with living, breathing software communities by coordinating with as many as 130 organizations and 900 students on 3 month software projects. Stipends are provided to both the mentor organizations and students, making it a very sweet deal from almost any angle.

As we have in the past, OSAF will be participating in SoC as a mentoring organization this year. A full list of projects we believe will be both useful to the project in the long term and stand a high chance of being included in our code base in the short run can be found here, but as in past years outside proposals are more than welcome.

Comprehensive information about this year’s program, including important bits like eligibility and application instructions can be found on the the official FAQ. Student applications will be accepted from March 24 - March 31, so now is the time to find a project and put together a solid proposal!

As always, feel free to ask on one of the Chandler Project mailing lists or in #cosmo or #chandler on irc.freenode.net for more information.

Interoperability is an important part of the Chandler Project vision.

Chandler is about trying to match the way people really work. And everyone uses lots of tools to get their job done. One of the first things people want to know when considering trying out Chandler software is “Will it work with what I already use? Can I switch back if I don’t like it? Will it work with the tools that friends of mine use?”

We believe the answer to all these questions is “YES”! You can safely and productively start using one or more of the Chandler Project components on top of your existing toolset. Go ahead, try it out! Read more below to learn the details.

For a bullet-list summary of our best-available notes on specific applications and which features are supported with each, see our interop overview.

Import/export

The gold standard of calendar transfer is the “ICS” file (in iCalendar format). Most calendar and task list applications support both import and export of ICS files.

You can try out Chandler Desktop without switching from your current setup. Just export one or more ICS files from your current application, then import those files into Chandler Desktop (continuing to use your current app). To switch over permanently, just export+import again a final time!

If you later decide you’d like to change again, you can export ICS files from Chandler Desktop or Chandler Hub, using those files for import into a wide variety of applications.

We’ve seen import and export work for Outlook 2003/2007, Mozilla Lightning/Sunbird, Apple iCal, and others; it should work with a great many apps, probably yours included.

Note that Outlook doesn’t export full information by default; we’ve found this $10 application from littlemachines produces high-quality exports from Outlook that work well with Chandler Desktop.

In practice, doing ICS import/export can have gotachas. Not all application combinations/roundtrips are 100% perfect. We urge you to keep backups and try out import/export before committing your important data to any application. In Chandler Desktop, we’ve spent a lot of time tuning our import/export routines to handle as many variants and details as we can. Chandler Desktop properly handles events, tasks, timezones, recurrence, and other details. Please report any import/export problems you encounter.

We’ve put together some additional information about import/export with Chandler Desktop specifically, so check that for additional hints and notes.

Synchronization

ICS import/export is great for transferring your data between apps, but it’s a manual process not suited to keeping multiple applications in sync. Usually when you import a data set, your app will overwrite changes you may have in your local copies of those events. It’s hard to make changes in two separate apps.

Chandler Desktop and Chandler Hub both support multiple network sync protocols. Where other applications (Outlook, iCal, etc) overlap at least one of these protocols, interoperability is possible on at least some level.

One main idea to keep in mind when thinking about these various systems is whether a scheme is “read-only” or “read-write” (ie, bidirectional). It seems like read-only (or 1-way) interoperability works more reliably today, but protocols like CalDAV promise a new era of real-time, 2-way synchronization of calendar data between lots of free and for-pay applications and web services.

The big news is that you can do 2-way/read-write calendar and task synchronization today, both privately and shared with other people. Here’s a list of the main ways to do that, based on Chandler Project software.

Webcal, 1-way sync

The most simple network protocol is to take an ICS file (see above in import/export) and post it to the web, so various apps can download it (redownloading to check for changes periodically). This system is called webcal.

Chandler Desktop works great for subscribing to a number of public webcal URLs and overlaying them all on one canvas. This is a great way to keep track of lots of calendars.

If you store any events/tasks on Chandler Hub, then you can login to get a URL that you can enter into the right spot in Outlook, Apple iCal, Google Calendar, Lightning/Sunbird, Evolution, Zimbra, and many other apps to synchronize that Hub calendar with your app. This is always a read-only/1-way procedure.

Using webcal, in Outlook 2007, you can overlay say personal or family Hub calendars on top of your Exchange/Outlook calendars you use at work. (Look for “Internet Calendar” features in Outlook’s help.) If you make a change on the Hub or Chandler Desktop and then synchronize, you’ll see that change in your work Outlook’s display.

You can also subscribe to Hub calendars in Outlook 2003, but only view the calendars side-by-side. Other apps like iCal, Lightning/Sunbird, Google Calendar, and Evolution all support overlaying the Hub calendar with other calendars.

Many applications, Outlook included, can also publish a webcal calendar to a web server. You can use Chandler Hub as a destination server for most of these webcal-publishing apps. This works, but please note this does not provide a web UI for that calendar, and it’s again a 1-way publication. The original application will very likely not detect any changes made to this webcal file on the server.

Webcal, 2-way sync

Chandler Desktop can also do 2-way synchronization via webcal. Most applications treat a webcal file as read-only or write-only, but Chandler Desktop will check for changes in a webcal file it is monitoring and integrate those changes. If used with another application that also checks for changes, you get 2-way synchronization. We know Lightning/Sunbird does this (though you might chose to use CalDAV to synchronize instead).

CalDAV, 2-way sync

CalDAV is an emerging standard protocol for open calendar exchange. It’s not a protocol that’s used directly between two clients (like ICS files are), but rather defines a calendar server to which multiple clients can subscribe and synchronize. Chandler Hub also provides a read-write web UI to any calendar you store or use in your account.

The Open Source Applications Foundation via the Chandler Project was an early supporter of CalDAV. Together, our Chandler Desktop application and Chandler Server server product are some of the oldest and most mature implementations of the CalDAV standard and we plan to continue that support.

Chandler Hub is, as far as we know, essentially the leading free CalDAV service offered to the public. Given a fully-cooperating CalDAV client (Lightning/Sunbird, iCal 3.x, and Evolution all cooperate to various degrees), you can use these other clients regularly or occassionally and even use Chandler Desktop for advanced work (like sharing a single item between multiple calendars).

Chandler Desktop can subscribe to and publish a collection (calendar+events) to any CalDAV server (Apple Calendar Server, RSCDS, Bedework), or actually any WebDAV server (Apache mod_dav, .Mac, etc). Both of these mechanisms support bidirectional (read-write) synchronization, so multiple applications or people can all create, edit, and delete events and tasks any time they want, using the application of their choice.

iCal 3 (in Apple 10.5 “Leopard”) is a great new CalDAV-using PIM client. You can use it to make changes to your Hub collection, and still be able to use the Hub web UI to make changes from anywhere. Note that iCal 3 supports read-write calendars only to calendars in your account. Chandler Desktop and Chandler Hub let you subscribe to shared collections owned by other users with full read-write access.

Email integration

Chandler Desktop is not a complete email client; it is rather intended to complement your existing email client. The mechanism we use is to create dedicated Chandler folders on your IMAP server. Using your regular email client (Outlook, Thunderbird, Mail.app, Evolution, etc), you just drag an email from your inbox into a Chandler folder, where the message will be parsed for event, task, and other information.

You should also be able to send email update of items from Chandler Desktop using just about any outgoing mail server available. Events emailed this way appear as ICS attachments. We’ve tested Exchange, Postfix, Gmail, Yahoo mail, and Hotmail/MSN among others.

Chandler Desktop has been in “release a Desktop dot version about once a month” mode since Preview shipped last year, and with that in mind, we’re still on track to release a 0.7.5 early in March. Besides the usual round of stability and usability fixes, here’s what’s in the works:

1. User Interface changes

   The trunk currently has implemented a fair deal of the Task → Star and Pared down Desktop UI proposals. Also, as my personal scratchy itch (and with some UI help from Mimi), I’ve made user collections in the sidebar re-orderable via drag-and-drop.

2. Cosmo security fixes

   Randy Letness has been the driver for addressing a security issue on the server side, where it’s relatively easy to give yourself read-write access to items that have been shared with you read-only. 0.7.5 will have some fixes to make things work more smoothly on the client side (see this thread for some of the discussion that went into this).

3. Printing

   Reid Ellis did some good work to get basic printing support in on a branch. Printing month views is working well for me, so I will be integrating his code into the trunk (possibly with some minor polish).

Here are a couple of linkies for your mouse clicking convenience:

• Bugs resolved so far in 0.7.5.
• The Desktop Work Queue, which I’m using as a guide for what to code next.

If there are fixes you would dearly love to see in 0.7.5, feel free to comment in bugs (or file new ones): I’ll do my best to respond. Patches are welcome, as is testing help. I will be releasing some checkpoint builds in the next week or two as we lead up to the actual release.

The Chandler Project is pleased to announce the 0.7.4.1 release of Chandler Desktop.

Chandler Desktop is an open source, standards-based personal information manager (PIM) built around small group collaboration and a core set of information management workflows modelled on Inbox usage patterns.

The 0.7.4.1 release contains the fix for a bug that severely complicated upgrades from version 0.7.3; see

#11823 Couldn’t migrate 0.7.3 to 0.7.4 on MacOSX

for details.

The 0.7.4.1 release is a single bug-fix release to 0.7.4, which was the fourth in a series of ongoing releases since Chandler Preview 0.7.0 intended to respond to the ongoing feedback received from users. Additional releases improving Chandler Desktop are planned and ongoing.

Chandler Desktop 0.7.4.1 is available for download for Windows, Mac, and Linux here.

Additional information is available from the Chandler Project homepage .

Thanks for your interest in Chandler Desktop!

Over the past 2 weeks, we’ve been plugging away at a Work Queue for Chandler Desktop. By we, I mean Grant.

The thinking behind the work queue is to isolate the half-dozen or so usability issues we feel are the biggest blockers to new users understanding what Chandler is, and how to set about using it. In that sense, the bugs in the Work Queue are not necessarily the most egregious bugs. For example, several serious crash bugs and the false-positive pop-to-NOW bugs were omitted from the list. They are also not necessarily the most ‘oft-requested’ features from our current users. For example, the ability to spawn sub-tasks, aka clusters and Print were omitted from the list.

Instead the focus is to remove the hurdles that all users run into within 30 seconds of downloading and launching the application. Many of the hurdles are conceptual. I’ve sent a number of messages to the Chandler-Dev list dissecting these conceptual barriers:

• Pared down Desktop UI - Part 1
• Next Usability Hurdle: Answering the question: What should an item be?

1. New users are confused by the abundance of email functionality in the user interface. Is Chandler meant to replace your email application or not?
2. New users are confused by what genre / category of software Chandler falls into. Is Chandler meant to replace Outlook? Apple iCal? My journal / notebook? Email, Tasks and Calendar functionality makes Chandler look like a traditional PIM. But there’s a lot of missing functionality typically associated with PIMS (e.g. contacts, full-blown support for email, scheduling, etc). You could also *try* to understand Chandler as a super-duper Task Manager, but again, there’s a lot of missing functionality typically associated with robust Task Managers (e.g. dependencies, assignees, %done, milestones, etc).
3. New users don’t understand what an ‘item’ is supposed to be, as a result, they have difficulty getting started putting data into Chandler. It’s not that mechanisms for creating new items are hard to learn. It’s that the concept of an ‘item’ is too abstract. When faced with the question: Do you have any items to put into Chandler, many users simply go blank.
4. New users have trouble understanding Chandler’s mental model for sharing. In particular, there appears to be a lot of cognitive hoops to jump through just to get your data up on Chandler Hub. This problem can be entirely addressed from the Desktop side. I’ve started a separate thread on establishing a similar Work Queue for the Chandler Hub UI.

We are addressing these issues by:

1. Doing a better job of introducing the product to new users (e.g. better demos; better, more accessible quick start guide);
2. Smoothing out crucial workflows (e.g. guiding users through sharing set-up);
3. Simplifying the user interface, removing concepts that might mislead users into thinking Chandler is a PIM / Task Manager when it’s not (e.g. removing superfluous email buttons from the toolbar; removing the concept of a task);
4. Tweaking Chandler concepts to be more immediately understandable (e.g. changing the concept of an item to a note; changing the task stamp into a star stamp - I will be posting a more in-depth discussion of this issue);
5. Doing a better job of communicating Chandler’s core value through the user interface (e.g. improving the Notes field in the item details to encourage users to think of Chandler as *the* destination for dumping ideas, stray thoughts and questions; providing visual feedback when a shared collection has unread edits to showcase the power of Chandler’s collaboration workflows.

That being said, it is still important for us to keep track of critical bugs, bugs getting in the way of day-to-day usage and features that would greatly enhance the Chandler experience for current users.

I’ve included a list of these bugs and feature requests at the bottom of the Work Queue. If any of these are expedient to take on and/or we end up with extra time on the Desktop side before we’re ready to declare 1.0 for the project as a whole, it would certainly be worthwhile to tackle some of these bugs.

There is also the larger issue of performance, in particular start-up time. There isn’t a lot we can do in the short-term to address performance. We have been working on a rearchitecture project that would address many of the performance problems people run into today, but a completely re-architected Chandler Desktop is not going to emerge in the next 3-6 months.

I can say that we hope to alleviate some of the pain caused by slow start-up time with strategically placed web widgets. For example, we hope to deliver a Quick Entry web widget in the next month or so that would allow users to quickly get ideas and notes into Chandler via Chandler Hub without having to fire up the Desktop app. These are the kinds of things we can realistically accomplish in the next few months.

In the meantime, our first and foremost priority is to turn the Chandler Desktop interface into an effective communicator of what it’s useful for and how it’s useful.

Last week the staff got together in person and took a critical look at where the project is now and what we want to achieve in the next year.

We asked ourselves a series of questions, including: “We have some successful, enthusiastic users who rely on Chandler daily: how are they using it? What are their success stories? How can we build on that and grow the user base?” and “Why do we only have 100s of unique desktop users syncing to the Hub daily when many 1000s of users have downloaded the desktop?”

Looking at users who are successful and potential users who run into difficulties, we had this insight: Chandler succeeds at meeting the needs of users who are tracking ‘knowledge work’. What do we mean by this? We’ve observed people tracking ideas and questions for tasks they need to do — the kind of things people otherwise might jot down in notebooks, on scraps of paper or in text files. They selectively add important email messages to Chandler (the ones they might have flagged if they were only using their email client). They share collections of these items with other people as they develop an idea, using Chandler to record the ‘knowledge’ about a shared project. Quick item entry, stamping items onto the calendar or a task list, and items in multiple collections are all signature features that help users evolve their ideas into tasks and projects. While the design includes tasks and a hard calendar landscape, Chandler is not oriented around calendaring per se or around a complicated task and project landscape with many dependencies. We don’t have enterprise scheduling features, for example, or task and project dependencies. Instead of adding more features for calendaring and task/project management over the next year, we’d like to build on Chandler’s more unique strengths, excelling at meeting the needs people who currently find Chandler compelling.

Of course, many users who do have similar needs to the successful users run into barriers when trying to use Chandler. The application is too slow for their hardware, they are overwhelmed by non essential functionality visible in the application, they don’t know how to get started, they run into a roadblock when creating an account, etc. We want to remove these barriers.

The flip side of this is that some people who have been drawn to the project are really not target users. Chandler doesn’t meet their needs because Chandler is not designed for them. We just don’t have the resources to make all of these people happy — we really do have to focus. More on this in the “what we are not doing” section below.

Another idea that came up in our discussions: we want Chandler to be more viral. We want Chandler to be easy to explain to others. We want Chandler to be found in contexts where people are already spending time. We want Chandler to be of great use to the individual using Chandler on their own, and to be even more useful as that user pulls in other people to collaborate. We want happy users be successful evangelists for Chandler.

What we are doing next

We made some important high level decisions about what we’re going to be focusing on in the next year, and in particular for the next 3-4 months. It was most concrete for us when we discussed exactly what each person would be working on (in particular what each developer would be working on), so I’ll use that to frame our strategy.

Grant Baillie: Incremental progress on the desktop. We decided that we can’t stop and take time out to rewrite the desktop or build a complete web based home for our target users, so that means continuing to maintain the current desktop code base. Grant will focus on bugs and small feature changes that remove barriers for users who otherwise would value Chandler’s feature set. We are not far from a 1.0 version of the desktop. One of the first projects that Grant is working on is a pass at simplifying the UI by removing rarely used email functionality — reducing the number of new concepts that users need to get started.

Travis Vachon and Jeffrey Harris: Web widgets. We’re turning our focus on the web away from replicating the desktop functionality, and toward making Chandler more viral and better at facilitating idea gathering and collaboration for our target users. Travis and Jeffrey are going to build web widgets that might be deployed in different contexts — iGoogle, Facebook, on an iPhone, etc. Widgets will give read/write access to a particular item (instead of a whole collection), allow users to search for a particular item, allow quick entry of items, etc. We’ve started the design work on the chandler-dev list. One requirement for the web strategy is that these widgets should be compelling to a new user who does not use the desktop, in addition to providing features that complement the desktop. Eventually, the widgets can be building blocks for developing out that web based home for our target users.

Brian Kirsch: Thunderbird plugin. Brian has already blogged about this idea; we’ve decided to proceed with it. We think it will be a great way to introduce Chandler ideas to a new audience.

Jared Rhine: Email related features on the Hub. Jared will explore adding email notifications/reports from the service, and email as a way of entering data into the service. Again, these features are a way of making the Hub more viral — data access from other contexts where people spend their time. This work is in addition to Jared’s many other responsibilities (managing the Hub service, build and release management, etc.).

Randy Letness: Chandler Server improvements and support for web widgets. Randy will continue with security work that has long been planned, as well as server support necessary for the new web widgets.

Phillip Eby: Desktop rearchitecture. We will continue to make a modest investment in the rearchitecture project that we embarked upon last year, as the rearchitecture is our path to really solving desktop performance problems. The rearchitecture will also provide a much better platform for other developers to contribute to the project.

Mimi Yin: Product design and strategy. Web strategy and web widget design, Thunderbird plugin design, desktop prioritization, project website improvements, etc.

Sheila Mooney: Evangelism strategy. Develop a pitch and a demo, meet with stakeholders, etc. One of the barriers for potential users and partners is really a marketing barrier — helping people understand what Chandler is intended for.

My job is to manage the project overall and give the project its best shot at thriving beyond the end of the year.

What we are not doing

We are not trying to be an open source Exchange/Outlook competitor. While this would be a worthy goal, it is not our passion and we don’t really have the right product or organization to pull this off. It has been a misperception in the press that this has ever been our goal — probably because so many people want an open source competitor to Exchange/Outlook. We have not designed Chandler for enterprise calendaring. Actually, the Microsoft product with the most overlap with our design objectives is probably OneNote.

Being a CalDAV reference implementation is not a priority. We believe that calendaring standards are important and hope that they are adopted in the world, and much of OSAF’s energy in previous years was directed at making that a reality. With our current need to focus, however, our strategic objective wrt calendaring standards is to be able to interoperate with popular clients (e.g. iCal and Lightning). For this reason and because we are not trying to do enterprise calendaring, we will not be implementing CalDAV scheduling.

We are not trying to be a GTD specific tool. Yes, we paid a lot of attention to GTD as we were designing Chandler and we were inspired by ideas from GTD. We also looked at how people who have never heard of GTD really use their inbox to manage their world, and taken inspiration from that as well. When getting into the specifics of Chandler’s design, we focused on user scenarios and workflows that would make our target users successful — not necessarily designing to GTD processes. We’ve recently taken a critical look at how well Chandler meets the needs of someone following the GTD process strictly. In doing so, we realized that we didn’t want to prioritize staff time to work on changes that would make Chandler a GTD specific tool, and that Chandler’s philosophy is different enough from GTD that it would be misleading to call Chandler a GTD tool. We’ll need to change our messaging — our landing page, blog and other places that refer to GTD. That said, we recognize that some developers are interested in features that would help people use Chandler for a GTD process, and we encourage anyone who wants to contribute code for such features.

We are not going to add full email functionality to Chandler desktop, or contacts (at least not in the next year, not on OSAF staff time). Yes, we know that many people want these features, and we’d love to design them and implement them if we had the resources, but we don’t have the resources in the next year. Again, we’d gladly accept code contributions that implemented these features, or additional funding to implement them. We are willing to spend time to help make people successful contributing code for these features (or other features that complement the current product).

To help focus as a team, we have consolidated our various mailing lists in the following ways:

1. Chandler-dev is now the working list for all things pertaining to the Chandler Project. This includes planning, design and bug prioritization for both Chandler Desktop and Chandler Hub as well as general interest topics like the project wiki, evangelism, community, and governance.

2. Cosmo-dev remains a separate list for those interested in just the server. Planning and project management discussions that used to happen on Cosmo-dev will move to Chandler-dev.

3. General, Design and Service-dev are now inactive. These conversations will move to Chandler-dev. If you are on one of these lists and want to continue following the day to day work of the project, subscribe to Chandler-dev.

4. Chandler-users will remain the best place for users to ask questions and report issues. Email us at chandler-users at osafoundation dot org.

5. Announce will continue to broadcast major releases and other newsworthy information.

All other public lists will stay the same.

We are also maintaining a Chandler Project collection where you can keep up with more day-to-day work. This is where we’re keeping track of feature ideas, upcoming blog posts and meetings.

View-only URL: https://hub.chandlerproject.org/pim/collection/f9fe3636-c489-11dc-dba3-f100459c9336?ticket=37960wr571

Finally, we will be making more use of the blog to discuss design direction, product strategy and to keep everyone abreast of project status and new releases.

Katie’s post OSAF 2.0 Team seems like a good opportunity to introduce myself in this space. When I first joined OSAF I was asked to do this by Pieter Hartsook but a combination of a bad memory and busy schedule has kept this task triaged Later.

I’m originally from a small town about 45 minutes outside of Portland, Maine. My first brush with software development came during the summer of 2006 when, alongside a 6 day-a-week summer camp job, I participated in Google’s inaugural Summer of Code program. My project for the summer found me working with the GNOME Project implementing an experimental “panel extension” system.

I found Chandler while looking for a Linux calendaring client during my senior year at Williams College and after an internship on the Desktop team working on a project to better integrate the Twisted IMAP server into Chandler I was hired full-time as a server/ web front-end developer.

Most of my work since then has straddled HTTP, working mostly at the protocol level on the server and client side, with occasional forays down into the depths of our database layer and up to the shallow waters of user interface implementation. Most recently I’ve been updating our JavaScript code to use the 1.0 release of the Dojo toolkit.

A second project I’ve worked on recently (alluded to in the title of this post) is the first of what I hope to be a series of interesting hacks designed to expand Chandler into the maze of nooks and crannies that is contemporary personal information management. One of the more important lessons I’ve learned while working in this space is that everyone has a different system for tracking and managing the various things they want to accomplish both in work and in life. While semi-standard systems like Chandler’s Triage Workflow and David Allen’s GTD can help, even the most hard-core practitioners will make adjustments to work with their own personal circumstances. As developers of software designed to “serve the way people actually work, independently and together“, I believe it is our job to lead the way in bringing our ecosystem to people’s real needs.

So without further ado, let me introduce chandler.el, a module for interacting with Chandler Server using Emacs, a popular text editing environment. Instructions for installing and using it can be found at the link above. The current implementation is decidedly rough, but is ready for some real world use and feedback.

This offering is definitely on the techie side, but I hope it serves as a proof of concept for a general class of lightweight applications that have the potential to bring Chandler to the system you currently use to track your life. There is currently a discussion on chandler-users@osafoundation.org in which I’ve solicited ideas for more applications like this, please feel free to chime in there or in the comments to this post with yours!

In the future, updates about chandler.el will be posted mainly on my personal blog occident.us alongside information about whatever I happen to be working on or thinking about at the time. If you’re interested in what I do, do check out that space.

Mimi and Katie talked in ealier posts about expanding the Chandler Universe by developing a Plug-in for Thunderbird.

The plug-in would allow Thunderbird users to interface directly with the Chandler Hub.

Some of the current ideas on what actions the Thunderbird Plug-In would perform are:

1. Sync messages in IMAP Drafts/Sent folders with Chandler Drafts/Sent messages.
2. Stamp a message and add it to a list of collection(s)
3. Assign Triage status to message items
4. Map individual IMAP folders to collections
5. Receive notifications from Hub Service when: a. New / Edited items in a collection b. Items tickled to NOW

What features would others like to see?

Is the idea of a plug-in to Thunderbird useful to the Chandler User base? Will a plug-in help attract new users?

If you have any suggestions for features that you would like to see implemented in a Thunderbird plug-in now is the perfect time to share them.

We’ve added Ubuntu Gutsy Gibbon and Mac OS X “Leopard” to our supported list, and are just phasing out Mac OS X “Panther” support, so it was time to clarify what platforms are officially supported.

Linux:

• Ubuntu Dapper Drake (tarball installs)
• Ubuntu Gutsy Gibbon (deb install, using system python)

Windows:

• Windows XP

Macintosh:

• PPC Mac OS X “Tiger”
• Intel Mac OS X “Tiger”
• Intel Mac OS X “Leopard” (using system python)

Additionally Chandler may be built and may run in the following configurations but is not officially supported/tested, although we may fix issues if reported, especially if given patches:

Linux:

• Ubuntu Feisty Fawn (using system python)
• Ubuntu Gutsy Gibbon 64-bit (using system python)
• Other Linux variants

Windows:

• Windows 2000
• Windows Vista

Macintosh:

• PPC Mac OS X “Panther”
• PPC Mac OS X “Leopard” (using system python)