The Old Blog Archive (Traditional Chinese), 2004-2009

Archive for the 'tekhnologia 技術或者藝術' Category

OpenVanilla on Linux/FreeBSD 的近期更新

Update: llwang也包裝過FreeBSD port,原文被我誤植的HTML code遮住了,特此更正。

OpenVanilla 在 2005 年春天時曾經發布過一個透過 SCIM 能夠在 Linux/FreeBSD 的 X11 環境下使用的輸入法套件。這個部份是由 vgod 完成並準備出第一份 Debian 套件,後來有 llwang 的 FreeBSD portmarr 的 RPM 包裝等套件。在此之後這支被稱為 OV-SCIM 的 loader 便進入開發停滯,然而在最近一個版本 (0.7.2) 中,OV-SCIM 仍然是可以順利編譯使用的。

在測試過 OV-SCIM 仍然可用,並且可在例如 Ubuntu 6.10 Installer CD 這樣的環境下使用後,我想該是時候來做一點修改的動作。

於是,OV-SCIM 在沉睡了一年半後,又開始動了起來。其中長久以來一直缺乏的設定管理(config management)和游標支援已經完成。

我們在這邊準備了一個可以 untar 到 Ubuntu 環境的套件,可以從這裡下載。下載完只要 sudo untar 到 Ubuntu 環境(或 Ubuntu Live CD 下),就可以使用了(可能需要重新啟動 X11、scim 或者調整 XMODIFIERS 等設定,在此不詳述)。

包裝內容包括 OV-SCIM Loader、幾套常用的 OV 輸入法模組(泛用模組 [包括倉頡、簡易、大易等]、傳統注音、台灣閩南語白話字 [Holo POJ]、行列、藏文),以及 OV 需要的 ltdl 程式庫。

以下是最近一次更動的說明:

  1. 在設定管理方面:這一版的 OV-SCIM 會將設定檔存在 ~/.openvanilla/ 下面的 org.openvanilla.[版號].plist 中。.plist 是蘋果公司的property list XML,也是 OS X 版本的 OpenVanilla 所使用的設定檔。這個版本使用和 OS X 一模一樣的設定方式和鍵碼配置,因此先前因為沒有config management而無法完整使用的模組(尤其是泛用輸入法的大易、簡易等),現在可以正常使用了。另外,使用 .plist 的設計哲學也與 OS X 相同:任何人可以用任何方式或任何程式去修改這個檔案,OV 會在偵測到檔案有變動時,通知輸入法模組更改設定。這樣一來,OV偏好設定程式,可以用 GTK、QT、ncurse 來撰寫,或者就只是使用 vim 來修改 .plist。
  2. 增加了游標支援。對於有使用到此一功能的輸入法,終於可以正確地使用方向鍵了。

技術說明和目前的問題如下:

  • 這一次的設定管理,是使用了第一個重構完的 AmphiVanilla 模組 AVConfig 來完成的。AVConfig 使用了 expat 這套 XML 程式庫來解譯 .plist 檔案。選擇使用 expat 的理由有二:(1) 它是 Ubuntu 本身即安裝好的程式庫、(2) 它在其他平台(例如 Windows)上的佈建也已成熟完整。當然另一方面也是藉此機會瞭解了一下 expat 的使用方式,發現比想像中簡單得多……
  • SCIM 的輸入法是可以指定一個 icon 的,但因為我不熟悉 autoconf 的用法,不知道怎麼樣在 make 時把圖片安裝到指定位置上。
  • 承繼上一個問題,因為 autoconf 設定不熟,目前 include AmphiVanilla 的方式,是寫死在程式碼中的。
  • 還沒有轉碼和 OV 所需的狀態列 (OVService::notify) 支援。不過之後當 OV 也 deploy UTF-8 的酷音時,也許我們完全可以進入到無需轉碼的時代(OV 目前 deploy 的仍是 Big5 版本的酷音)。

測試套件可從 openvanillla.org 的 beta 測試區取得。以下是 screenshot:

OpenVanilla on Ubuntu

照片網站的API戰爭:ObjectiveFlickr觀點

前陣子FlickrBoothTUAW有提過)作者Tristan O’Tierney寄信來和我討論在ObjectiveFlickr中加入Zooomr註1)與23HQ API支援的可能性,於是研究了一下。

這兩家照片網站都號稱建立了一套和Flickr一模一樣的API layer,在去年春天時還頗引起一陣轟動,特別是Zooomr因為還去跟Flickr申請commercial API key來搬資料,弄得很是熱鬧(以商業觀點,這是很成功的PR戰術)。兩位朋友的試用報告可以看這裡這裡

我對照片網站的興趣缺缺,又是Flickr滿意的付費用戶,因此並沒有很想去深入瞭解Zooomr和23HQ有什麼特別的地方(註2)。但是兩家不約而同地跟進使用Flickr API layer是挺有趣的發展。那麼,API developer的眼中看到的Zooomr和23HQ會是怎樣呢?

雖然說Zooomr號稱照著Flickr API做了一套,事實上還沒有完整移植。目前能用的只有upload和簡單的照片查找而已。這個技術選擇,目的不證自明:要讓原本Flickr的上傳工具能無痛移植到Zooomr上。但是簡單兩件事就讓我對目前狀況抱持保留態度:首先,Zooomr必須要使用e-mail來申請API key,而Flickr的non-commercial API key是可以線上申請的。光是這一點就讓想要提供Zooomr支援的人卻步了。雖然ObjectiveFlickr大可不管這事(反正要申請API key的人是那些要寫uploader的),但我也想要有API key來做unit testing或測試我的demo app。如此一來我就只好寫信和等待(他們blog留言上有人說寫信去了很久還沒回音,也不見該公司的人出來澄清)。而在此之前我只好不release Zooomr support了。

除此之外呢,Zooomr的static photo URL規則竟然也和Flickr不同,而Zooomr在blog上竟完全不提這件事,彷彿他們最希望convert的對象,就只有uploader的作者們。而Zooomr在張貼完該篇blog之後,就再也有後續消息啦。Google “Zooomr API” 竟然什麼都沒有,還是找 “Zooomr blog api” 才在第三名找著。光是這樣一陣折騰,我就想轉台了……

至於23HQ呢?其實是因為意外讀到有人藉更換FlickrBooth裡的ObjectiveFlickr來使用23HQ上傳,才知道23HQ原來也照Flickr API複製了一整份。比較起來23HQ就兇狠多啦,不但Flickr API已經移植得差不多了,連手冊也都大方地連到Flickr那邊,不用再多寫什麼。URL endpoint完全無痛轉換,包括static photo URL也都照Flickr格式(23HQ甚至還寫了這個網頁教你怎麼”switch”)。但是比較奇怪的是23HQ竟然提供了Flickr早就不用的舊式authentication(讓使用者把帳號和密碼放在HTTP GET參數裡!)。還有一個不知算是優點還是缺點的東西:23HQ不需要申請API key。照他們的說法,你要不就是自己隨便選一個名字,要不然直接用你在Flickr拿到的API key也是可以的啦…… 這點就讓我不太放心了,總覺得這像是某種收集API key的陰謀(雖然shared secret是收集不到的),除此之外我也在想:不用API key,是否代表API usage monitoring也就隨便做了,難道23 HQ不怕有人寫惡意程式搞死他們的API server嗎……?

23HQ倒是有API forum,這點就比Zooomr強太多了。顯然要在API war中佔塊地,恐怕還是得像Joel曾說的,developers, developers, developers! 但是23HQ只支援REST似乎是致命傷,因為有太多XMLRPC和SOAP的程式庫,這對「傳統」一點的desktop app發展者來說仍然挺重要的。

結論是什麼呢?我想 23HQ 在「照著 Flickr 刻一套」這個criteria上,顯然比 Zooomr 要高明多了。不過 Flickr 的 API 也日新月益,仍然每幾個月又多吐幾條新的 API method 出來,讓大家很是目不暇給(就這點上,Flickr 顯然學到了微軟的招式)。而 Flickr 前陣子也更新了自家 static photo URL 的格式,對上傳和其他工具的開發者來說,大概又有得忙了,如此一來,對23HQ、Zooomr或其他家網站的支援,是否就因此會被擱到較後頭呢……

雖然鄉民們一定會說lock-in是壞事,但Flickr的API已經完整到寫個「把自己所有照片通通搬回來」不是問題的程度,所以「Flickr只進不出」的說法,恐怕是FUD。至於技術上呢,Flickr自己就是自家API的最大消費者(但是要用他們家API做一套跟Flickr一樣的網站則是被禁止的),而Zooomr看來是先有了照片網站,才開始做相容性layer。

ObjectiveFlickr針對23HQ做了一些測試,發現傳回來的response block有一些問題,上傳等候回應的速度也和Flickr完全不能比(不是連線速度,而是傳完照片之後,等待XML response block的時間)。

如是觀之,後發者要靠 API 與大玩家搏一局,或者要爭取 developers 跳船換旗,看來還有很多關鍵細節得照顧。

(ObjectiveFlickr最新的原始碼已加入23HQ支援,近期內發佈新版。)

註解

  1. 是 Zooomr 裡面有三個 o。裡面只有兩個 o 的是個蟑螂站(不想增加他們 page rank ,就不連過去了)。嗯,這樣的命名策略很不好啊……
  2. Zooomr號稱以本地化語言做得好為特色(事實上23HQ也是如此)。這點表面上看來對Flickr確實有可能造成威脅──例如這一封顯然是講西班牙語的人所貼的post(只要看英文的部份就可以了),就直陳Flickr沒有西語介面的種種不是,Flickr則說,localization不是那麼容易的事。以我簡單晃了一下23HQ和Zooomr的中文介面的感覺(唔,Zooomr我順便也逛了法文和日文的),呃… 我覺得他們能先把「一兩種語言」做好,就應該要覺得滿足了吧。

2006年OpenVanilla捐款收支年報

各位朋友,

謝謝大家這一年對OpenVanilla的支持。

OpenVanilla從2005下半年開始接受捐款,今年(2006)六月則為了WWDC和蘋果在北京的輸入法工作坊,而辦了一次募款活動。我們達成了目標,也順利成行。希望OpenVanilla能一直為大家帶來便利,相信這對台灣及華語地區的open source開發者,也是很大的激勵。

我們自2005年至今,一共募得了新NTD 67,300.-(新台幣部份)、USD 2,639.85(美金部份),今年支出為新NTD 41,500.-(新台幣部份),USD 1,295.-(美金部份),總結餘全部換算為台幣,為NTD 69,764.-。

今年度的捐款收支及支用情形,已經編整為年終報表,全文請從這裡下載或閱覽(使用 gpg 簽名過的純文字檔,UTF-8編碼)。

最後,再次謝謝所有一路支持 OV 的朋友們。

新年快樂, happy new year, あけましておめてとう, bonne année ! :)

散播音樂、散播愛 (buggy version)

本來是在寫程式測一個 OS X 繪圖功能的,結果出現了 bug ,然後變出了這張圖:

spread da music spread da love

漢字的部份不但沒上色,還有如被離心機甩到了邊旁。

好了,我要繼續抓bug去了。

(update: I caught the bug.)

Web 2.0 Visual Design, 1928 Style

一張1928年的海報。Theo H. Ballmer (1902-1965) 作品。”Büro”在德文裡有「辦公室」的意思。紐約市現代藝術館(Musem of Modern Art, New York City)。

正所謂法國人說的,「改變越多,事情就越是一樣」(Plus ça change, plus c’est la même chose)……。

Frank O. Gehry談雜誌

芬德萊──方才談到了批評,蓋瑞先生幾乎沒有從建築同業方面得到奧援,反而一直受到藝術家們的激勵,目前在日本的建築界,這也是一個重要的課題。不知道眼前建築科系的學生們,對所謂的建築報刊雜誌或關於建築的評論,抱著什麼樣的看法呢?…… 又,你對建築報刊雜誌有什麼看法呢?

蓋瑞──我在年輕的時候,就推掉所有送到我事務所裡的雜誌,也堅持不看所謂的專業刊物,因為我覺得刊登在雜誌裡的內容,看起來就像在展示流行一樣,這些和我在做的東西,或是我應該做的東西,完全沒有關聯,而且還會因此受到一些無關緊要的事影響,所以我把那些刊物全都丟掉,我年輕時就對這一點有所覺悟了。

我認為比起閱讀專業雜誌,更重要的事情是找出自己的才能,發現自己的力量,亦即去了解自己擁有什麼和別人不一樣的特點。雖然你可能會懷疑那個特點不是具有優勢,或是沒有把握它會不會比別人的更好,但那都無妨。總之重要的事,去找出那個不同的地方。想想心中那個想做些什麼事的想法,然後去完成它,那才是最重要的。如果在那個時候還去瞄到別人的作者,就可能會不安地懷疑自己的東西到底行不行,而變得神經質了。我曾經在想,幸好在我年輕時,還沒有安藤先生〔安藤忠雄〕這號人物,否則如果當時我看到了他的作品,就會在心裡驚嘆著:「真是太厲害了!真是太棒了!」那麼我就會認為自己一定沒有辦法超越他,做出比他更好的東西。所以各位,絕對不要被這類的雜念煩擾著。

就像簽名時每個人的筆跡都不同那般,不斷地反覆磨練屬於自己的想法,如此就會漸漸地雕琢出一個更清楚的輪廓,這是非常重要的。[......]

或許各位之中,也有人對親自做設計不是那麼有興趣,不過建築不是獨自一人可以完成的工程 [......]。我所承攬的案子裡,每一個都是非要團隊合作才能完成的,而恰好每個人都擁有不同的才能,我非常感謝上天有這樣的安排,讓大家的長才不盡相同,這樣才能互相彌補不足 [......]

〈法蘭克.蓋瑞 Frank O. Gehry,1998年10月29日,主持人凱塞琳.芬德萊 Kathryn Findlay〉,《建築家的20歲年代》(建築家たちの20代),東京大學工學部建築科 安藤忠雄研究室編,謝宗哲、黃曦穎譯,台北:田園城市,2003。

入力快適感滿點!

我終於又有日文輸入法可以用了。

OS X 是有內建的日文輸入法 Kotoeri ,可是 OS X 只要裝一種以上的中日韓輸入法,輸入法切換的行為就變得相當惱人──這一點,在WWDC 2006上,已經被許多同樣需要多語輸入的與會者抱怨過了(顯然再次驗證了「什麼不孤,必有什麼鄰」這種顛撲不破、放諸四海而皆準的真理)。

也因為這樣,在 OV-UIM (Anthy) 開發出來後,我就一直很高興地用 Yatsu-san 包裝的 UIM.framework (附於 MacUIM 中)配合 OV-UIM (Anthy) 來輸入日文。同樣在 OpenVanilla 裡的好處是,可以使用 OV 的快速鍵來切換注音和日文,入力快適感滿點。

可是,因為 MacUIM / UIM.framework 仍是 PPC-only ,因此在 Intel Mac 上是無法使用的。為了這一點,困擾了我很久。在入力法燒鳥會上,Yatsu-san 說會努力(最近 MacUIM 出了 0.5.0 ,確實在 build system 上有些改變),我相信不久之後,我們一定會有 MacUIM 的 universal binary 版本的。

倒是,今天靈機一動,突然想到,其實 OV 是 universal binary ,意思是可以在 MS Office 這一類 PPC-only 的環境下執行。那麼,MS Office 顯然可以把 OV-UIM 以及 UIM.framework 給載進來(如果在 i386 環境下,因為 UIM.framework 沒有相對應的 binary,OS X 的 loader 會拒絕載入,使得 OV-UIM 載入連帶失敗)。

就是這樣。

用 Finder 在 Safari.app 上按 Command-I ,把 “Open using Rosetta” 選項打開,此時 Safari 就變成了一個 PPC application,然後開啟 OV ……

OV-UIM (Anthy) 復活了

啊,三個月了,終於又有好用的日文輸入法。先前偶爾還有跟日本友人書信或 instant messenger 往返的,其實都因為不喜歡在 OV 和 Kotoeri 間切換,頓時沒有了學習書寫日文、學著用日文說話的動機。

如今這些動機又都回來了,雖然必須用 Rosetta。

(是的,這時候覺得,OS X 上有那麼多種 browser ,其實是很幸福的──我把 Camino 撥過來變成「寫日文專用 browser」好了 XD)

註:在 OpenVanilla 裡的另一個好處是,可以透過 filter ,達到打日出簡(?)等奇怪的特技。至於入力娘嘛……

… 有比唱《北国の春》更重要的事 :~

以後如果我有小孩,小孩可能會怨我。興致還在想唱《北国の春》之中,結果竟然忘了昨天還有一件比唱歌更重要的事:

OpenVanilla兩歲了(2004/10/23)。

嗯,在秋天出生的程式嘛…… (rev 1的OpenVanilla.h)。

小孩三週大,蝦米攏毋驚:第一個能用的 POJ 模組

明體(明朝體、宋體)與基督教

摘自日文版Wikipedia (thanks gugod for pointing this out),原文是很長的一段:
Continue Reading »

ObjectiveFlickr Demo小更新

結果發現,PhotoSearch.app 竟然忘了建 PowerPC 版本了。已經更新(請重新下載同一個 ObjectiveFlickrDemo-latest.zip),造成大家困擾真是抱歉。m(_ _)m

« Prev - Next »