昨天講到 4 月 15 日下午，系統匣做到一半整組 revert。

隔天晚上 6 點 56 分，我換了一條路：寫一個 Godot 的 C++ 原生擴充（GDExtension）。

commit 是 e3221f9，1439 行。裡面包含 .gitmodules、SConstruct 建置腳本、編出來的 dll，還有 C++ 原始碼。原始碼本身是 685 行：

hide_taskbar.cpp           150
hide_taskbar_windows.cpp   368
register_types.cpp          55
hide_taskbar.h              91
register_types.h            21

這個外掛叫 hide_taskbar，功能只有一個：讓視窗不要出現在 Windows 工作列上，改成放在系統匣（右下角那排小圖示）。

為什麼需要它

Godot 網路上察看是有提供「把視窗從工作列隱藏」的 方法，但是跟著二三種設定做了之後發現一直沒辦法成功。

為了達成目標，詢問 AI 後決定改走 Win32 API：
改視窗的 extended style、加上 WS_EX_TOOLWINDOW，順便還要自己處理系統匣圖示的建立、右鍵選單、訊息迴圈。

這個決定的影響

從 commit 看得出後續的維護成本：

04-16 18:56  外掛首次進 repo（e3221f9）
04-16 18:56  補一份除錯文件（05f2dc8）
04-20 19:19  刪掉沒用到的 debug dll（f2fa7d7）
04-21 11:33  加 godot-cpp submodule（8700849）
04-21 14:32  rebuild dll（73d9cca）
04-22 20:50  用這個外掛把子視窗也從工作列藏起來（6061088）
04-22 21:00  remove old version files（3eb66df）

4 月 21 日那天我只 commit 了 4 次，時間跨度 3 小時，內容幾乎都是在處理 dll 和 submodule。

Godot 的 C++ 擴充要編譯，要對應正確的 godot-cpp 版本，debug 和 release 要各編一份，換電腦或換 Godot 版本要重編。我還一度把編出來的 dll commit 進 git（debug + release 都有），後來又刪掉。

一個自用工具，需要這個嗎

我在 4 月 10 日的規劃文件裡寫得很清楚：「先做出自己會天天用的番茄鐘工具、預設 UI、不含美術素材、純功能導向」。

一個純功能導向的自用工具，工作列上有沒有圖示，完全不影響我眨眼。

但如果它要上架 Steam，那就不一樣了。桌面小工具就該像個小工具，而不是一個佔著工作列的應用程式。
這個決定是從「我覺得應該就要這樣」想要作品完美的心態長出來的。

第四版遇到同一件事的時候

Pomofocus 也有系統匣、也有「把主視窗收起來」的需求。交接文件裡是這樣寫的：

⚠️ 已知限制：Godot 不允許隱藏主視窗，「縮匣/迷你」時主視窗改用最小化（工作列仍留圖示，引擎限制）；

一句話，接受限制，繼續往下做。

而且我現在每天在用它，雖然覺得工具列一直存在很討厭，但它沒有妨礙過我休息。

帶走這個：撞到工具限制時，先問三個問題再決定繞不繞

AI 也許會告訴你「plan B」，但不會主動問你需不需要，所以遇到撞牆時，先想想：

1. 這個限制擋住的是我的需求，還是我想像中「產品該有的樣子」？（工作列有沒有圖示，不影響我眨眼）
2. 繞過去之後，需要付出的成本（我：要裝編譯環境、管 submodule、每次換版本重編 dll）
3. 如果直接接受這個限制，最糟會怎樣？（工作列多一個圖示。）

三題答完，如果答案是「接受」。

之後要做一件事：把它寫成「已知限制」放進文件，像第四版那樣寫清楚是引擎的限制、目前的替代行為是什麼。這樣下次你或 AI 再碰到，不會又從頭研究一遍，也不會有人把它當成 bug 重修。

明天講另一個同款的東西：一個為了好看而做的自動變色功能，怎麼變成這個專案後期的主要維護對象，以及 Sproutimer 是怎麼停下來的。