Fred's blog

自 HanGee 國民機運動發起之後，我們開始從一個全新的思維和高度，來看待這個手機科技產業到底需要些什麼東西，甚至是創新發明這件事的困難是什麼。尤其是排除掉鬼遮眼的短線商業問題後，專注考慮怎麼讓產業提升、科技產業改變，更可以發現有很多東西是我們可以去嘗試的 其中，使用者介面（User Interface、UI/UX）是一個相當重要的課題，當人類和使用者越來越依賴顯示和觸控技術與機器溝通，虛擬形式的使用者介面就更是不可缺少。因此近年來，這也是許多科技人之間的熱門話題。只是，在我們深入了解後發現，仍然存在許多可以改進的空間。 講可以改進，並非是我們真有一個絕佳的 UI/UX 想法，或是覺得現今已經存在的使用者介面和模式有什麼不好，而是我們認為，設計方法和工具有很大的進步空間。我們都相信，在手機產業蓬勃的今天，設計師們早就已經花了大量時間去研究使用者的行為，並為其設計出不少使用者界面，甚至直到此時此刻，世界上隨時都有新的 UI 被設計出來。不過最大的問題是，設計師腦中的想法很容易被創造，但可以用的原型（Prototype）卻難以被製造出來，需要很大的成本和很高的門檻。 的確，打造實際可以用的原型（Prototype）無論在哪裡，一直都是人類進步的過程中最大的問題之一，更可怕的是，往往人類的思考和創意，都因為牽就工具和打造原型的方法，而受到挶限。還記得在你設計出一個自認傑作的使用者界面當下，工程師告訴你做不到時，你有多麼難過嗎？還記得你告訴自己開始要有 Sense 的去設計 UI 後，你總是設計出平淡無奇的作品嗎？這些都是我們被制約的實際例子，當我們無法很容易取得或使用多彩多姿的顏料，我們就只能畫沒有色彩的素描，你我的創意和創作就沒有了明天。 那麼，我們可以做些什麼呢？ 事實上，就在 HanGee 國民機運動開始不久後，筆者就建立了一個『 UI 先進技術研究組』，並創造了一個名為 OwaNEXT 的專案，試圖找尋協助設計師更快打造出 UI 的方法，然後進一步設計出可用的工具。如果可以讓不懂程式技術的人和設計師，都能輕易打造出可用的 UI 原型，而且能夠真正直接被使用在實際環境上，勢必能讓 UI/UX 領域的工作和視野往前跨更大一步。 OwaNEXT 的名字由來，一方面是以 Owa （芋頭的台語念法）來呼應蕃薯（HanGee），另一方面是向已逝的 S...

在上個星期剛結束的 OSDC.tw 2014 活動上給了一個 Talk ，提及用 Node.js 結合 QML 來開發應用程式，讓我們可以使用 Node.js 和 JavaScript 來寫 QML 元件，不需要再使用 C/C++。事實上，這樣的技術看起來簡單，但實際上是困難重重。 其實，要做 Qt 的 Node.js binding，有很多問題要克服，最直接的不外乎是 Event Loop，Node.js 本身是 JavaScript 語言，所以有自己的事件引擎，而 Qt 是一個圖形界面的 Toolkit，一樣也有自己的事件引擎，因此，我們要再解決一次與過去整合 GLib 一樣的問題（詳見舊文： 探究如何整合 GLib Main Event Loop 和 Node.js 的 libuv ），只不過這次要實作的是 Qt 的 QAbstractEventDispatcher。 為了讓 Node.js 可以順利驅動 Qt，筆者之前花了一些時間研究，所以有了一個實驗性質的 Project 『 Brig 』在 Github，也為了 Qt 重新寫了一個新的 libuv 版本的 EventDispatcher。很幸運的，在實作完新的 EventDispatcher 後，已經可以順利的將 Node.js 和 Qt 的 Event Loop 接起來。 但別高興的太早，還有個大問題存在。Qt 5.2 之後將 QML 內的 V4 JavaScript 換成了 Google V8 JavaScript Engine，並且為了一些特性，修改了 V8 的部份實作。很不巧的是，Node.js 的核心也是 V8，這意味著，如果我們使用自己的 Node.js Binding 去建立 QML Engine，程式會馬上崩潰並結束（Segmentation Fault）。 種種問題，你可以說這是 Node.js 的原罪所致，這也是為什麼相當難幫 Qt 寫一個 Node.js 的 Binding，你在 NPM 上也根本找不到良好的 Qt Module 存在。最終我們的做法，還是修改了 Node.js 的部份程式，才能將他們整合在一起。

去年一年在萬里當兵，基隆對我來說就像旁邊的公園一樣，時常去走走逛逛，然後去廟口吃點東西，最後吹吹帶有奇怪味道的海風，然後依依不捨的回去萬里山中隱居。很遺憾，黃色小鴨在我退伍的第二天，才來到基隆，一直沒機會去看看牠，這也是為什麼我為這次的 Talk 取了一個這麼奇怪的題目。當然，在 OSDC 的活動上，大多數人無法理解這樣奇怪的主題，所以我也在場上直接換了一個時事標題，詳見已釋出的簡報檔： 本次簡報的主題，將提到如何使用 Node.js 開發一個 QML 應用程式，以及如何使用 Node.js 去括充 QML 的功能。QML 能讓開發者很快設計出極酷炫的 UI，但最大的問題是他擁有一個殘廢的 JavaScript 支援，所以任何額外的功能擴充，都必需學會 C/C++ 才能達成，相當的難以開發。 此外，在過去如果 QML 要與 Node.js 做橋接，通常都是以 Node.js 建一個本機的 HTTP Server，然後運用 QML 內建的仿 XHR（使用方式和 API 真的完全模仿），去本機 HTTP Server 要資料。或許這對很多 Web 開發者來說相當容易上手，但有趣的是，他不會有 jQuery，所以你要自己手刻 Ajax 的各種機制，甚至是 Long-polling，痛苦至極。 想一下，我們即便是要與本機溝通，取得或監聽機器上的一些資訊，都要使用 Long-polling，這未免也太小題大做，一點也不簡單和直接。所以這也是為什麼要做 Qtjs，讓我們可以用 Node.js 直接來開發 QML 的元件，直接與 QML 溝通和傳遞資料，而不必再透過 HTTP 的方式。 就以本次簡報的例子來說，我們用 QML 設計了一個 IRC 聊天室的前端，然後運用 Node.js 和第三方模組去連線到 IRC Server，最後把聊天內容收回來畫在 QML 的界面上。並使用 Node.js 設計了一個 QML 元件，使用方式如下： IRC {     onReceived: {         console.log(nickname + ': ' + message);     } } 註：過去開發 QML 元件必需使用 C/C++，...

你可能已經知道，我最近相當忙錄，到處奔走，犧牲睡眠，不為別的，就是為了 HanGee （台語發音：蕃薯）國民機運動。過去，心中一直抱持著想改變產業、改變世界的想法，雖然一直在用自己的方式推進，但總是缺少契機去做更大的發展。令人相當意外的是，這次一樣是在自己的 Facebook 動態上許願，許了親手打造國民機的機會，本以為如同過去一樣會石沉大海，但換來的是短短兩天內，幾千個讚的回饋和熱烈支持，一直到現在，關注的人、企業和媒體也越來越多。 說實在的，剛開始我僅僅只是想藉由自己的手，完整參與打造一支手機。但是到了今天， HanGee 國民機運動的目標，已經不僅僅是打造一支手機，更重要的是，藉由打造手機的過程，讓世界能透過『HanGee』看見台灣的科技實力和人才；集結有想法，有能力的人們在這個開放創新的過程中發光發熱，共創價值。 這一個多月以來，看到許多業內外的設計、科技、行銷企劃、學生和富有想法的人才陸續加入，更讓我覺得，當我們能夠靠自己發願的力量，把世界上這最複雜的科技產品打造出來，實踐改變和刺激產業昇華的夢想將不是遙不可及！ 我想，這個共創的過程一定能造就無數種創意可能，而創意最後的落實能力，就是台灣的產業優勢，或許也讓我們在社群共創的開放歷程中邀請他們，HanGee 將試圖打造一個完善的開放平台，廣納各方的想法和資源，然後藉國內產業的能力優勢，進一步成就共創價值。如果 HanGee 運動能成功，除了一支手機會誕生，屆時，這裹也將證明台灣是世界上各種創意的實現中心，世界創新的凝聚地。HanGee  開放創新的構想是一場台灣科技公民的冒險行動，歡迎人人都加入了這個未知且令人興奮的旅程。 接下來，HanGee 將會隨著打造手機的過程，逐一建立起線上共創（Co-creation）平台，包括投稿平台、解決方案整合平台等，並著手打造許多工具和標準，讓各界都能參與過程，建立對話平台，讓產業也能持續創造價值。 有興趣的人可以造訪 HanGee 的官方網站： http://han-gee.com/ 也歡迎加入 HanGee 的 Facebook 社團，貢獻你對國民機的想法，或是出一份力讓我們更接近目標： https://www.facebook.com/groups/HanGee/ 無論你是個人還是組織單位，無論你是否為科技圈的人，亦...