読者です 読者をやめる 読者になる 読者になる

嘆きの壁

いつもなんか嘆いてる

Krile Advent Calendar 25日目: アトリエシリーズ

この記事は Krile Advent Calendar 2016 - Adventar 25日目の記事です。

www.adventar.org

アトリエシリーズ

さんざん百合の話が繰り広げられてきた Krile Advent Calendar ですが、最後に持ってくるとしたらこれということで、 今日はアトリエシリーズに関する記事とします。

続きを読む

二夜連続特集『うらら迷路帖』 その2

この記事は うらら迷路帖 Advent Calendar 2016 - Adventar 24日目の記事です。

www.adventar.org

昨日の記事もうらら迷路帖関連なのでよければご覧ください。

karnoroid.hatenablog.com

アニメ『うらら迷路帖

今日の内容は、「この冬最も熱いアニメ」「優勝しすぎて殿堂入りに最も近い」「どちや」の呼び声高い2017冬アニメ『うらら迷路帖』です。

www.tbs.co.jp

さて、このアニメ『うらら迷路帖』ですが、先日ようやく(!!)PVが公開されました。

www.youtube.com

うらら迷路帖アニメのキャストグループ「らびりんず」が歌う「夢路らびりんす」がBGMでかかっていますが、完全に頭に残るやつですね。 右クリックでループが選択できることにどれほど感謝したことか、もう何度見ているのか覚えていません。

さて、PV中ではいろいろなシーンが描かれていますね。そのほとんどが原作シーンの準拠となっていますが、 どれくらい準拠しているのか調べてみました。

ということで、この先はネタバレが含まれます。うらら迷路帖をまだ購入されていない方はもうさすがにいらっしゃらないと思いますが、 万が一未購入であれば今すぐ買いに行ってください。今すぐ。

続きを読む

二夜連続特集『うらら迷路帖』 その1

この記事は Krile Advent Calendar 2016 - Adventar 23日目の記事です。(うらら迷路帖 Advent Calendar の記事ではありません)

www.adventar.org

漫画『うらら迷路帖

おすすめのマンガ各種と『うらら迷路帖

最近、マンガを買いに買っている私です。メロンブックスのポイントが6000ポイントを超えていて自分でも若干引いています。 メロンブックスでは購入金額のおよそ5%分ポイントが付くのですが、怖くなるのでいくら使ったかは計算しないことにします。

さて、今まで買ったマンガの中には、たびたび読みかえすほど好きなもの、残念ながら続き買うのをやめてしまったもの、諸々あります。

好きな漫画を挙げるとしたら、Krile Advent Calendar においてもいくつか紹介されていますが、例えば「少女終末旅行」「わたしのカイロス」「ゆるキャン△」「紅殻のパンドラ」「やがて君になる」、そして先日アニメ化が突然発表されました「メイドインアビス」(http://miabyss.com/)などが好きです*1

さて、そんな大好きな漫画の中から、この場は百合アドベントカレンダーであることを鑑みて、私がこよなく愛してやまない、そして、この冬最も熱いアニメとなる予定であるうらら迷路帖について、僭越ながら、少々書かせていただきます。

うらら迷路帖 (1) (まんがタイムKRコミックス)

うらら迷路帖 (1) (まんがタイムKRコミックス)

*1:ここでは「ゆゆ式」「きんいろモザイク」「ご注文はうさぎですか?」は必修科目として挙げていません

続きを読む

私の推しマンガ5選

こんばんは。かーのです。Twitterではめっきりツイートしなくなってしまいました。

さて、

で発言した内容ですが(鍵アカウントなので以下に内容を添付しておきます)、ニーズがあったのでやってみます。

ここ1年以内に買ったマンガから面白かったものを5つ、苦渋の決断で選び出して紹介します。

f:id:karnoroid:20160107194915p:plain

なお、ツイートの通り、以下の内容において

f:id:karnoroid:20160107195045p:plain

f:id:karnoroid:20160107195119p:plain

は紹介いたしません。なぜなら必修科目ですので、当然みなさん既にお持ちでしょう。(あと、買ってから1年以上経ってるし)

続きを読む

邪道式 Windows Presentation Foundation

世間ではUWPだ、Electronだという声が大きくなっていますが、今更WPFの話をしようと思います。 というのも最近は、WPFのレイアウトに関する長年の悔恨をそろそろ晴らしておきたいと思いまして、とある難題を調べ漁る毎日を送っていたからです。 あと、最近ブログにプログラミングの話題を書いていなかった上に、そもそもブログに文章を書いていなかったので、長文記述力を取り戻すためにもここらで何か書いておくかという思惑もあります。

※この内容は続き物な気がしますが、次回投稿があるかどうかは主に気力がないので不明です。ということで、第n回みたいなタイトルは付けないでおこうと思います。

やっていること

拙作のTwitterクライアント「Krile StarryEyes」にはタイムラインのスクロール制御を組み込んでいるのですが、こいつが動いたり動かなかったりと 中々適当な挙動を見せてくれるうえに、ついに最近(.NET Framework 4.6以降?)は全く動かなくなったとの話も聞きます。

KrileのタイムラインはWPFのリスト、より詳しく言えばピクセルベースのスクロールとコンテナリサイクルを有効にしたVirtualizingStackPanelを レイアウトに使用するItemsControlで構成されています。こいつが思い通りに動いてくれないわけです。

これをなんとかするため、VirtualizingStackPanelとItemsControl、ScrollViewerの関係を探っています。主にReference Sourceを読み漁り、たまにMSDNを読んでいます。 各種クラスの関係とか内部の実装とかはほとんどドキュメント化されてないので、MSDNだけですべてを探るのはけっこう厳しいものがあります。 そういう意味ではReference Sourceはとても参考になりますが、やっぱり読みづらいです。。。

そもそも論:WPFレンダリングプロセス

昔々、WinFormsのコントロールは、最悪自前で全部描いてしまえばなんとかなる、みたいなことがありました。

しかしWPFXAMLに予め定義された要素を置いて、あとはスタイルなりビヘイビアなりで制御して、という形がほぼすべてです。 WinFormsではよく見た、完全にカスタムしたコントロールをコードで作るという例はWPFではあまり聞いたことがないです。

というのも、WPFXAMLでちょいちょいっと書くだけで、かなり複雑なカスタマイズにも対応可能だからです。 XAMLで見た目を定義するのはとても楽ちんですし、今更レイアウトを計算するコードを書くなんてダサいし非効率的だしバグの温床になるというわけで、 自分で何から何まで面倒を見るコントロールを作るという文化はWPFではほとんど廃れてしまったように感じています。

私はこれまで、WinFormsのコントロールとくらべてWPFのコントロールはカスタムできる範囲に限度があり、そしてそれは最悪自分で全部レンダリングできる WinFormsと、レンダリングの要素が予め用意されているものに限られるWPFの構造に起因している と思い込んでいました。そして、それは事実ではありませんでした。

つまり、やりようによってはWinFormsの流儀である DO IT YOURSELFWPFにおいても通じるようです!それができるなら、もう既存のコントロールの 不快な動作にやきもきする必要もなく、自分で全責任を持って楽しい毎日を過ごすことができそうです。

そんな楽しい毎日を過ごすために、ここでWPFがどうやってUIを組み上げているかの説明をしておきたいと思いますおきたいと思いましたが、中途半端に終わってしまいました。

反省の弁

そして、何より今まで私は、WPFがどうやって要素をレイアウトしているか、どうやって要素を描いているか、そんなことに気を配らずにアプリケーションを書いてきました。これは大変に恥ずべきことです。。。

どうやって動いているかが分かれば、あとはそれをなぞるなり逆手に取るなり無視するなりの対策が打てるようになるので、もっとマシなアプリケーションが書けそうな気がします。 反省も含めて、WPFのレイアウトシステムがどうなっているかを簡単になぞりたいと思います。

レイアウトとレンダリング

そもそも、WPFレンダリングは2つのツリーによって行われています。

ひとつは、「LogicalTree」。XAMLで記載する内容に近いデータが保持されています。たとえば、Windowの下にGridがあり、その中にListBoxがあり、その中にはさらにListBoxItemがぶら下がっている、そんな構造が そのまま現れます。

そしてもう一つが「VisualTree」。こちらは、画面に描画するコンポーネントが登録されます。ListBoxの中にはScrollViewerがあったり、さらにその中にVirtualizingStackPanelがあったり、…。

おおよそ見当が付く通り、WPFはこの「VisualTree」を使って描画します。そして、VisualTreeに参加する資格があるのは「System.Windows.Media.Visual」以下のクラスです。

そしてMSDNにはVisualについて「WPF でヒット テスト、座標変換、境界ボックス計算などの描画をサポートします。」との記載があります。 つまるところ、WPFで何かレンダリングするためには、以下の条件が達成できれば良いわけです。

  • ヒットテスト - 指定した座標がVisual内にあるか判定
  • 座標変換 - 指定したVisualに含まれる子Visualの相対座標の制御
  • 境界ボックス - bounding box、指定したVisualが画面中で占める領域を計算

ところで、Visualではヒットテストや座標変換を制御できるvirtualメソッドはありますが、Bounding Boxの言葉は一言も出てきません。

それもそのはず、Bounding Box周りのvirtualメソッドはすべてinternalになっています: Visual.cs - Microsoft Reference Source

ではどうするかというと、その一層下の UIElement を見なければなりません。

UIElementは「MeasureCore」「ArrangeCore」などのレイアウトに関係するほかにも、膨大なvirtual methodを提供してくれます。詳しくはMSDNをご覧ください。

そう、実際には、ユーザが何か独自のコントロールを生み出したい場合、UIElementが提供する機能以上のことは行えません。 しかし、UIElementは十分すぎる機能を提供してくれます。自分で実装する気力さえあれば、きっとあなたのソリューションを見つけることができます。

さて

だいぶお酒が回ってきたので、今日はここまでにしたいと思います。

この記事について

基本要素の概要 - MSDNを見るとよくわかるかもしれません。

第10羽(+2) Teaを探す日常

この記事は、ごちうさ Advent Calendar 2015 12日目(12/12)の投稿です。

gochiusa.connpass.com

前日はろっとさんの記事が上がる予定でしたが、今のところまだのようです。

ご注文はうさぎですか?といえば、喫茶店「ラビットハウス」が主な舞台です。 皆さんは、ラビットハウスに行くことがあったなら、何を飲みたいですか?

おそらく、コーヒーを連想されるかと思います。もしくはココアでしょうか?

そう、ラビットハウスといえばコーヒー、コーヒーといえばラビットハウスです。 ラビットハウスの描写にもその事実は強く出ており、特にチノがコーヒーをサイフォンで淹れているシーンは強烈な印象を与えていることと思います。

f:id:karnoroid:20151201233638p:plain

このように、コーヒーばかりが脚光を浴びていますが、実はラビットハウスではお茶も飲めることにお気づきでしょうか?

暗唱できるほどにご注文はうさぎですか?アニメを見ている、また、ワンシーンから何羽の何秒目か、または何巻の何ページかを即答できる難民諸君は当然ご存知でしょう。 ラビットハウスのメニューには、一般的な喫茶店同様、しっかり紅茶が書かれています。

f:id:karnoroid:20151201234143p:plain

しかし、飲めるお茶は紅茶だけではないのです。

続きを読む

Krile StarryEyesをどうするか

少しずつしか進まなくなってきたのでメモ。 尋常じゃなく忙しそうな未来が見えるので、頓挫しそうな予感しかしない。

Twitter受信まわり

  • REST APIのレートリミットを考慮してポーリングするようにする
    今のところ、レートリミットに引っかかっても15分くらいで復帰するからいいやーみたいな感じで処理してましたが、2ヶ所3ヶ所で同じ設定を共有するKrileを同時に起動するとお互いでレートリミットを食いつぶしてエラーが頻発するようなので、何らかの理由でレートリミットを見ながら受信するようにしたい。

  • ユーザストリームの処理速度を向上する
    ツイート受信処理速度が Krile Mystique よりもだいぶ遅くなった気がします。なんとか 1000tweets/min くらいまでは捌ききれるようにしたい。

  • 別のソースからの受信を取り入れる
    togetterとかをソースにして読めるようにしたら面白いかなぁと思う。タイムマシン機能(後述)付きで。

UIまわり

  • クエリの廃止、またはGUIとの整合性を取れる形に
    現状のクエリは柔軟ではあるけど使いづらいので、もうちょっと足かせを加える形になったとしても、普段よく使うクエリが使いやすくなるようにしたい。Krile2のクエリに近くなるかも。

  • ツイート表示UIの見直し
    Display Requirements に従う気は毛頭ないけど、スペースが開き過ぎとかいろいろ意見があるので、もうちょっと調整したいですね。あと、スクロールロックがどうもうまく動かないので、ここは抜本的な改良が必要かも。新着ツイートの取り扱いとか。

  • タイムマシン機能
    せっかくDB積んでるんだし、任意の時間から再生できたら面白いよなーとか思う。実況を後から追う時とか。タイムマシン機能を作りこむか、タイムマシン機能が作れるようなプラグインAPIを用意してプラグインで作るか、後者の方が拡張性高いけど時間が無いから無理かもしれない

  • UIを小奇麗にする
    だいぶごちゃごちゃしてきたので、一旦さっぱりさせたい。MahApps.Metro使うのとかやめたいし、設定ビューは別のダイアログに切り出したほうがお互いに楽だし。

  • ダイレクトメッセージとかアクティビティの表示方法を考える
    ダイレクトメッセージはツイートと一緒だし、アクティビティはバックステージビューにしか出てこないけど、出来ればDMはちゃんとしたUI整えてやりたいし、カラムでアクティビティもフィルタして見たりとかしたい。DMはあんまりやる気ないけど、アクティビティは何とかしたいなぁ。

DBまわり

  • 吐くSQLをもっと頭良くする
    今のSQLはお世辞にも速くはないので、もうちょっとまともなの吐けるようにしたい。

  • FTSテーブルを使う
    キーワード探索をする機会が非常に多いので、FTSテーブルで高速化とかしたい。bi-gramとかtri-gramかなぁ。

それで

具体的にどうするか、全然決まってないです。とりあえず目標が明確なツイート受信処理周りをちまちま触って遊んでる状態。

時間がないし、出来れば誰か代わりにやってくれ