As I said in an earlier post the new version of iCalMaker (iCalMaker2) will be able to import date and time data, from tab or comma-delimited files, using custom date and time formats. This will also be applicable to exported data…

In iCalMaker version 1.0 to 1.9, the format of dates and time that could be recognised/used by iCalMaker was limited to the pre-set style in System Preferences.

In iCalMaker2 there is a choice, you can either use the values set in the System Preferences, or some values as set by you, the user, in the iCalMaker2 prefrences.

The date/time format for importing and exporting data in iCalMaker2 can be set in the Preferences

Basically, once the “Use Own Time/Date settings” is clicked the different settings become available. For example, the date can be “Day Month Year”, “Month Day Year” etc. The month can be a number (1 – 12), or an abbreviated month (Jun for example), or the full month (June). A year can 2008, or 08. The time format is equally flexible, i.e. hour minutes and seconds, or just hours and minutes. 24 hour time, or 12 hour…

In both cases, time and date, the separator can be set to one of the available presets (e.g. :, /, – etc.), or one of the users decides (other).

Finally, the order of date and time can be set. Time and date, or date and time.

Now, the question is: should an advanced setting be added where the user can set up their unique time/date format? Should it be made possible to save previously used formats?

Anyway, back to dealing with the mapping of recurring events to the data-model and the program interface… what fun.

One feature of iCalMaker I use a lot, and so do our users judging by their comments, is the comma/tab import feature.

So, what is it? Well, imagine you have been sent a spreadsheet of dates/appointments and you want to get them in to iCal…. well, you could type them in one at a time, or you could export the data from the spreadsheet as a tab, or comma, delimited file (tab works best…) and then import it in to iCalMaker for export as an iCal file, or directly to iCal.

Two major requests from users are more choices on the import besides just start time, start date, end time, end date and summary, and more options over the format of dates and times (this is required for date/time analysis).

Well, the code for comma/tab data import has been significantly re-written. This has two advantages:

1. More options for import can now be easily added (so far there aren’t any new ones added, but this should now be trivial)
2. Time/date formats can now be set. The user can either have them set to the system default, or use their own format (this needs some work in the program preferences).

The new comma and tabbed data import window

In addition, it is now possible to step forward and backward through imported data to see if the selected ‘types’ match.

The data input order can be selected by using the pop-up menus in the import window…

Selecting the data-import type

and if the same data-type is selected more than once then the import cannot be run (note the ‘Import’ button is not available), and a warning is presented on the window….

Import for tab and comma-delimited data files has been tested, and all seems to work OK…. another thing done (tick), and another step closer to releasing the new version of iCalMaker2.

Work is progressing on iCalMaker2… one new big change has been to the ‘format’ of the program. This change was made fairly early on, and at the request of the users…

One thing that iCalMaker does quite well is ‘sort-out’ broken iCal files. By broken I mean ones in which entries have been ‘duplicated’ or ‘mixed’ in some way.

However, a number of users commented that once data was imported in to iCalMaker there was no way to save ‘work-in-progress’. Yes, the data could be exported as an iCal file and imported later, but the problem there was iCalMaker would not allow iCal files to be saved IF there was a problem with events ending before they started (long story – but this feature was added to prevent ‘invalid’ events being produced).

To get over the ‘saving’ problem it was decided to make iCalMaker2 a document based application. What that means is iCalMaker2 data can be saved as it is worked on as a document, and multiple iCalMaker2 documents can be open at a time….

All part of some the improvements and changes that are now possible as a result of moving iCalMaker over to objective C v2.0, Xcode 3 and core-data….

In Mac OS X 10.5 (Leopard) (Amazon Link) icons are bigger and bolder, and there is ‘Cover Flow’ in the Finder for navigating through files

‘Cover Flow’ looks like this…

Cover Flow in Mac OS X 10.5 (Leopard) (Amazon Link)

A great way to look for files and navigate a hard-disk. However, the iCalMaker icon didn’t look too good…

The old iCalMaker icon in Cover Flow

So, a new one had to be produced…

The new iCalMaker2 icon in Cover Flow

As can be seen, the new icon looks a lot better. This is mainly because it is bigger!!! 512 x 512 pixels, as opposed to the old icon which was ‘only’ 128 x 128…..

With the data model of the iCalendar data standard (rfc2445) complete the next thing to do was move the old code from iCalMaker over to the new iCalMaker2.

Code in iCalMaker can be divided two main groups:

1. Code that ‘talks’ to the interface, i.e. what the user sees…
2. Code that does the ‘grunt work’, i.e. the code that processes the iCal data from ical files, comma/tab delimited files, does all the exporting etc….

The code in group 1 is not really needed any more as Xcode 3.0 uses ‘data-binding’ to link the data to the interface. This makes life a lot easier.

The code in group 2 is a different story. This code is the ‘guts’ of the program. It does all the work. Most of it can be moved over with very little change, just the odd ‘tweak’ here and there to tie the data generated by the code, to the data-model, and hence to the interface. This is fiddly, but can be done.

The first sections of code to be moved over were the methods for parsing the iCal files. This needed a re-write of some sections so the data could map to core-data model. This has been done, and had been successfully tested. In addition, new code has been written directly read from iCal. More on that later….

iCalMaker is being renamed iCalMaker2, updated to work with Mac OS X 10.5 (Leopard) (Amazon Link), and rewritten to take advantage of the latest features in 10.5, and Xcode 3.0.

The first thing that was done was to ‘model’ the iCalendar data standard (rfc2445) into an Apple ‘xcdatamodel’.

Part of the iCalendar data standard modeled in ‘xcdatamodel’

This was surprisingly difficult and took a lot longer than anticipated. The model is now complete.

With a working model it now means that data-binding can be used between the main code of the program and the interface. This has the advantage of speeding up development and providing a consistency in the way the data is handled. Plus, it means less code has to be written.

As I said in an earlier post, iCalMaker does not play well with Mac OS X 10.5 (Leopard) (Amazon Link), and that MMISoftware was working on a fix.

Work on the fix for iCalMaker started back in November, and is still going on. It looks like it is going to be a long haul and that the code-base for iCalMaker needs a rewrite… there are a number reasons for this.

iCalMaker was written back in the days of Mac OS X 10.0, using the earliest xcode (the Apple programming environment) and contains a lot of old code that is no longer needed, plus it wasn’t written to make use of the latest Mac developments.

Hence, time for a rewrite to clear out the old code, bring in the new, migrate iCalMaker over to the latest version of xcode, use core-data and bindings, and objective-C version 2 with all the advantages that includes.

Why the name change? Well, it looks like the new iCalMaker will not work with Mac OS Xs earlier than 10.5. Hence, I feel a name change is needed…

iCalMaker does not ‘play’ well with Mac OS X 10.5 (Leopard) (Amazon Link). It works, but some of the features are deliberately disabled.

When 10.4 was released Apple changed the way iCal worked. This caused problems with iCalMaker not exporting correctly to iCal. When this was fixed code was included so that iCalMaker would not export directly to iCal in Mac OS X 10.5 (Leopard) (Amazon Link) until everything had been checked.

When 10.5 was released Apple changed the way iCal worked again. And this time it has caused real problems.

There is a fix for iCalMaker the works and I hope to get a beta out soon. However, it is proving to be difficult as iCal works in a very different way now.

Meanwhile, you can still use iCalMaker with iCal if you go via the file route. Export data from iCal as a file, and then import in to iCalMaker, export data from iCalMaker as an iCal file, and then import to iCal.

Work started on an update of iCalMaker back in November. It has proved to be an interesting challenge and things have moved much more slowly than hoped. However, there is now light at the end of the tunnel…

Over the next few weeks there will be a number of posts on this blog charting the progress of the work, so stay ‘tuned’.

If you would like to take part in beta testing of the new iCalMaker then please drop me a line beta_test@mmisoftware.co.uk. I already have a number of beta testers lined up, but as usual, I am looking for a few more. (If you are interested in beta testing please note that the new version of iCalMaker will only work under 10.5 (Amazon Link).