在寫 JavaScript 的時候，可以使用一個叫做 window 的物件，像是我們想要從現在的網頁跳到另外一個網頁的時候，就會去修改 window.location.href 的位置；在我們的 Objective C 程式碼中，如果我們可以取得指定的 WebView 的指標，也就可以拿到這個出現在 JavaScript 中的 window 物件，也就是 [webView windowScriptObject]。
這個物件就是 WebView 裡頭的 JS 與我們的 Obj C 程式之間的橋樑－window 物件可以取得網頁裡頭所有的 JS 函數與物件，而如果我們把一個 Obj C 物件設定成 windowScriptObject 的 value，JS 也便可以呼叫 Obj C 物件的 method。於是，我們可以在 Obj C 程式裡頭要求 WebView 執行一段 JS，也可以反過來讓 JS 呼叫一段用 Obj C 實作的功能。
不久前公司信箱收到封信。來信的這位朋友說，他這幾年做網站做得非常膩，也覺得非常無趣，所以想要改做 Mac 軟體。
想改做桌面軟體好擺脫 Web，這種想法老實說不怎麼現實，首先呢，如果現在是想要做 iPhone 還是 iPad，可能還有點道理，以目前的 Mac 軟體環境來看，做 Mac 軟體大概就像寒天飲冰水，光是靠「不想做 A 所以來做 B」這種理由，實在不知道可以維持多久的熱情。國際巨星李奧納多．狄卡皮歐在電影《全面啟動》裡頭就告訴我們，光是負面情感，是沒有辦法真正深植想法的，今天做 Web 覺得煩了，誰知道哪天又覺得做什麼別的也煩了。
而且，做桌面軟體也不可能擺脫 Web。姑且不論 Google Chrome OS、Palm WebOS 這種擺明就要用 Web 技術實作桌面或行動裝置作業系統上的應用程式架構，或是 Adobe 提出像 AIR 這種用 Flash、HTML 與 JavaScript 就可以寫桌面應用程式的方案，現在哪一套桌面應用程式，幾乎都有或多或少的 Web 整合。
所有跟 NSWindow 相關的設計中，最讓人覺得麻煩的，莫過於 Field Editor。Field Editor 之所以麻煩，在於一開始遇到這個東西造成麻煩的時候，完全讓人想不到原來跟 NSWindow 相關。
前一篇提到 NSWindow 跟其他平台上面處理 Window 不一樣的地方，現在來講些一直以來我覺得 NSWindow 討厭的地方。
首先，在 Cocoa 對 Window 的設計中，有個你光看名字實在看不懂什麼意思，不看文件不可能猜得到的屬性，叫做 Key Window－你可以決定一個 Window 是不是 Key Window，也可以詢問目前的 Window 是不是 Key Window。
如果你有其他的平台的經驗，來寫 Cocoa 應用程式，可能會發現 NSWindow 的行為跟你想得似乎不太一樣。
前兩天心血來潮寫了一個小東西－ASCII Art 產生器（下載）。顧名思義，這個小東西就只有那麼一個功能－把圖片檔案轉換成以文字構成的 ASCII Art。
照理說應該 10.4 以上的麥金塔電腦就可以用（不過我現在手邊沒有安裝 10.4 的機器，所以我只能保證在 10.5 與 10.6 可以用）；程式碼都在 Github 上，如果想要自行編譯，您需要安裝 Xcode 3.0 以上版本（不過我現在用的不是 3.0，用的是 3.1.4…反正去找最新的 Xcode 來用就對了。）