るいもの戯れ言
#259
2017/01/26 02:05

Gladeの編集画面に、ボーダとか色の指定とかが無いので、どうするのだろうかと思ったら、どうやらCSSを使うようだ。

CSSは外部ファイルから読むことも、テキストとして与えることも可能だが、一番簡単なのはソースに埋め込んでしまう方法だろう。src/resources/style.cssにファイルを配置して、コードからは以下で読み込める。include_str!()は、コンパイル時に指定ファイルを読んでソースの中に埋め込むマクロだ。


    let css_str = include_str!("resources/style.css");
    let css_provider = CssProvider::new();
    css_provider.load_from_data(css_str).unwrap();
    StyleContext::add_provider_for_screen(
        &Screen::get_default().unwrap(), &css_provider, 1
    );

CSSのセレクタだが、id指定の場合、Glade上のIDではなく「ウィジェット名」が使われるので注意が必要だ。

この場合、CSSでは以下のように指定できる。


#titleLabel {
    border: inset 2px;
    background-color: red;
}

GTKのウィジェットクラス名を使って全てのラベルに一律に適用することもできる。


GtkLabel {
    padding: 3px;
}

Glade上のスタイルクラスを使うこともできる。

この場合、CSSでは以下のように指定できる。


.name {
    border: solid 1px;
}

なお、上のリファレンスではラベルに背景色を付ける例が載っているが、試した限りラベルは透明コンポーネントのようで背景色の設定は効かなかった。

サンプルは、GitHubに置いておいた。

コメントを書き込む

第6曲は、これまでとは違って自由な構成になっている。最初は短調で始まり、

このあたりからクレシェンド。うまく行かない現状への怒りを思わせる。

ここから長調となり、過去の幸せな記憶を思い起こすかのような、幻想的で暖かな感じの曲調になる。

ここからは、なんとなく諦めのような、不思議な音型の繰り返しとなって、そのまま曲を閉じる。

う〜む、何か嫌なことでもあったのか。

楽譜の引用はエキエル版から

コメントを書き込む
#257
2017/01/24 23:58

今日も来た。コメントformのURLを見ているわけではないようだ。

今度は、フォーム内のフィールドのname属性を変更してみた。あと承認待ちのコメントに名前を出さないようにしてみた。

コメントを書き込む
#227
2017/01/24 10:27

GTK(Cairo)での、線、矩形描画が思ったようにいかずに、少し悩んだのでメモ。

例えば以下のパラメータで矩形を描画した場合:

  • 始点: 2, 2
  • 終点: 8, 6
  • 線の太さ: 2
  • 線の色: 青
  • フィルの色: 赤

以下のように描画されるようだ。

線の太さは直径なので、2ピクセル未満とすると、サブピクセルになってしまうので、きっちりドットバイドットで表示したければ、最低でも2を指定する必要がある。また、GTKに再描画を依頼する場合、領域の指定は(2, 2) - (8, 6)にすると線の外周部分が漏れてしまうので、線の太さを考慮して、(1, 1) - (9, 7)を指定する必要がある。完全に1ピクセルの線を引きたかったら、線の太さを0にした矩形を描画した方が良さそう。

コメントを書き込む

作品15の2番目も、3部構成になっているが、今度はどちらも長調になっている。第3、4曲での極端なやり方に反省して、幻想的な雰囲気を壊さないように配慮したのかもしれない。

しかし、中間部の右手の多声進行は複雑だ。

エキエル版での謎の箇所として、まず出だし

そして中間部が終わった後の出だし。この2箇所でスラーのかかり方が微妙に違う。

これが意図したものなのか、単なる間違いなのか良く分からない。ちなみに全音だと、どの箇所も以下になっている。

みんな違うし ^^;

今回の演奏では、エキエル版の最初の出だしのスラーのかかり方を正としている。

楽譜引用は、エキエル版と全音版。

コメントを書き込む
#225
2017/01/24 04:01

コメント・スパムが来ているが、コメントは承認が必要なので全部削除。ただ、削除も面倒なので何か対策ができるか試し中。

とりあえずIPのblacklistをnginxに入れてみたが効果無し。これまでコメントスパムって、WordPressとかの有名どころのアプリケーションを使っているところに、機械的に投げ込んでいるのだと思っていたのだけど、うちのようにフルスクラッチのところにも来るというのは、どういう仕組みなのだろう。formのURLがpost comment的なところを見つけて送っているんだろうか。まさか人力でもあるまいし。

というわけでコメント投稿のURLを変更してみた。Play!だとroutesを変えるだけで良いのでラクチンだ。

コメントを書き込む

作品15も、9に引き続き3つで構成されている。作品15の最初の曲となるこの曲は、第3曲と同じで前後を穏かな長調、中間部を激しい短調のパッセージという形式になっている。ただ第3曲よりも洗練されて、全体に簡潔にまとめらている。

中間部、第2小節はペダルを踏む指示があるけど、スタカーティシモ。どのくらいペダルを踏み込むのかが演奏者に任されている感じ。

楽譜引用はエキエル版

コメントを書き込む

Rustで、Multimap(1つのキーに複数の値を登録できるMap)を実装してみる。後でキーをソート順の取り出したいので、BtreeMapを使って、値にVecを入れる。


use std::collections::BTreeMap;

struct Bag {
    map: BTreeMap<i32, Vec<i32>>
}

impl Bag {
    fn add(&mut self, key: i32, value: i32) {
        match self.map.get_mut(&key) {
            None => {
                self.map.insert(key, vec!(value));
            },
            Some(vec) => vec.push(value)
        }
    }
}

でも、これはコンパイルが通らない。


error[E0499]: cannot borrow `self.map` as mutable more than once at a time
  --> /Users/shanai/.emacs.d/rust-playground/at-2017-01-22-230525/snippet.rs:32:17
   |
30 |         match self.map.get_mut(&key) {
   |               -------- first mutable borrow occurs here
31 |             None => {
32 |                 self.map.insert(key, vec!(value));
   |                 ^^^^^^^^ second mutable borrow occurs here
...
35 |         }
   |         - first borrow ends here

mutable borrowが2回起きているという警告。まずここでself.mapに対するmutable参照を取得している。


        match self.map.get_mut(&key) {

で、このmatchが終了する前に、ここでもう一度self.mapに対するmutable参照を取得している(insertは、mutableなselfが必要)。


            None => {
                self.map.insert(key, vec!(value));
            },

つまりmutableな参照が、2つ存在してしまう瞬間がある。これはRustでは禁止されている。以下がエラーになるのと同じ。


    let mut i = 0;
    let pi = &mut i;
    let pi2 = &mut i;

スコープを分けて、mutable参照が2つ同時に存在する瞬間を無くしてしまえば良い。


impl Bag {
    fn add(&mut self, key: i32, value: i32) {
        {
            match self.map.get_mut(&key) {
                None => {},
                Some(vec) => {
                    vec.push(value);
                    return
                }
            }
        }
        
        self.map.insert(key, vec!(value));
    }
}

でも、BtreeMapにはentry()という素敵なメソッドがあるので、これを使うのが簡単。


impl Bag {
    fn add(&mut self, key: i32, value: i32) {
        self.map.entry(key).or_insert(vec!()).push(value)
    }
}

entryはキーを引数に取り、Entryというenumを返す。指定されたキーが無ければVacant、あればOccupiedが返る。or_insert()を呼び出すと、Vacantの場合は、引数に指定された値をmapに格納した上で、その値へのmutable参照を返す。Ocupiedの場合は、値へのmutable参照を返す。なので上のように書けば目的が達成できる。


fn main() {
    let mut bag = Bag { map: BTreeMap::new() };
    bag.add(1, 10);
    bag.add(1, 20);
    bag.add(2, 100);
    println!("map = {:?}", bag.map);
}


map = {1: [10, 20], 2: [100]}

コメントを書き込む

DrawingAreaは、デフォルトではマウスのイベントを拾えないようだ。発生するイベントの種類を増やすには、WidgetExt::add_event()というメソッドを使うらしい。


    let drawingArea: gtk::DrawingArea = builder.get_object("drawingarea1").unwrap();
    drawingArea.set_size_request(300, 300);
    drawingArea.add_events(gdk_sys::GDK_BUTTON_PRESS_MASK.bits() as i32);
    drawingArea.add_events(gdk_sys::GDK_BUTTON_RELEASE_MASK.bits() as i32);

JavaのSwingだと、clickedというイベントで同じ場所でマウスのボタンが押されて離されたという状態を取得できたが、どうやらGTK+には、そういうのが無いようだ。自分でPRESSの時の座標を覚えておいて、RELEASEの座標が同じだったらクリックと判定する必要がある模様。イベントハンドラの登録は、WidgetExt::connect_event()を使う。


        drawingArea.connect_event(|_, e| {
            let clone = e.clone();
            match e.get_event_type() {
                EventType::ButtonPress => {
                    let res: Result<EventButton, Event> = clone.downcast();
                    println!("pressed: {:?}", res.unwrap().get_position());
                },
                EventType::ButtonRelease => {
                    let res: Result<EventButton, Event> = clone.downcast();
                    println!("released: {:?}", res.unwrap().get_position());
                },
                _ => {}
            }
            return Inhibit(false);
        });

Event型で来るため、特定のイベントであるかをEventTypeで判定して、ダウンキャストするというなんとも汚ないコード。なぜイベント自体をenumにしなかったのかな。GTK+との関係で難しいのだろうか。

クロージャの引数は&Eventで、downcastの引数は、&selfではなくてselfそのものなので、そのままイベントを渡すとmoveが起きてしまってコンパイルエラーになる。なので、一度clone()している。

コードサンプルは、こちら

コメントを書き込む
ショパン・ノクターン第3曲 作品9-3

作品9は3つのノクターンで構成されていて、第3曲が最後。ショパンとしては、この曲は意欲作だったのではないかと思う。ショパンのノクターンは3部構成になっているものが多いけど、この曲は、その中間部の雰囲気をがらりと変えて大きな効果を得ることを狙ったのだと思う。ただ、残念ながら一般には作品9の中での知名度は最も低くなってしまった。まぁ普通の人からすると、え、何、なんでノクターンなのに、こんなに激しいの? みたいな違和感が大きかったんだろうな。まぁ、こんな具合に作曲者が空回りしてしまうケースというのは多い。

この曲は、スタカーティシモが多用されている。面白いのはタイの後の音にスタカーティシモが付いているケースがあって、これ、どう表現するか悩みどころ。実際の演奏会なら大げさに右手を跳ね上げたりするんだろうか。

中間部。Agitatoでガンガン行く。ショパン的には「どうだ!」って感じだったのだろうな。

最後のアルペジオは、ものすごく綺麗だけど、これppで弾くのすごく難しそうで禿げそう。

楽譜引用はエキエル版

コメントを書き込む
1 / 8