09/07/27 12:05:56 uitqp3gT
Windows派の俺からしても、LinuxでGUIのラーメンタイマーを作るなんてのは容易いんだよな
仮にgtkmmでダイアログオンリー、3分から5分までのボタン、後は手動での入力用にスピンボタンをひとつ
といったような感じで作ったとしよう、まあデバッグ入れても半日はかかるまい
ラーメンタイマー程度のアプリなら、Windowsだろうが、Linuxだろうがここまでは大差無いんだ
問題はここからだ、バイナリ配布した場合gtkmmのバージョン問題で起動すら出来無いという事が考えられる
なにしろ同じ2.4系列でありながら、2.14でビルドしたJDが2.16で動かないとかざらにあるから
では、ソース配布ならどうだろう？ それでも上記のような問題が発生し、よほど注意深く作らない限り
ビルド時に警告が多々吐き出されたり、そもそも古すぎてビルドすらままならない可能性だってある
更に言えば、ラーメンタイマーと言うくらいだから、時間になったら当然ユーザに対し知らせなければならない
仮に音を鳴らすとしてビープ音で良いだろうか？ いやいや、Wave音位は流したいと考えるのが普通だろう
ここでまた問題が発生する、ディストリによって対応がまちまちだからだ
つまり、一方はALSAのみ、一方はOSSもエミュレートで対応、一方はpulseaudio経由でよろ、一方は何でもgstreamer直投げ
といった具合に事実上の標準と言うものが無い
まあこの場合、ガワがgtkmmなんだからgstreamer直投げで問題ないだろうとは思うがね
gstreamer直投げならコーデックが対応してれば、MP3でも、AACでも何でも行けるし
でも世の中にはPhononからxine派とか、未だにesound、arts派ってのも居るからね
たかがGUIのラーメンタイマーでこの有様
しかももし、これをサポートして行こうと考えたら、gtkmmのバージョンが上がる毎にビルドが通るかチェックして
ビルドが通らなければ通るようにしなければならないんだ、例えラーメンタイマーに何ら機能を増やして居なかったとしても
そしてそれをgtkmmだけではなく、gtkmmが依存しているGTK+やglibc、そして当然gccについても面倒見なきゃならない
それには当然複数バージョンのautoconf/automakeをはじめとしたビルドツールも同じように管理する必要が出てくるだろう
これがLinuxの現実