例えばエロペガは、DirectX9の一部である、DirectShowを使って動画を再生している。
Delphiで動画を再生するための機能をまとめて、部品として公開してる人がいて、
エロペガにその部品を組み込んだ上で、ツマミとかは自分で作って出来上がりって感じだ。
部品、すなわちコンポーネント、略してコンポの単位で作れるのがDelphiの良いところ。
エロペガのツマミはもともと、VSTiを作るために使ったもので、その部品を再利用したもの。
マルチメディア（死語）にはやっぱりツマミがいいなと言うことでエロペガは作られた。
特にボリュームとか、スライダーで微妙に調節しやすかった試しがない。
このように、既存プレイヤーのほとんどの機能に不満なく、一部の機能に不満という場合、
その不満な部分だけを自分で作り、あとは他人の作ったものを再利用出来るのが良い。

例えば真魚の1.00を作り始めたのは、当時使っていたTeraPadにタブが欲しかったから。
それで、TeraPadが部品として使っているTEditorを、真魚も同じく部品として使い、
タブを切り替えて操作する部分とかだけ自分で作ると言うことをやっていたわけだ。
まぁ、後にTEditorに満足できなくなって、2.xxからTEditorをやめて自分で部品から作ったがな。

と、部品単位で何か作って配布する人がいるおかげで、その部分で手を抜くことが出来て助かる。
大してこだわりもない程度の部分については、部品を集めて搭載するだけにし、
こだわりのある部分だけを自作するっていう開発は当然アリなわけだ。
集めてきた部品のライセンスがややこしいとかっていう問題も同時に生まれるけどな。

先日、真魚の内部で使っている、文字コードの自動認識判定や変換を行う部分を、
.NETに移植してVisual BasicやC♯等から使えるDLLを作って公開した。
サンプルとして、このDLLを使って自動判別や変換を行うメモ帳とソースも同梱した。
ということは、このDLLを利用することで、文字コード判定が必要だがメインではないアプリで、
文字コード判定以外の部分だけを自作するよう労力の配分が出来るわけだ。
そりゃもしかしたらテキストエディタかも知れないし、開発環境やHTMLエディタかも知れない。
DLLが嫌なら、ソースが付いてるから組み込んでしまえばいい。
と、自分で文字コードのことを調べて自動判定を作る気がない人に、
無償で使わせようとして置きながら、一つ企みが混じっている。
それは、現在Windowsのテキストエディタで主流である、中途半端なEUC変換の駆逐。
EUC-JPにはあって、S-JISにない文字については、S-JIS主流の時代なら切り捨てて良かった。
しかし、今は切り捨てなくてもユニコードに変換できるんだから、変換すれば良いのだ。
それが、昔ながらのS-JIS主体のライブラリが現在も横行している状態なので、
特にこだわりがない人にはぜひ、切り捨て型のライブラリを使わないで絶滅させて欲しい。
しかしそういった話は難しいので、その企みよりも簡単に使えるという利点を全面に出している。
これは別に、あたしが作ったものである必要はないから、著作権は主張しないつもりで、
このやり方が広まって欲しいだけなので、無断でパクリも大歓迎だ。
ただひたすら、悪いものを早く駆逐したいだけなのだ。
あたし自身も、調べるまでEUCにそんな事情があるとは知らなかったわけで、
知ってしまったからには、旧来のやり方の問題点は解決するよう動いて当然だ。

真魚のエンジンであるTNotePadも同じような理由で、当初は部品のみの公開を行った。
ユニコードの文書をS-JISにコンバートして開く、危険なテキストエディタの駆逐を狙った。
情報が失われるとしつこく書いてきたわけだが、ここは見てる人もいないので効果はいまいち。
わからずに使ってる素人さんはしょうがないとして、
素人でないはずなのに新しくS-JISでテキストエディタを作る人が後を絶たないのは困った事だ。
表示できないだけで情報は失われていないかのように、ウソの説明している人とか憎たらしい。
真魚の全ソースを公開してからも、TNotePad部分だけを切り離して部品で使えるようにし、
よそのDelphi系作者にもユニコード化の手法が伝わるよう、安全なテキストエディタが作れるよう、
アピールはしてきたつもりだが、誰にも伝わらず次から次へとS-JISで作る人が出てくる。
きっと、たとえ危険と知っていても、簡単にテキストエディタを作れる方法を選んでしまうんだ。
たとえいらない機能でも、簡単に実装できるなら無駄に実装する傾向からも伺える。
必要だから作るのが本来の姿なのに、作れることが面白くて作ってしまうんだよな。
TEditorを使えば、素人でも立派なテキストエディタが作れるから、面白くて作ってしまう。
誰かが既に作った古い文字コード変換を安易に組み込んで、面白くて作ってしまう。
これもしょうがないことなのだろう。
内部データをユニコードで扱う、TEditorくらい簡単な部品が出れば良かったのだが、
TNotePadは、TEditorのように簡単に使ったりできることより実用性を選択した。

さて、こうなったらもう、TNotePadを部品化することすらやめて良い気がしているのだ。
これを部品としてまとめることで、どうしても部品と本体の連絡がボトルネックになる。
もう分離可能にしようと言う縛りを無くしちゃって、効率化したいと考えている。
ググってみても誰も利用はしてないようだし、特に問題はないだろう。