Fred's blog

既然要投入 JavaScript 的發展，一個很重要的目標就是讓 JavaScript 能被用來開發 Native 桌面程式。而為了達成這樣的願景，我們的團隊沒日沒夜的發展各類基礎技術和擴充底階 API，甚至是將以 JavaScript 開發整個桌面環境（Desktop Environment, 如：GNOME、KDE、LXDE 或 XFCE 這類專案）為終極目標。 當然，跳出瀏覽器之後的 JavaScript，缺少了繪圖引擎，所以要拿來做圖型化使用者介面，會更為困難。慶幸的是，前些日子發展出的 jsdx-toolkit 已經解決了大多數的問題，除了有 3D、動畫等支援，也已經有了許多現代桌面有的UI元件（如：Entry、Label、Button... 等），以致我們完全可以放心的開發屬於自己的圖型化應用程式。 不過，目前的情況，在手機、平板或是特定用途的嵌入式系統中完全夠用，一旦回到更為複雜的桌面環境下，就會遭遇到許多的問題。像是回到 XWindow 底下後，會遇到許多 X11 的視窗管理機制，其視窗之間錯縱複雜的交互關係，就是我們要處理的。尤其是當我們在開發桌面環境時，就會發現在一般的桌面環境下，使用者可能會同時開無數個視窗和程式，並且隨機又大量的切換使用，這迫使我們必須去修改 jsdx-toolkit 以處理 X11 底下的更多狀況，符合並更完整支援一般桌面環境下的操作習慣。 你可能用過 GTK+/Qt 這類常見的 Toolkit，也知道在 X11 之下有很多種類型的視窗（Window），像是 Dialog、Splash、Menu、Popup Menu 等等，但你可能不知道這些現代 Toolkit 內部做了多少事。事實上，X11 本身雖定義了各類視窗的類型，但實際上 XWindow 和 Window Manager 並不會完全去照定義去處理你的視窗行為，更準確的說法是，X11 HWMH 中的基本定義和我們實際的認知是有出入的，該定義只是說希望達成的行為，但沒說是由誰（XWindow、Window Manage 還是 GUI Toolkit）去處理。 舉例來說，我們現在寫一支程式，該程式不使用任何現代的 GUI Toolkit，然後單純使用 X11 API 把一個 Window 的類型設成 Popup Menu。但是你會發現，它的實際行為並不像我...

已經過了近兩年，至今仍然沒有一台 PC 廠商做的平板電腦能勝過 iPad，精緻度估且不論，其速度與流暢度，相較之下只能堪稱工程機的程度。其實真正原因不在於這些廠商行銷廣告中的 CPU 『數量』，而是 Android 系統軟體本身處處存在了一些效能上的問題，重點是這些問題不是工程師所在意的，而且吃力又不一定討好，沒人會拿飯碗去賭。另一方面，Android UI 設計永遠就像工程師自我良好的作品，單獨看每一個元件都很漂亮，可是拼裝起來後感覺就是盤剩菜剩飯，就算換了 UI，也不過只是換了封面罷了，換湯不換藥。 Open Source Project 的開發，最困難的就是修改機制，在很多時候，我們只有能力挖肉，沒能力整骨，畢竟整個 Project 不是我們自己寫的。當然，也因此很多設計是無法加上去的，就算加上去也無法好用。就像現在廠商所提倡的軟硬體垂直整合，雖然我們已經有了硬體與軟體的溝通，但在應用軟體到軟體系統之間，其實更需要有好的垂直整合，否則出現斷層後，就像現在 Android 平板總是說不出的有問題。也難怪有人在罵大多數場商只是把 Open Source Software 隨便放到硬體上就拿出來賣，根本不用心。 我們何不來自己動手寫一個平板系統？ 運用現成的 Open Source Project 為基礎，以 iPad 為學習目標，重新打造一個平板用的作業系統。重要的是，品質要能出貨，又有好的擴充性和可用的底層機制，而不只是用套軟體拉一拉 UI 就完事。 Mandice Flat Project （  http://code.google.com/p/flat ） [ Flat Project ] 就是一個這樣的產物，目標是自己動手打造一個開放的平板環境。（目前已經釋出程式碼的子項目是 GrandPa（視窗管理器），是一個仿 iPad 視窗行為的 3D Window Manager。） Flat 的起源，[ Mandice ] 是這幾年間與不少大大小小廠商合作過案子，已有不少經驗和成果。所以在今年的 [ COSCUP 2011 ] 活動，筆者一時興起，便把過去案子所開發的各種元件抽出來再開發並陸續釋出，這就是 [ Flat Project ] 的由來，當然已經移除不應該公開的商業部份。 後記 順帶一提，今年...

好不容易，Linux 桌面經過十多年的演進，GTK+ 和 GNOME 總算進入了 3.0 的時代，向來最愛仗著『使用者之名』做盡任何事的 Ubuntu，也推出了他們的 Unity 介面，試圖重新打造桌面使用者的習慣。可惜的是，這些新的桌面設計雖然帶來了完全不一樣體驗，卻也造成不少使用者操作思維的混亂；更可怕的，這些標新立異的改變，將原本『好不容易』成熟穩定下來的桌面系統，在短時間內，又再次推向重新建立習慣和軟體崩潰的循環地獄。 網路上一篇討論文章『 Linux的桌面為什麼這麼傻逼 』（這篇文章是有心人翻譯的，內有原文連結），對 Linux 桌面環境有很獨道的見解和體驗，其批判性的強烈言詞，可以感覺到這些年作者的沉痛經歷。 就某方面來說，筆者相當讚同該文的論調，本身就長期使用 Linux 桌面，不時因為各種桌面系統的問題，親自動手去做程式開發或調整，可以說該文道盡筆者心聲。不過最近這一兩年， GNOME 已經可以算是很好用的桌面環境，程式也很穩定，周遭初入 Linux 的朋友們也都可以輕易上手。但高興沒辦法太早， GNOME 3.0 在此時投下了一顆超級炸彈，其更新除了讓許多元件壞東壞西，使用操作和程式開發上完全讓人覺得陌生。 喔不！我不要再經歷一次『桌面環境的黑暗時代』。我只想穩穩定定且不要有意外的使用著我的作業系統，所以我也拒絕 GNOME3 和 Unity。在一切混亂的情況下，Enlightenment（簡稱 E17） 帶來了一線曙光。 我對桌面環境的要求其實不高： 可用性高，穩定度和使用性最好不要與 GNOME 2.0 有太大的差異。 速度快 漂亮又炫麗（最好能夠有 3D 桌面的支援，這讓我覺得我的系統比 Windows 高級） 省系統資源 畫面易客製化（如果能讓我看起來更像個專業 宅男  Hacker更好） 經過一些拼裝和調整後，這是用 Enlightenment + GNOME Component + Thunar File Manager(XFCE) 組裝的桌面環境其最後樣貌： Debian 使用者，可以照下面步驟拼裝出同樣的桌面環境（當然畫面上的元件排版要依各自喜好自行調整）： 去  http://packages.enlightenment.org/  尋找和系統相對應...

若嘗試去讀各個 Window Manager 的程式碼，最大的挫折就是會遭遇其中了龐大數量的專有名詞和屬性，假設沒有對 XWindow 和 Window Manager 整體架構有清楚概念，必定會花不少時間在查詢 X11/Xlib 的官方文件和映證，不過，查證過程雖繁瑣，對瞭解整個實作很有幫助。筆者將在本文記錄幾個比較特別的視窗(window)屬性，以便讀者懂得如何處理一些特殊的 window。 WM_TRANSIENT_FOR 此 Hint 屬性記載著短暫視窗的父視窗的 Window ID，若不是短暫視窗，將回傳沒有父視窗。短暫視窗有與一般視窗不同之特性，其將不會在工作列上被顯示，只是用來做短時間顯示使用，如對話視窗(Dialog Window) 就屬此類。想取得該屬性的設定值，可以藉由此 XGetTransientForHint() 得到： XGetTransientForHint(Display *, Window, Window*) OverrideRedirect 此 Window Attributes 參數表明忽略重新定向，若此參數為真(True)，視窗管理員(Window Manager) 將不會為該視窗畫上標題框和邊框，如選單視窗(Menu Window)就屬此種會忽略重新定向的視窗。我們可以透過 XGetWindowAttributes() 去取得該屬性，簡單的範例如下： XWindowAttributes attr; XGetWindowAttributes(display, win, &attr); if (attr.overrideRedirect) .... else .... 暫且撇開一般 X Application 開發者熟知的視窗形態(Type)，如：Dock 、Desktop、Toolbar 等等，Window Manager 在畫視窗時，首先要處理的是 WM_TRANSIENT_FOR 和 overrideRedirect 這類的屬性，而視窗形態應該是考量於 Window Manager 自身的應用後，才有不同的設計和呈現。

在 Linux 等 Unix's like 的系統上，擁有數十載歷史的 X11 通常為主流的圖形介面支援方案，雖架構看似老舊，卻在世界上眾高手的努力下，成就了現在的各種極絢麗的桌面環境，而最為眾人所知的，便是 Compiz 這類『視窗管理器(Window Manager)』，其運用 3D 技術帶來震憾的桌面體驗，因此在目前主流的 Linux 發行版中，無一不預設搭載。而許多人在此時，才真正了解 Window Manager 的厲害和重要性，新興的系統中，無論是 Moblin 還是 Google Chrome OS，也都特地為自家系統打造專屬的 Window Manager。 然而，Window Manager 實作細節雖看起來複雜，但實際上沒有想像中這麼艱澀，單純透過 X Protocol 和 API 去控制 window 的行為，這類工作極為簡單，而真正令人感到棘手的，是在事件(event)處理和 ICCCM/EWMH 的部份。ICCCM/EWMH 現在是由 [ FreeDesktop.org ] 所維護，其定義了一系列的屬性，用來記錄視窗環境的狀態，並可供所有 X Client 存取，而 Window Manager 要做的就是成為一個常註程式(Daemon)，並隨時去提供和更新這些狀態。不過由於 ICCCM/EWMH 這部份細節繁雜，暫不在本文討論範疇（有興趣可自行參閱 FreeDesktop.org EWMH Spec ），我們主要是討論如何監聽畫面上視窗的 event。 一般 window 監聽自己的 XEvent 是家常便飯，只要有以 Xlib 寫過純 X Application 的人應該都多少有些了解，會比較不瞭解的部份，就是該如何去監聽整個 screen 上的 event，但在這之前，我們有必要先大致瞭解 X window 的架構。通常在 X 上所呈現的桌面環境，是一層層 window 疊起來而成，舉例來說，桌面上常見的工具列(Panel)，上面的狀態 Icon ，如：網路管理、Pidgin Icon 等，都是一個個 window 放在 Panel 的 window 之上，而在 Panel 之後，到最底層便是 screen 的 Root Window，Root Window 在所有 window 之下。 所以，若要做到監聽整個 s...