為了方便以後追蹤，獨立出一篇來討論。

先前的討論在 這裡

說明： 

Swing Windows Script for Linux 是為貝兹訓練法的「怡動」(movement) 原則所寫，可讓指定的視窗維持運動，避免眼睛呆視，希望對電腦使用者的眼睛健康有所幫助。 

需求:

    bash awk wmctrl bc x11-utils

Changelog for Ver 0.3：

• 可自訂撞牆的深度 (但對上方、左方無效，可能是 wmctrl 的 bug 或限制)
• 除了上下左右，現在可以右上、左上、左下、右下斜線運動
• 可自訂斜線運動的距離 

效率的問題無解，我只會一點 shellscript Orz

看看有無善心人士可以寫程式直接用 X window 的 lib 控制 

Changelog for 0.4:

• 內建多種移動方式，執行方式改為

/PATH_TO/swing-windows.sh {hori|vert|star|triangle-cw|triangle-ccw|square-cw|square-ccw|diamond-cw|diamond-ccw|octagon-cw|octagon-ccw}.

• 改善一點點效能，但現在如果執行 swing-windows 時移動視窗，會在新位置與舊位置跳動，必需按住滑鼠等一下。

以下算是對於該script小小的建議，不過因為小弟程式也不太行，所以也只能提供意見，看看有沒有那位能人志士可以幫忙改進。再加上之前有用過Windows版的移動視窗，所以有點比較的基礎：

1. Windows版的移動視窗主要是有一個中心作為移動(或者該形容為轉動)的依據。小試了一下square-cw的參數，我桌面上的terminal好像越跑越下面，一直到桌面的下邊界卡住。
2. 該腳本要預選要移動的視窗。在windows的版本裡，當使用者切換視窗時，程式自動選擇移動該active的視窗。
3. 如同在第2點提到的windows版的該特點，該腳本似乎只能選定一個視窗移動，而無法一開始選擇多個或是全部，然後只讓active的移動就好了。
4. 在windows版內可以設定滑鼠是否跟著移動 (這個功能在操作視窗軟體的時候還蠻好用的，就不用一直開關軟體)
5. 該腳本的移動似乎不是很順？有點拖的感覺。可能是我沒有設定好的原因？
6. 另外，算是最大的bug吧。不過又好像目前無解。就是在桌面邊界會卡住的問題。一般如果開terminal或是editor時，對我還ok。因為我不會將視窗放到最大。但如果是看pdf或是browser時，會習慣將視窗放到最大以利閱讀，可是這個時候視窗就會受到桌面邊界的影響而卡在那邊，等同幾乎變相的無用化，這我覺得倒是有點可惜，因為畢竟個人我現在花相當多的時間在用browser以及看pdf文件，算是影響視力最大的因素吧。

雖然我沒有實際測試過Linux上的這個script, 這位訪客的意見也是忠實反應了個人的意見,

但我有一點點不同的意見僅供參考: 可能不能只有依照swing window 軟體的特色去思考這個Script.

而是要思考一下為什麼要Swing window?

主要是眼睛不要呆視/凝視即可, 所以我覺得不要完全依照既有的軟體去思考比較好.

其實視窗最大化, 有可能表示還是會有散視的習慣, 另外, 視窗最大化在Win的swing windows也會不動啊? (我的是Vista).

如果要完全跟Swing window一樣, 那就有點累了 :p

由於一直保持眨眼/匯視的習慣, 有時候忘記開swing window也還好 :-) (我看browser/電腦螢幕, 每天大概是12小時左右.)

不是吐嘈訪客你喔, 不要生氣, 請見諒 :p

第一點，square-cw 不應該有你說的狀況，請問你測試是在那一套桌面環境？

第二點不難，只不過若想寫到目前的 script 中，會比較複雜一點，有此需求的話，也許下次另外寫一個 script。

第三點，選擇多個，沒想過這個問題， 再想想。

第四點，不曉得有什麼工具可以控制滑鼠的？目前應該做不到。而且目前的 script 效率不好，如果再加上滑鼠也要動，可能效能會更差 ……

第五點，DELAY_HORI 與 DELAY_VERT 還有 DELAY_SLASH 都可以自訂，小數點也 OK。DISTANCE_HORI、DISTANCE_VERT 與 DISTANCE_SLASH 也有關係。

第六點，在我的 Window Manager，即使最大化也不會卡住，視窗還是可以往右、往下移動。唯一有問題的是，如果視窗有部分在螢幕外，超出某個範圍後，會卡住，記得我上次測試時，覺得這應該是 wmctrl 的 bug，我的 script 無能為力。

xdotool 可以。另外也有一些零碎小工具可以，或是自己寫。

不同 WM 對 EWMH 支援度/bug 都不同，所以行為不同是正常的。

謝謝，看起來 xdotool 還不錯。

知道 script 那裡出問題了，決定位置時，不論 wmctrl 或 xwininfo 都會以窗框內的左上角決定 (X, Y)，但使用 wmctrl 移動視窗時，會依窗框外左上角決定位置，所以位置 X 差了窗框厚度， Y 差了標題列的高度。我使用上沒有遇到問題，是因為我用的 Window Manager 有點特別 - awesome window manager，沒有標題列，窗框也很薄。還有，決定螢幕解析度的欄位，不同 Window Manager 輸出不同，原本我是抓 wmctrl -d 的 DG (desktop geometry) 欄位，icewm 不會輸出此欄位，只會輸出 WM (work area)。

所以目前我釋出的 script，可能只適用於 awesome window manager 這類視窗管理員。

要通吃好像有點難。

Ver 0.45 Changelog:

• 修正不同 Window Manager 所導致的跳動問題
• 改為直接搖動 active window，不再提供視窗清單
• 需要 xdotool 

重要說明： 

從 0.45 版開始，第一次執行時，必需算出視窗標題列高度、視窗邊框寬度。

./swing-windows.sh init

得到 BD_W 與 TB_H 兩個值，將兩個值取代 swing-windows.sh 開頭預設的 -1。

以後即可正常使用。如果更換佈景主題或 Window Manager，最好重新執行一次。

現在回好像太晚了點，因為好像又有新版出來了。不過還是提一下好了，我用的是肥大的gnome。 剛又微調了一下數值，移動是有比較順，但仍有向下跳動的情況發生。

無法重現，在我的 gnome 還蠻正常的。可以告訴我你的 BD_W 與 TB_H 的值是多少嗎？

忘了強調一點，在做 swing-windows.sh init 時，要選有「正常」視窗外觀的視窗，不要選到桌面(root window)或 gcb 這種特殊視窗。

最好選你常用來閱讀的程式，如瀏覽器、terminal emulator、或 pdf reader 來算。

如果還是有問題，請附上 sh -x ./swing-windows.sh square-cw 的一段執行結果，我看看能不能找出問題在哪。

剛試了一下，設定值為BD_W=4, TB_H=24，結果順利無誤；之前的設定是BD_W=4, TB_H=0。不過有趣的一點是，當設定值為BD_W=4, TB_H=24時，我用滑鼠游標點桌面時，桌面居然慢慢的往上跑了   我居然眼睜睜的看著我桌面上的icon沒入頂端確無能為力

以下是sh -x 後的結果：

+ which wmctrl
+ WMCTRL=/usr/bin/wmctrl
+ which xdotool
+ XDOTOOL=/usr/bin/xdotool
+ BD_W=4
+ TB_H=24
+ DISTANCE_HORI=6
+ DISTANCE_VERT=10
+ DISTANCE_SLASH=6
+ DELAY_HORI=0.05
+ DELAY_VERT=0.05
+ DELAY_SLASH=0.05
+ PAUSE=1
+ wmctrl -d
+ awk /\*/{ print $9}
+ RESOLUTION=2560x974
+ echo 2560x974
+ awk -F x { print $1 }
+ SCR_W=2560
+ echo 2560x974
+ awk -F x { print $2 }
+ SCR_H=974
+ DEP_X=24
+ DEP_Y=24
./swing-windows.sh: 73: Syntax error: "do" unexpected (expecting "}")

目前應該沒有使用到這個 function，應該沒關係。

桌面會動的問題

可能以後加入黑名單或白名單的功能

0.47 changelog

• 加入白名單功能，從此版開始，只有在白名單中的程式，才會搖動，請在 script 開頭自訂 WST 這個變數，目前預設已加入 firefox-bin、acroread、x-www-browser、google-chrome，加入執行程式的名稱即可，不需路徑。
• 改善 active window 偵測的可靠度 (還是有遇到一些錯誤，尚未抓出原因) 

特別提醒：

在作 ./swing-windows.sh init 時，請選擇你希望它會搖動的視窗來偵測，譬如：瀏覽器、PDF Reader，不要選擇桌面、面版等一些特殊視窗。 還有，選擇的視窗，請不要放太大、儘量與螢幕邊界(或面版、taskbar)保持至少 100 pixels 的距離，這是因為在偵測 TB_H 與 BD_W 時，會稍微移動視窗，如果碰到邊界，有些 Window Manager 會讓視窗維持在螢幕內，導致偵測不準確。

PS. 能不能幫我看看第 17、69、70 行的寫法？69、70 這種寫法好像有點土法鍊鋼。  Orz