GNU archのnaming conventions、初めて見たときは何故あんな名前にするのかさっぱり分からなかったのですが、実際に使ってみたところ、これは熟慮の上に決定されていることが分かりました。要点は上記のページに書かれている通りなのですが、やはり使ってみないと実感できませんね。
でも実際にはarchは使ってません。他のプロジェクトで作業するときに、試しにあの慣例を使っただけです。archは無闇に長いリポジトリ関連の名前のせいで事実上使用不能ですから……
(本当はGNU makeのpattern rulesを書くときにちょっと引っかかった点があったので、それについて書こうと思っていたのですが、この記事を書くためにマニュアルを見直していたら解決できそうな感じになってきました。よって保留)
「ネタ: TrayIcon Shuffle」の続き。タスクバーもウィンドウの一種であることには違いない。という訳でまずは手始めにウィンドウクラス等を調べてみた (正確には昔調べたときのメモが残ってた)。調査対象はWindows XP。結果は次の通り (クラス名等にはオーナーウィンドウのものもコロン(:)で区切って前置している)。
タスクバー ========== CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd TITLE: C:\WINDOWS\Explorer.EXE: 通知領域 (トレイ) ================= CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd:TrayNotifyWnd TITLE: C:\WINDOWS\Explorer.EXE:: CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd:TrayNotifyWnd:SysPager:ToolbarWindow32 TITLE: C:\WINDOWS\Explorer.EXE::::通知領域 CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd:TrayNotifyWnd:TrayClockWClass TITLE: C:\WINDOWS\Explorer.EXE:::22:54 アプリケーションの一覧 ====================== CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd:ReBarWindow32 TITLE: C:\WINDOWS\Explorer.EXE:: CLASS: C:\WINDOWS\Explorer.EXE:Shell_TrayWnd:ReBarWindow32:MSTaskSwWClass:ToolbarWindow32 TITLE: C:\WINDOWS\Explorer.EXE:::実行中のアプリケーション:実行中のアプリケーション デスクトップ ============ CLASS: C:\WINDOWS\Explorer.EXE:Progman:SHELLDLL_DefView:SysListView32 TITLE: C:\WINDOWS\Explorer.EXE:Program Manager::FolderView
ポイントはToolbarWindow32。これはcommctrl.hで定義されているTOOLBARCLASSNAMEの実際の値。で、TOOLBARCLASSNAMEはToolbar controlのクラス名。Toolbarに関してはAPIが揃っているので、情報の取得・変更はできますね。他の部分についても同様のことが言えるでしょう。
これでタスクバーの内容の入れ替えができそうだということは確定。後はインターフェースさえ作れば完了ですね。ドラッグアンドドロップが直感的でいいと思いますけど、単一プロセス内で完結しているならともかく、他プロセスにちょっかいを出さなければならないので面倒だなぁ……
「黒歴史ウェア」という単語を思いついた。主にもう二度と振り返りたくはない自作のソフトウェアを指す……んじゃないかな。何となく思いついただけで特に深い意味はない。
Taskbar Shuffle (via ベイダー日記 - Taskbar Shuffle) というツールを見て思った。トレイのアイコンを入れ替えるTrayIcon Shuffleはどうだろう? ……二番煎じな上に多分既に誰かやってそうな気がする。
それはさておいて、Taskbar Shuffleはどうやってタスクバー上の位置を入れ替えてるんだろう? タスクバーに関する情報を得るのもどうやっているのか気になる。気が向いたときに調べよう。
最近はLuaを色々と弄っています。諸事情によりUnicodeな文字列を扱いたいため、内部での文字列のエンコーディングはUTF-8に固定し、外部との入出力が起きる場合は適宜変換するようにしました。
これ自体は特に難しいことではなかったのですが、ファイル名が関連するAPIを全くチェックしていないことに気付きました。基本的にはファイルを開く箇所で、ファイル名を表す文字列のエンコーディングを適宜変換すればいいだけなのですが、具体的にはどうしましょう?
今までUTF-8化で要修正だったAPIはLua本体とは直接関係のない部分だったため、Lua本体のソースは弄らずに済んでいましたが、今回は修正対象にLuaのAPIも含まれます。でも、できればLua本体のソースを弄りたくはありません。とはいえ、普通に考えたら本体に手を加えるしか方法はない。でも本体は弄りたくないし……(以下ループ)
と暫く悩んでいたのですが、今朝になって解決策を思いつきました。インターポジショニングを使えば……ああ、いや、やっぱ止めた。普通だったら「既存のAPIにラッパーを被せたいのに、既存のAPIを置き換えてどうする」となるところなのですが、今回は回避策があります。でも、インターポジショニング以外の手段がないわけではないし、後々困りそうな気がするので止めておいた方がいいですね。
考え直してみたら、Lua部分は一旦共有ライブラリにまとめてから使っているので、インターポジショニングのしようがなかった。今回は問題になる関数をラッパーにマップさせて回避。
ここ一ヶ月の間、検索エンジンからこのサイトへのアクセスで、三日に二回は検索ワードに「shell」「alternative」「windows」を含むものがあります。以前もときどきあったのですが、せいぜい一週間に一回あるかないかくらいのペースでした。
何でだろうと思い、試しに「alternative shell」でぐぐってみたら凄い結果が出て吹いた。既に一部からは黒歴史化と苛められるのに、Googleにまで苛められるとは。
これはもう開き直って更新するしかないのか……?!
新しいモニターが到着しました。購入したのはFlexScan S1731-SABK。必要な条件を満たすものが他になかったのでこれにしました。値段は五万少々と安いものではなく、購入前は安物で我慢して浮いた分を他に使おうかと思っていたのですが、使用頻度がトップのモニターにケチっても仕方がないと思って購入しました。
早速取り替えてみたのですが、今のところはかなり良い感じに思えます。液晶周りの枠が細いことと黒がちゃんと黒く見えるところが特に良い。少々コントラストがきつい感じがするけれど、その辺は後で適当に調整するかな。それにドット欠け等もありませんでした。
ああ、何かこの調子だとお金で買える幸せに目覚めそうです。次はキーボードとトラックボールかしら……!
センサーで周囲の明るさを感知して自動的に輝度を調整してくれるのですが、これが意外と良い。ただ、ちょっとしたことでセンサー部分に影が入ることでも自動調整が働いてしまうので、モニターの位置が不味いと逆に不便でしょうね。
結論: 10月は忙しかった。11月からはもっと忙しい。