戻る


2013/08/30 16:10

iconvとかいうクソAPIにしてやられた。

iconv_t、マルチスレッド非対応なのな。マルチスレッドで使ったら変になった。

iconvで変換したものをウィンドウのタイトルに設定してたんで、最初ウィンドウのタイトルを設定する関数の方を疑ってしまった。

マルチスレッド時におかしくなるというのはいやだなぁ。原因が分かりにくい。

enumの値の論理和を取るとセグメント例外で落ちるのはなんでだろう。

結局はただの数値なわけだし、そんなんで落ちるんならコンパイル時にエラー出してほしいんだけど。値をintにキャストした上で論理和して、その結果をenumにキャストしたら問題なく通った。わけわかんね。

わけわかんねかったけど、とりあえずこれでリサイズ不可且つ常に最前面なウィンドウとか作れるようになった。よかったよかった。

次は描画やらサイズ変更やら移動やらのタイミングでのイベントハンドラ呼び出し処理を追加するべきか。


2013/08/28 22:10

装飾なしウィンドウとかいらないと思った。

gtk+に、gtk_window_set_decorated()とかいういかにもな感じの関数があったんで使ってみたがウィンドウの装飾が外れない。

ぐぐりまくって、GTK_WINDOW_POPUPとかいうので作ったウィンドウが装飾なしだったんだけど、これどう見てもoverride_redirect=Trueなんだよなぁ。移動できないし、タスクバーに表示されない辺りウィンドウマネージャの管理から外れてる。

結局、audaciousのプレイヤーウィンドウがどうやって枠なしのウィンドウ作ってるのかとか、よく分からんかった。しかしながら、gkrellmも枠なしだけど、こっちは非矩形ウィンドウなので、もしかしたらaudaciousのプレイヤーウィンドウも、四角い形してるだけの非矩形ウィンドウなんじゃないかな、とは思った。

で、正直言ってフルスクリーンじゃない装飾なしウィンドウとか私がお呼びでないのでそんなもんサポートしなくていいかという感想。フルスクリーン用なら問題なく作れるし。

その代わり、そのうち非矩形ウィンドウをサポートするのはいいかもしれない。SDLの新しいバージョンでサポートしていたような気がするし、きっと環境非依存な感じで書けるんだろう。分からんけど。

今日は大体の時間これをやってた。twitterで流れてきたので。

最終的に所要時間0.1秒切れたので満足した。

競技プログラミングとかそういう系は基本的に性に合わないので、多分これっきり。


2013/08/28 19:20

gtk+をいじくる。

リサイズ不可ウィンドウとか、常に最前面なウィンドウとかは作れるようにしたんだけど、タイトルバーやら枠やらの装飾なしウィンドウがどうしても作れぬ。

audaciousのプレイヤーウィンドウは装飾ないんだし、できなくはないはずなんだけど、ぐぐって出てきた情報を元にしてもうまくいかない。

で、audaciousはgtk+を使っているようなので、ならばgtk+を使って簡単なプログラム作った方が仕組みを理解しやすいんじゃ、となった。

audaciousのソースも見たんだけど、いまいちどこで装飾なしにしてるのか分からなかった。

スキンもプラグインとして実装してるっぽいからなぁ。メインのソースにGUIに関する記述が見当たらなかった。プラグインのソースにはあったんだけど、プラグインがどういう仕組みになってるのか知らんし、把握するの大変そうだ。

古いプロジェクトをやってた時にも書いたような気がするんだけど、フルスクリーンは別枠にした方がいい気がしてきた。

装飾なしで、リサイズ不可、常に最前面で、サイズがディスプレイ全体を覆うものをフルスクリーンウィンドウとしようとしてるんだけど、装飾なし、リサイズ不可、常に最前面、というのを、普通のウィンドウを作るのと同じように、3つのフラグを設定して、とかするのはなんか違う気がする。

linuxの場合とか、その3つのフラグの効果を合わせ持ったウィンドウよりも、より適したウィンドウがあるわけだし。そのような特性を持ったウィンドウが生成されることを期待するが、ウィンドウの生成方法は違う方法を取る、みたいな?なんかそんな感じ。

この言いたいこと伝わってない感

あ、セブンスドラゴンたのしい

っていうのを14:30頃に書いて、アップロードすんの忘れてた


2013/08/25 15:50

昨日書いたように作り変えた、っていうのを書こうと思ってたんだけどすっかり忘れてた。

ウィンドウタイトルの設定とかまだしてないのでそれを終わらせたら、次はウィンドウをリサイズ不可にしたりウィンドウの装飾無くしたりとかその辺かな。

最終的にはマウスやらキーボードやらも対応するべきだと思うんだけど、今はまだいいかなという気分。

マウスはまだしも、キーボードはlinuxとwindowsで違いがありすぎてめんどいしなぁ。前に作った時も、後回しにして結局作っていなかったはずだ。

マウスの調子がおかしい。

前に使っていたマウスが、右クリックだったかホイールクリックだったかがおかしくなって、1回押しただけなのに何回も押されたような挙動になってしまったので、一時的にタブレットのマウスを使っているんだけど、もうだめになったらしい。

長いこと使ってなかったのが原因なんだろうか。右クリックの反応が鈍くなっているようで、押したのに押されてないことになったり、離してないのに離したことになってたり。

というのが最近発生していた問題なんだけど、今日それに加えて左クリックもおかしくなってきた。押しても反応しない時がある。

これは新しいマウスを買わなければなるまい。明日辺り探しに行こうかな。


2013/08/24 03:15

とりあえずウィンドウ出した。

しかし、dp::Windowの破棄時にウィンドウが閉じるまで待機という仕様は、やはりびみょうな気がしてきた。

今考えている仕様だと、閉じるボタンを押した時に呼び出されるイベントハンドラでtrueを返すとウィンドウが閉じて破棄され、falseを返すとウィンドウが閉じないという感じにしようとしていて、これを利用して、いわゆる「本当に終了しますか?」みたいなことができるようにしているわけだ。

なので、なんらかの方法で、有無を言わさずウィンドウを閉じて破棄する方法が必要になるわけだけど、それはdp::Windowの破棄でやってしまえばいいんじゃないかな、と思った。

前に作っていたやつだと、閉じるボタンを押した時に呼び出されるイベントハンドラの戻り値がなく、閉じる前になんかできる、というだけだったから、破棄のタイミングで待機でもよかったんだけど。

22日の日記に書いたような、複数のスレッドで待機とかする気は全くないんだけど、待機はstd::condition_variableを使って自前でやる方法でいいかなーと。

ん、閉じるボタンを押した時に呼び出されるイベントハンドラでtrueを返すと、とかもいらん気がしてきた。そのイベントハンドラで待機を終了して、処理が再開し、ウィンドウを破棄されるので、閉じるボタンが押され、イベントハンドラを呼び出した後は、ライブラリ側ではなんもしなくていい気がする。

閉じるボタンを押しても、押したことが通知されるだけで、それ以上のことはやらない感じ。それでいい気がしてきた。

起きたらその辺整えよう。最近なんだか疲れている気がする。夜更かししすぎかしら。


2013/08/23 05:10

ルミネスたのしい

dpの進みはわずか。ルミネスやりすぎた。明日から本気出す。


2013/08/22 04:20

構成考え中。

試しに書いて色々考えた結果、挙動は前の前に作ったライブラリと同じような感じでいいかなと思った。

破棄関数で、ウィンドウが閉じるのを待機する感じ。

破棄関数では強制的にウィンドウを閉じ、待機は別に関数を作った方がいいかなとも思ったんだけど、複数のスレッドで待機できるようになる以上の利点を見出せなかった。

複数のスレッドで待機するとなると、待機しようとする前にオブジェクトが既に破棄されてないかも気にかけないといけないし、そもそも複数のスレッドで待機できるからどうなのだというのもあった。

なので変に変えず、前に作ったのと同じでいいかーと。

生成時の引数は変えることにした。前まではdp::Windowの生成にdp::WindowInfoの参照を渡し、イベントハンドラやウィンドウタイトル、幅、高さなどの情報を全てdp::WindowInfoに入れていたが、dp::WindowInfoはイベントハンドラだけ持たせることにする。

dp::WindowInfoはdp::Window内にそのまま持たせ、後々参照を取得し、変更できるようにするのだが、その時にタイトルやら幅やら高さやらが変更可能になっているとどうにも妙だと感じたからだ。

変更したからといって実際のウィンドウにそれが反映されるわけでもない。なので、その辺のデータはdp::Windowの生成時にdp::WindowInfoの参照とは別に渡す形にすることにした。

今まで、dp::なんたらInfoとかいう、なんとも曖昧な名前な構造体をいくつも作ってしまったが、dp::なんたらEventHandlersの方がしっくりくるかもしれないな。

ウィンドウをリサイズ不可にするとか、装飾を無くすだとか、その辺をどう実装するのかも大体まとまってきた。これなら全部書けるかもしれぬ。


2013/08/20 20:40

リネームおわった。

次はウィンドウ生成に進みたいところだけど、やるのを渋っていた理由にlinux側のAPIが、新しいのが主流になるかもしれん、というのもあったんだった。

waylandかmirか。普通に考えれば前者が主流になりそうな気がするけど、どうなんだろう。

どちらにせよ、X11のAPIでも使えるようにするラッパーをどちらも用意しているようなので、とりあえずはX11ので作っちゃえばいいかなぁ。新しいのを使ってみたい気もするのだけれど、どんななのか知らんし、この環境にうまくインストールできるかも分からんし。

gitのbareリポジトリ便利ね。

今まではbitbucketのリポジトリをクローンしてきて使ってたんだけど、今は別のマシンもあることだし、bareリポジトリをはさむことにした。

bareリポジトリをはさむことで、途中までいじくった状態のを別のマシンからチェックアウトしてその続きの作業をしたりとか、そういうことができるようになった。

今までもできなかったわけではないが、bitbucketの方に変更を送信したりしないと無理そう。中途半端なのは送信したくないしなぁ。

とは言っても、別のマシンで作業する機会なんて滅多にないが。コンセントを使える喫茶店とか近くにあるなら、たまには気分転換で、そこで作業するのも悪くないとは思うのだけど。

今気付いたが、std::unique_ptrのtypedefを統一するのやってなかったわ。やってもやらんでもインターフェース変わらんし、まぁいっかー

次の作業を終えて、pushする時に含めようかな。


2013/08/20 04:20

まだ本調子ではない。

名前の変更、大体の方針が決まった。

昨日書いたdp::Less以外にも、インスタンスの削除をdp::Freeというテンプレートファンクタでまとめることにした。

処理としてはdp::free()という関数を呼び出すだけだが、オーバーロードによりdpの構造体全てに対応できる。

あと、std::shared_ptrの生成をdp::shared()というテンプレート関数でまとめる。

std::shared_ptrのdeleter設定はコンストラクタの第2引数であり、std::unique_ptrのようにテンプレート引数で指定することができない。そこで、各構造体ごとにdp::なんちゃらShared()という関数を用意し、deleterを設定したstd::shared_ptrを生成していた。

今回、deleterをdp::Freeに統一したので、これもテンプレートで1つにまとめられる。

すっきりまとめられて気分がいい。

std::unique_ptrのtypedefも、deleterをdp::Freeに統一した関係でテンプレートを使ってより簡潔にできる。が、それにはC++11で追加されたエイリアステンプレートを使う必要があり、vs2012はそれに対応していない。vs2013で対応するらしいが。クラステンプレートを使えば同じことはできるけど、::typeとか書くのなんか嫌いなんだよなぁ。


2013/08/18 22:00

色々忙しかったでした。

関数やらファンクタやらの名前を修正している。

今まで、キーデータの比較にdp::なんたらLessというファンクタを用意しておいて、それを使うことでstd::unique_ptrやらstd::shared_ptrやらでラップしたキーデータをstd::setにつっこんだりできるようにしてたんだけど、改めて見てみたら処理自体はどれも同じなわけで、dp::Lessという1つのファンクタにまとめることにした。

テンプレートと関数のオーバーロードとうまく利用して、コードを簡略化できたので気分がいい。

というのを16日辺りにやったと思うんだけど、それから今日まで色々忙しかったり疲れちゃったりしてて日記書くのおっくうになってたり、作業もできてなかったり。

今日作業するのもなかなかつらい。明日から本気出すべきか。

疲れすぎたらしく、食べ物の味もよく分からん。何食っても飲んでも味がしない。

別のマシンにGUI環境入れて、uimを使った日本語入力とかもできるようにした。

chromiumのビルドが失敗する。エラーメッセージを見る限り、コンパイルエラーとかではないようなのだが。ぐぬぬ


2013/08/15 00:05

linux側のディスプレイ管理できた。

この次はウィンドウ生成に進む予定だけど、昨日書いた通り、関数名変更を先にやってしまおう。

1日に1回は日記を増やそうということで、最近は続けている。今日で途切れると3日坊主ってやつだ。

って、ああ、日付変わっちゃってる。

別のマシンには大体必要なものを入れた。GUI環境以外については、あとはvalgrindくらいか。今glibcをsplitdebugにして再ビルドしている。

そういえば音関係入れてないな。pulseaudioを入れておくべきか。


2013/08/13 18:50

別のマシンにgentooをインストールしながら作業。

ちょっと外出する時とかでも、外で作業できたらいいなぁとか考えて小さいマシンを使えるようにしているんだけど、バッテリーどのくらいもつかなぁ。

CPUのクロック周波数を落として省電力化、とか多分できると思うんだけどどうやるんだろう。やったことがないから調べてみないと。

指紋認証機能が付いてるので、それも使えるようにしたいところではあるが、vaioだしなぁ。モジュールあるかしら。

今はgcc4.8.1をemergeしている。どのくらいかかるかなぁ。10時間はかかる気がする。

関数名、もっと単純にしてもいいかもしれないなぁ。

例えばゲームパッド関係だと、dp::gamePadGetButtons()という関数を使うとゲームパッドのボタン数を取得できるが、dp::getButtons()でいいかなぁとか。

別の機能で関数名が被ることがあるだろうけど、大体のものは第1引数に処理対象の構造体の参照を渡すわけで、それにより呼び出すべき関数が確定するはずだ。オーバーロードを活用する感じ。

関数と構造体から成り、例外を投げない、Cっぽいライブラリにするといっても、Cに対応する気は全くないわけだし。万が一Cに対応する場合でも、ラッピングした関数を作ればいいだけだし。

ディスプレイ関係の実装が済んだら変えてみようかな。


2013/08/12 16:50

ディスプレイ管理を進めている。

前のプロジェクトから構成を少し変更している。dp::DisplayManagerに依存させなくてもいい機能を取り外して独立させたりなど。

ディスプレイの接続・切断検出機能については完了している。

現在はディスプレイの解像度や配置などの情報取得処理を進めている。

それが終わったら、ディスプレイの解像度や配置などの情報変更処理。

順調だと思うのだが、やはり進みが遅い気がする。前の日記から6日も経っているではないか。

モチベーションを上げるためにも、この次は音声出力ではなく、ウィンドウ生成とOpenGLを進めるべきか。


2013/08/06 21:50

ようやくlinuxのゲームパッドのボタンやら軸やらのイベントとか対応して、linux側のゲームパッド対応は完了した。

windows側は後回しにして、次はディスプレイ管理か音声出力か、かなぁ。前のプロジェクトで、前者は既に作ってあるし、後者は中途半端なところまで進めている。ディスプレイ管理が先かなぁ。

ちなみにライブラリのサイズは以前より小さくなった。74KBくらいのが55KBくらいになった。例外クラスが無くなったからなのか、エクスポートするのがクラスではなく関数になったからなのかは分からんが。


2013/08/03 22:35

今日は、地元のお祭りに行きました。最後の花火を見て、きれいだなぁと思いました。おわり

作り直しは着々と進行中。ペースがとろい気もするけど。

文字コード変換とか、linuxのゲームパッド接続・切断検知処理とかは完了している。

前よりいい構成になった気がする。#define DPIMPLEMENTとかいう、マクロ名をミスるだけでバグになるような記述も使わないようにしたし、ファイルの構成も、インターフェースと実装を完全に別にした。前は混ざっちゃってたからなぁ。

オブジェクト生成時に例外投げてたのもなくした。構造体を生成し、そのアドレスを返すだけの関数にしたので、失敗時にはnullを返すだけ。その代わり、対応する破棄関数を忘れずに呼び出して破棄する必要があるが、std::unique_ptr、std::shared_ptr、std::weak_ptrのエイリアスを定義しておき、それらを使えば自動的に破棄関数が呼ばれるようにしてあるので問題はない。

私としては、deleterをコンストラクタで設定するstd::shared_ptrとかあんま使う気しないんだけども。std::unique_ptrだけで十分なんじゃないかなと思っている。

でもまぁ、せっかくあるのだし、定義しておいて損はないだろうとか、そんな感じ。

今はまだbitbucketにpushしてないどころか、プロジェクトを作ってすらいないけど、まぁそのうち。


戻る