確認済みの問題点や、それを解決しない言い訳、思いついたけどやる気の無いこと等。
書き足ししたりしてるので、文体に統一感がありませんが気にしないでください。


--展望--
これといってありません。
思いついたことや気付いたことをToDoListに書き、
優先度を付け、ソートし、気が向いたときにやる、という感じです。

--メモリ使用量--
多い。
Migemo使ってると50MBぐらい使うことになる。
シェル関数とGCの仕様が原因のほとんどだと思ってます。
ページングファイル使ってると使用感悪そうだとは思うが、それはWindows自体の問題という気もする。
自分の環境はメモリ2GBでページングファイルOFFなのでメモリ使用量が使用感に繋がることは無いです。

--見た目--
とりあえずフレームの描画のみ設定可能にして様子を見る、と決定してから数年が経過しています。
描画だけでなくウインドウの形やマルチスレッド等も考慮しなければならず、
やるとなると、ちょっとしたフレームワークのようなものを作り上げることになります。
そもそも、やったところで、動作が遅くなることはあっても、効率化することはまず無く、
なかなか、ToDoListを細分化することすら、やってみようかと思えません。
とりあえず少しだけでもやってみるのがいいとは思うんですが。
Winampのスキンアーカイブをそのまま使うとかすればいいかと思ったり。

--初期化処理(起動と設定適用)が遅い--
常駐ソフトの起動の数秒なんてどうでもいいが、
設定可能部分が多いのに設定適用が遅いのはいろいろ試す時に困る。
自分の環境で、起動にかかる1.57秒のうち、起動スクリプト(.giraffeとsiteinit.giraffe)の実行に1.43秒かかってる。
spirit部分が0.68秒、これ以上速くってのは、機能(互換性含む)を削らないとまず無理。
expr生成が、0.28秒(細かくタイマー設置したのでそのオーバーヘッドがかなりある)。
パース部分を合計したら1秒として、2/3にあたる。
評価(実行)部分が残りとして、特別どこが遅いということも多分無い。
結局パース、特にspirit部分が遅いってことになる。
バイトコンパイルでもしない限りどうしようもない。
deprecated.giraffe等をC++で実装するのも有効だろう。
普段やってる登録アイテム全キャッシュを有効にしたら起動に3秒かかったから、
そうする限りどんなに高速化しても1.5秒以上かかって結局遅いと感じることには変わりないか。

--起動時に実行されるスクリプト--
.giraffeを実行した後に、siteinit.giraffeがあれば実行する、ということになってます。
慣習と逆です。よくないです。
経緯を説明すると、初めに.giraffeだけを起動時のスクリプトとしてて、
デフォルトで起動時に実行されるスクリプトをデフォルトの.giraffeに書いていった結果、
デフォルトの.giraffeが複雑化して、ユーザが編集すべきものではなくなってしまい、
あってもなくてもいい起動時のスクリプトが必要になり、siteinitが採用されました。
マルチユーザに対応したくなったら、そのときに変更します。
たぶん、今の.giraffeがinit.giraffeにでもなります。
起動順は、まずそのinit.giraffe、次にsiteinit.giraffe、
そしてマルチユーザを意識したディレクトリリストから.giraffeを探して実行、ということになるでしょう。
本当にマルチユーザに対応するとなると、init.giraffeに呼ばれるsettings.giraffeがマルチユーザモードかどうかの決定後に実行されないといけませんから、
.giraffeが呼ばれる以前に、siteinit.giraffeがマルチユーザに対応した呼ばれ方をすることになります。
siteinitをScript2に置いて、Script2をAll Usersディレクトリとして、siteinitが全てのユーザで呼ばれ、
.giraffeがユーザごとに違うものが呼ばれる、なども考えられますが、
マルチユーザ自体がどうもこういうソフトと合わない気もします。

--キー名--
109キーボードの印字を名前として、それをVKに変換してます。
ですから、109じゃないと予期しない結果になります。
104だと、特に記号の辺りがずれるので、この件を知らないと訳のわからないことになります。
キー名と値のマッピングを動的に設定可能にはしてみましたが、Giraffe+から設定するいい方法が思いつきません。
自動でやると不意に設定が変わるし、手動だと面倒だし。
109でも問題はあって、例えばCapsLock単体ではeisuuですが、Shift+CapsLockの場合、s-eisuuではなく、s-capsになるなど、
モディファイアとVKによる設定の無理が生じてる部分があります。
VKでなくSCを使えば、このCapsLockの件はとりあえず解決ですが、
その部分だけSCにするのも無理があります。
どう転んでも気に食わないとなれば、いかに妥協すべきかということになります。
s-capsの件は小さく少ない問題なので気にせず、
キーボードが109で無い場合の方も、文字キー等は同じなんだからまあいいかという感じの、
いい加減な結論になりました。
やらないよりマシそうな対応として、Winuser.hに定義される全てのVK_*NAME*の*NAME*部分を指定可能にしておきました。

--ドキュメント--
ブログに気が向いたときに適当に書いていったら、いつの間にか出来上がってる、
みたいなのを期待してたが、そんなわけには行かないようだ。
そもそも、そういうものを求めるなら、ブログではなくWikiにすべきだったようにも思える。

--リストボックスに変わる新しいGUIオブジェクト--
リストボックスを、それとはまるで違う同じ役割のものと置き換えたいと思ってる。
特にどこがというわけでもないが、漠然と、現状よりいい状態が幾らでもありえる感じが嫌。

--ステータスウインドウ--
常に表示されていて欲しい情報というのがある。
パスにアクセスしたら、エクスプローラのステータスバーにあるのと同じような情報が欲しい。
ステータスウインドウに限らず、入力を受け付けるメインウインドウと、候補を表示するリストボックス以外にも、
いろんなウインドウが衛星のように散らばってるUIにしてみても面白いような気がしてる。
UIはシンプルなほうがいいという気も大いにする。

--設定ダイアログの改善--
Settings/hotkeyやSettings/keyは現状で別にいいかと思うが、
Settings/setupはスクリプトの衝突や実行順や依存関係といったものを扱えないといけない。
これといって思いつく解決方法もない。

--登録アイテムの管理--
ShortcutViewerというショートカットを扱う汎用的なソフトで管理するというスタンスだったが、
スクリプトの登録やディレクトリによる階層化等、
出来ることが増えるにつれて、専用の管理機構が必要な状況になってきた。
でもやる気はない。

--ごみ箱内アイテムのドラッグ--
Giraffe+からごみ箱の中身をドラッグしてエクスプローラにドロップしたら、
ファイル名がITEMIDLISTのものでなく、ファイルパスのものになる。
Shell IDList Arrayだけじゃダメらしい。

--複数ファイルin違うディレクトリのシェルコンテキストメニュー--
シェルコンテキストメニューで違うディレクトリにある複数ファイルを選択することができない。
検索フォルダのところは自前実装だとか。
よくわかんないしやる気もしない。

--フォルダ等のアイコンの変更--
レジストリの設定でフォルダのアイコンを変えててもGiraffe+では普通のアイコンが表示される。
これは他のプログラムも同じなので、アイコンを変えるソフトが設定するレジストリの部分は、
エクスプローラにのみ有効なものなのだと認識している。
でもやっぱり同じにしたい。
なにかの初期化をすればいけるんだろうか。
プロパティのダイアログに表示されるアイコンも違うから、使ってる関数が違うということはないはず。

--ITEMIDLISTのVALIDATION--
ITEMIDLISTの指し示すものが本当に存在してるか確かめるいい手段が無い。
SFGAO_VALIDATEでいけるんだけど、フロッピードライブへのアクセスが発生したりする。
SFGAO_VALIDATE無しだとキャッシュが使われるとかで常に存在するものとなる。
親の中をEnumerateして一致するものがあるか調べるというのもあるが、これは確実な代わりに遅い。
今現在の実装は、フロッピーやCDを避けるために、ドライブは常に存在とし、
その他はSFGAO_VALIDATEを使って判断してる。

--Unicodeの使用--
使える部分と使えない部分がある。
基本的には、ver.0.5以前の部分であるDLLの関数を利用する機能で使えない。
たとえば、Ctrl+RによるリネームはShell.dllのRename関数を使っているため、現状ではUnicodeのファイル名を扱えない。
Ctrl+Rのリネームについては、どうせやるなら根本的に作り変えたい部分なので、そのときまでこのままになりそう。
DLLフォルダの存在自体が「廃れた仕様」なので、その中のDLLを更新することは考えていない。
*追記*
リネームについては、ダイアログを使わない代替版として作ったRenameFile2はUNICODE対応。
登録アイテム追加&編集も、ダイアログを使わない新版はUNICODEに対応してる。
全てのUNICODE対応は完了してるが、それらをデフォルト設定とはしてない。
ダイアログ(というか慣れたUI)じゃないと、いちいち説明しないと使えないだろうから。

--XMLパース出力で日本語が文字化け--
Boost.Spirit付属のtree_to_xmlの仕様。