fiat lux

OpenVanilla just had its 2nd birthday. It was born in the form of a little .h file on the Twenty-Third of October in the Year of Common Era Two-Thousand-and-Four. We’re well into the third year. I’m really glad that it helps many people and is both useful, innovative, and fun.

As the operating system and desktop environment grow over time, OpenVanilla must catch up too. Many edges are becoming rough again, and some of its code base begins to show its age. We’ll continue polishing the rough edges and hopefully we’ll come up with features that are again both useful, innovative, and fun (WebKit-based candidate/feedback windows are high on the list).

Without you support, OV wouldn’t be what it is today. Thanks everyone!

When it was three weeks old: the first functional POJ module

lukhnos :: Oct.24.2006 :: tekhnologia :: Comments Off

I’ve started putting in HeaderDoc tags into ObjectiveFlickr header files. Which marks the beginning of documentation work. The framework has been stablized, and I feel good about it. Now what is needed is a really good documentation. A dedicated blog and nightly/weekly builds will be in the sweetspot, too.

It’s almost done. Another two or three days and the documentation should be there.

lukhnos :: Oct.20.2006 :: tekhnologia :: Comments Off

The refactor work is now done. I’ve broken lots of things for lots of reasons. But all in all I hope this eventually becomes a production-grade framework, with details such as naming convention being taken minute care of.

Now there is documentation work to do. I’m thinking about using Apple’s own HeaderDoc tools to write the in-the-code documentation, and use the tools to generate HTML document for me.

And I’ve added another example. This is done after Ruby on Rails’ screencast (on how to use RoR to create Flickr public photo search). I have even copied their CSS. Working with WebKit is always fun, and ObjectiveFlickr gives you the power of accessing Flickr method and return data blocks in native Objective-C. Because of limited time, I only wrote a Chinese blog entry on that, but you can always download the latest build or use the source to see for yourself.

I know. The current state is very, very far away from anything “production grade.” Even my blog theme is lacking in that they are totally inadequate for project hosting purposes. I have to work harder on this.

lukhnos :: Oct.08.2006 :: tekhnologia :: 1 Comment »

Lately I found you can actually call valueForKeyPath: to retrieve a key from deep dictionary-array combos, such as [aDict valueForKeyPath:@"a.b.c"] instead of [[[aDict objectForKey:@"a"] objectForKey:@”b”] objectForKey:@”c”].

Apple calls it “Key Path” (à la XPath?) and it plays an important role in Key-Value Coding/Observation. The biggest problem, however, is that it uses the symbol “@” to perform some functions on array data (e.g. you can do average or count or total, those db/spreadsheet thing, using @ modifier in a key path).

That is in direct conflict with ObjectiveFlickr’s current XML-to-NSDictionary convention, which follows BadgerFish’s XML-to-JSON convention, ie. using @ symbol to mark that it’s an attribute of an XML tag.

Either I’ll have to move attributes to another key, e.g. aTag._attr, or have to use another symbol that is not “@”.

In any case, I’m going to break that part of ObjectiveFlickr. I don’t want to write three left brackets just to retrieve a key, it’s too ugly. KeyPath is a better way, but unfortunately the symbol “@” doesn’t fit into the picture. Only had I knew it before I designed!

lukhnos :: Oct.02.2006 :: tekhnologia :: Comments Off

I just came back to Taipei and will spend the next two days in Chutung, attending HappyDesigner’s second gathering and catching up with friends.

For the last two days I have been refactoring the framework. One thing that I have to say is that, since ObjectiveFlickr is still in a very rough and early state, each new version mak break somewhat what was available before…

I’m thinking about removing OFFlickrRESTRequest altogether, creating an OFFlickrHTTPRequest instead. In fact it’d be nice to have a HTTP transport class, because we may also want to fetch the image–you don’t want to do that with NSImage’s initWithContentsOfURL, it’s blocking your code!

We will actually need two HTTP transport classes, one for regular GET/POST requests with a potential large return data, and another for doing large POST request (i.e. “uploading”). This is because NSURLConnection is not good at doing large POSTs… well, at this point I was actually thinking, if we should scrap NSURLConnection altogether and simply use CFReadStream for everything?

There are other design considerations, such as simplifying the error codes, and making classes Key-Value-Coding compliant. In addition, there is actually a very nifty way of getting Flickr XML data that is converted into NSDictionary (using flickrDictionaryFromDocument method), which is called “value path” and is a part of the KVC convention. I haven’t tried out that yet.

In the end, all those async things smell like reinventing the wheel of XMLHttpRequest… why didn’t we simply create a WebKit object and make Javascript work for us? Or maybe some AOCX (OC for Objective-C) may eventually surface. Who knows…

Lots of work ahead, will keep you posted on the progress. Before then, if you’re already using ObjectiveFlickr, I’m eager to learn to which extent are you using. Some things will really break in the next few revisions…

lukhnos :: Oct.01.2006 :: tekhnologia :: Comments Off