Aspect ratio

最近搞得比較清楚的是 aspect ratio, 幾個相關名詞理解如下：

• Fill, Zoom: 會把 video stream 擴展至填滿全螢幕，會失去原比例
  
• Letter box: 按比例，16:9 stream 調整至的符合 4:3 螢幕的寬，因此會出現上下黑矩形，與此相反的是 Pillar boxing，將 4:3 stream 調整至符合 16:9 的高
  
• Pan & Scan: 會把畫面調整至「較重要」的部份，不調整比例，也就是不放大或縮小，而是調整輸出畫面的位置於畫面較重要的部份，有時簡單實作的話會跟「Center cut」相同。與此相反的叫 tilt and scan。
  
• Center Cut:簡單的將 16:9 stream 調整高度至符合 4:3 螢幕，並將畫面置中，以致於將左右切掉。
  

還有其他很多種名詞，等有進一步了解再來註記

GeeXboX 與 X geexbox-xorg howto

GeeXboX 有個 Xorg 的分支，主要是用來支援 HDTV 的，wiki 上沒說明，這邊先補充。底下請照做，看不懂就留言發問：

• hg clone http://hg.geexbox.org/geexbox-xorg geexbox-xorg
  
• cd geexbox-xorg
  
• make
  

將來若想同步 source code, 請下

• cd geexbox-xorg
  
• hg pull
  
• hg update
  

上面後兩個命令可以合併成 hg pull -u -v。至於 hg 是哪個套件？是 mercurial，請自行至 GeeXboX 的 wiki 上查。

另外，也可以直接下載 20070519 發行的 generator 來用。

產品遙控器操作邏輯之我見 remote controller hotkey

有個爭議點是，在設計產品的 GUI 時，假設有個相同的選項畫面有二個方式讓它出現，一個是直接從遙控器按鍵來，也就是所謂的熱鍵, hotkey。另一個是從選單來的，這二個方式有人說應該讓 Hotkey 出現的跟選單出現時，操作方式一致，以前在實作 DVD 產品時就採用這種方式。當時我就提出我的看法，並不被客戶接受，我的看法是：

熱鍵產生的應該視為單獨的選單。也就是它並沒有「上一層」的概念在。

之所以我覺得不應該把兩個不同操作模式所造成的同一畫面看成同一件事，是因為這件事不應該從 RD 的角度來看待。當使用者拿 RD 做的產品來操作的時候會認為：Hotkey 按出來的畫面，它是沒有上一層的，因此會習慣於「回上一層」消失。而由 Menu 按出來的，在操作的感覺上會傾向於在操作的預期上「回上一層」就應該回到它來的地方，也就是它的上一層 menu....

也就是說，我的論點是這樣的議題起因於二類不同的操作習慣而產生的，有些人習慣用遙控器的 hotkey, 這些人或許是年輕一族，會期待他要的功能愈快出現愈好，甚至於要求「One click」；另一些人根本就懶得看遙控器，它只希望所有功能都在 Menu 上找得到，而對這類人的設計就是選單的層數要愈少愈好，功能愈齊全愈好。

我的意思是，按 Hotkey 與按 menu 原本就是針對不同的習慣設計的，所以要看成兩個不同的「東西」。不能以 RD 或測試者的眼光來看這件事。

另一個狀況是當使用者按 Menu 進入到 Hotkey 也有的畫面時，若它在該畫面又按一次該畫面所屬的 Hotkey, 在我看來應該畫面沒變，但是效果相當於使用者按 Hotkey 進入該畫面，也就是此時應該以 Hotkey 的效果來處理。

照片如何鏤空 using Gimp to alpha blend

要怎樣把圖檔的某部份鏤空？所謂的鏤空通常是為了在做 OSD 顯示或者在美工圖層加疊的時候有空。

通常我們會用繪圖軟體把圖先畫好，然後以 gimp 編輯，把要鏤空的部份圈起來按 Ctrl-X(剪掉)即可。

另外鏤空跟圖形格式有關，一般建議存成 .png 格式，或者以編輯軟體預設的格式來存也不錯。 請注意 BMP, JPG 似乎都不支援鏤空。

一對多 client and server design

有朋友在問要怎麼寫 client/server 架構的程式。

其實這是基本功夫，參考資料與書目一堆我就不多此一舉再寫，底下稍微描述一下作法。大抵可以分成兩段來寫，一段是彼此建立信任機制，一段是控制。

建立信任機制可以參考 UPnP 的作法，可以讓你達到免設定，但是這邊講的信任機制您還得再加以思考一下，怎麼確認是受信者而非駭客？這牽涉眾多，UPnP 也有類似的機制。對 UPnP 請參考前面關於 GeeXboX 或 ushare,djmount 的文章。

一旦你收集了彼此的資訊，那就可以省略設定步驟，否則這一步也可以是提供設定畫面。第二段就是控制，所謂控制就要彼此都有共通的語言，也就是要先建立通訊協定，我建議較簡單的是透過 HTTP 的方式。例如你可以用 busybox 來架設 web server, 或是編進 lighttpd 進行加密通訊。其實若你已經會寫 TCP/IP 的程式，要寫 client/server 的話就容易了，這一段是可以自己寫，而我之所以建議採 HTTP 的方式也只是利用人家定義好的協定而已，本質上跟自己寫通訊協定是一樣的。若採用 http 的話就容易多了，不止已有現成的，連 source code 都有，而且 client/server 端都有很多參考資料。有了通訊協定(就算是自己寫程式也要先有它)之後，再在這層通訊協定上建立專屬的控制命令與傳回值，也就是所謂的協調方式，這一點若是用 HTTP 的話，可以想成是在寫 CGI 即可。

diff 與 patch

使用 diff 來產生新舊兩個 source tree(source code directory tree) 的差異性列表有助於比較前後的差異(修改、增減)，另外還可以提供較精簡的源碼更新，後者就需要 patch 這支工具配合。

我習慣用下面的命令來產生 diff 檔:
diff -ruN DirA DirB > xx.diff

上述產生的 xx.diff 若是由其他人拿到要更新(同步)源碼的話, 只需要切換到產生 diff 的同目錄(可以看到 DirA 的那一層)再下: patch -p0 < xx.diff 即可。或者像我的話比較喜歡切換到 DirA 目錄下 patch -p1 < ../xx.diff 這樣較不會有混淆的狀況。

至於 diff 與 patch 的選項請自行參考說明文件。若是在 M$ OS 下，建議安裝 cygwin，它可以說是讓你在 M$ OS 下具有眾多 Linux 工具的最佳解決方案。

Google desktop

其實這東西我知道非常非常久了，可是一直沒在用，其原因是我根本很少用 M$ OS, 剛好它只支援 M$ OS。最近開發專案需要讓我長時間停留在 M$-OS 上，用了一下感覺非常棒，找資料超快的。

第一次用可能會覺得怎麼這麼久還沒建好索引，事實上建索引本來就需要大量 CPU, 而 Google 為了不造成系統太大負擔，因此降低 CPU 使用率，也就是讓你覺得系統不怎麼受影響，這樣的結果就是建索引的時間會拉長。總之，等建好索引之後你要找資料就非常快了，也就是你可以感受到一件 google 一直在宣傳的事：你不必再管資料怎麼分類。因為，不管放在哪，它在哪是你「立刻」可以找到的。

另外，google desktop 還有很多小工具，請自己玩玩看，寫這篇也只是希望還不知道的朋友可以有機會試試。我一直是 google 迷，另外說一下，gmail 已開放公開申請，若還沒有用 gmail 的人，我真的強烈建議您去申請。

若對 google 提供的軟體有興趣的，可以至 http://pack.google.com 申請。