Zonble and I have just released our first iPhone app on Apple’s AppStore: .

There are so many things happening around. Stay tuned! (And following tweets is also a good idea!)

We realized that Mondrianum 1.0b5 had expired on June 14–just as when we were on the trip back home to Taipei. We know, we did that again–quite a disappointment to many, and we learned that it even caused some frustration. A software developer always feels glad that his or her work is being helpful in people’s daily work and life, but also feels the pain when it causes inconvenience–our sincere apology for our lapse in this matter.

So today we’ve released the next version of Mondrianum, 1.0b6. This version once again extends the expiration date to September 30, 2008. Its watered-down Tiger sibling is available at this link, please download and copy the .colorPicker bundle to the ColorPickers folder under the Library of your home folder.

We have received some inquiries on when we’re going to be real, i.e. starting accepting payment and issuing registration code and stoping all those endless expiration thingy, or whether we’ll make it free at all… honestly, it’s still a tough question, just like we’ve explained a while ago. Such is the nature of any desktop application these days that depends on a web service. The API provider’s rights and decisions are to be respected. And we hope to bring out the best for the user.

Once again, our apologies to any inconvenient caused. And thank you all for the support of Mondrianum!

We made a mistake when we were packaging 1.0b4, so the Installer script would tell you that the installed product would expire in end March, which was not right–although it didn’t affect the real function, it was indeed a bad thing that caused confusion. Sorry about that! Hopefully the next releases will be smoothier, and thanks again for bearing with us for the rough edges!

We have always liked to idea of desktop-Internet integration, and Mondrianum is one of the little ideas that turns out to be a very useful tool for many people. It makes Adobe’s kuler instantly available to many desktop applications on Mac.

We have been thinking of making Mondrianum a commercial product since Day 1 (Day 0 actually, being programmer speak). As kuler requires developers to obtain the permission to use its API for commercial purposes, we’re now working on the process of getting it.

We do have some urgent tasks at hand for the past two weeks, but we shouldn’t have let the expiration slipped in at the first place. We apologize if it has caused any inconvenience to you.

Ok, that’s the thing. For the Leopard version of Mondrianum, we have come up with yet another interim release that extends the expiration date to May 15, 2008 (GMT, not Taipei Time this time :). And also after some debating, we have decided to release a trial Tiger version–a functional version without the cover flow component that its Leopard sibling has. That is an intended omission as we have tried a few replacement ideas, none of which worked really that well.

So for Leopard users, just download the latest disk image from here. For Tiger users, please also download the image for documentation. As for the color picker itself, here’s the Tiger version. Just drop the decompressed file to your ~/Library/ColorPickers folder, and that’s it.

Thanks for everyone’s encouragement and interest in our humble plug-in.

From what we have learned so far, they are for real. At the moment, Apple’s own developer site is overwhelmed by the download traffic, and we have no luck to get a quick peek at the new things–free!–with which we are at the same time all familiar: Cocoa, Xcode, Interface Builder. In short, they provide us a platform to which we can quick transfer our desktop skills. And Apple has solved the distribution puzzle and given all developers the definitive answer: the iTunes App Store.

So this is what we have learned so far. We’ll get the SDK once it’s our turn to download. We’ll start do our homework (and yes we have been reading Craig Hockenberry et al. on previously learned facts of what a native SDK would offer to developers). Homework time!

We’re gladly surprised by the popularity of Mondrianum, hence the decision to serving you the file from another server. We’re working hard on fixing the bugs (and thank you all for reporting them to us) and on polishing the UI further. Hopefully we’re have a new release soon. Until then!

Since its release on Monday we have received many positive feedbacks and also requests for a Tiger version (we didn’t expect that request could be so strong). So it’s on our to-do list now, we’ll work on that. The first Tiger port might not have UI components as shiny as Leopard’s cover flow, but we’re sure the core features will be there, to make a bridge between the cool content and community that is kuler and native Mac apps.

As we have explained earlier, the Cocoa part in our plug-in’s former name is a misnomer, hence the name change. We hope this makes a helpful utility for your creative work life–and feel free to let us know how we can make it better.

One final note: Mondrianum is currently a free beta. You can try it until it expires on February 29, 2008.

Thank you!

Mondrianum can be downloaded here:

http://www.lithoglyph.com/mondrianum.

At Lithoglyph we follow this great insight and develop our internal working code solely on the principle of encoding agnosticism. Even we use char, we are using it as if we were using unsigned char. We only use the byte semantics, and we use UTF-8.As a developer of Mac OS X software we are lucky to be able to use UTF-8 for most of our life. Cocoa's NSString uses UTF-16 internally, but comes with two nifty and apropos methods to work with UTF-8. The class method, NSString's +stringWithUTF8String:, and the instance method, -UTF8String, are all you need for interfacing your working parts (say string processing code written in C++) with user interface code written with Cocoa. Also the good thing is the compiler always translates @"string" into an NSString (which is UTF-16 internally). But don't ever use non-ASCII characaters in that--you'll need to use [NSString stringWithUTF8String:"ああ"] for that.

We have later developed a similar strategy on Windows. The rule is simple: We maintain the usage of UTF-8 throughout the internal workings, and interfacing with Windows only using UTF-16, or actually wchar_t and wstring.It's a known (and misfortunate according to some) fact that the Windows platform has a plethora of string libraries (think of Microsoft's own Standard C Lib, Platform SDK [Win32], MFC/ATL, then CLR, and we're not counting libraries in VB and OLE), and many of them have then two (or three) variants: ASCII (actually, "such that conforms to the current running Windows's code page"), Unicode (UTF-16LE). There is also MBCS (multi-byte character set, like UTF-8) that is often counted as ASCII, but sometimes stands out sui generis. From a historical perspective, those different libraries have existed for their own reason. It's easy to deride Microsoft engineers' nearsightedness, but let's not forget a culture like Windows's has its own burden to bear (which is not easy to shake off), and therefore there is always compromise (reads: backward compatibility for all!) in the design.

Excellent books like J. M. Hart's Windows System Programming offer programmers a few choices, or some “Unicode strategies”, one of which they should pick up in the very beginning when they’re into the platform. We take the advice of Hart’s book, and choose to use Unicode throughout.

In fact, we often use W-ending API functions explicitly in some low-level code so as to tell others that don’t ever think this will work with the so-called ASCII environment anymore. I think that’s a very important point to make. We live in 2007, almost 2008 now. There’s no point to use “ASCII”-based API anymore.So to sum up, UTF-8 throughout the code, UTF-16 when interfacing OS X and Windows.But what about locale-specific processing like sorting names? Our observation is that it’s best to leave that part to the UI–and fortunately 99% of the case it’s the UI that needs to be locale aware. We try to design internal workings as locale neutral as possible. This not just fits in our belief in encoding agnosticism, but it can also yields efficient code–because we can still use stdc’s qsort or C++’s generic sort without much worry. We let the UI code (and anyway both OS X and Windows have their own excellent libraries for that) deal with the locale.