Programming」カテゴリーアーカイブ

gst direction next frame

JavaScript でスマホゲームもいいけどメインの GTK+ もやらねば。
久々に Y901x の更新、ポーズからコマ戻しが上手くいく方法を見つけたので。

# self.player @ playbin
# self.settingwin @ My Setting

def set_next_frame(self, rate):
    """
        1 frame up down (rate 1.0 or -1.0)
    """
    if self.settingwin.direction != rate:
        self.settingwin.direction = rate
        self.set_playback_direction(rate)
    event = Gst.Event.new_step(Gst.Format.BUFFERS, 1, 1.0, True, False)
    self.player.send_event(event)

def set_playback_direction(self, rate):
    """
        Change direction
    """
    pos = self.player.query_position(Gst.Format.TIME)[1]
    if rate >= 0.0:
        self.player.seek(
                rate,
                Gst.Format.TIME,
                Gst.SeekFlags.FLUSH | Gst.SeekFlags.ACCURATE,
                Gst.SeekType.SET, pos,
                Gst.SeekType.SET, -1)
    else:
        self.player.seek(
                rate,
                Gst.Format.TIME,
                Gst.SeekFlags.FLUSH | Gst.SeekFlags.ACCURATE,
                Gst.SeekType.SET, 0,
                Gst.SeekType.SET, pos)

def on_play(self, widget, data=None):
    if self.settingwin.direction == -1.0:
        self.settingwin.direction = 1.0
        self.set_playback_direction(1.0)
    if self.player.get_state(1)[1] == Gst.State.PLAYING:
        self.player.set_state(Gst.State.PAUSED)
    else:
        self.player.set_state(Gst.State.PLAYING)

逆転させる手続きを分離して send_event するだけだった。
GLib.idle_add とか色々試したのに実はこんなに簡単だった…

これなら関数を抜けるので逆転した後で 1 コマ移動ということになるのかな。
再生開始で正転に戻すのを忘れないようにと。

それと手段が全然解らず困り果てていたシークバー上のマウスホイール。
event.direction 引数が Gdk.ScrollDirection.SMOOTH になるのよ。
Gdk.ScrollDirection.UP, DOWN になる記事以外見当たらなかったし。

http://nullege.com/codes/show/src%40p%40i%40pitivi-HEAD%40pitivi%40utils%40widgets.py/1035/gi.repository.Gdk.ScrollDirection.UP/python

そういうことだったのか!
やっぱり GPL のコードを見たほうが圧倒的に参考になるね。
何も作品を作っていなさそうな人って何故勉強しているのか、日本人に多過ぎ。

def on_seek_scroll_event(self, widget, event):
    """
        Mouse Wheel event
        widget @ GtkScale
    """
    delta = 0
    if event.direction in [Gdk.ScrollDirection.UP, Gdk.ScrollDirection.RIGHT]:
        delta = 1
    elif event.direction in [Gdk.ScrollDirection.DOWN, Gdk.ScrollDirection.LEFT]:
        delta = -1
    elif event.direction in [Gdk.ScrollDirection.SMOOTH]:
        unused_res, delta_x, delta_y = event.get_scroll_deltas()
        if delta_x:
            delta = math.copysign(1, delta_x)
        elif delta_y:
            delta = math.copysign(1, -delta_y)
    if delta:
        location = widget.get_value() - (delta * 10000000000)
        if location > 0 and location < self.playinfo.duration:
            self.set_play_position(location)
            self.put_time_status(location)

これで約 10 秒送りなホイールスクロールが可能になった。
Fedora 20 でしか試していないけど多分 GNOME なら大丈夫だろう。
次バージョン早く出ないかなぁ、20 が安定しているからいいけど半年サイクルに慣れ過ぎた。

Gtk+ 3.10 on Ubuntu 14.04

Ubuntu 14.04 が出たが Fedora な筆者はどうでも…よくない。
GtkHeaderBar や GtkStackSwitcher は Unity 環境ではどうなるか確認せねば。
使用感とかは他人に任せてと。

筆者が書いた下記サンプルコードで試してみる。
GTK+ 3.10 – L’Isola di Niente

gtkheaderbar

GtkHeaderBar はそのまま使えるけど標準とは異なるものになってしまう。
つまり標準の Nautilus とかは改造しているということだったのか。

それに枠に影がなくなるのでウインドウが重なると境界が解らない。
更に最大化しても上部バーと一体化せず一段下へと標準とは異なる動作に。
というか、リサイズできなくなる。

なんだよ、つまり GtkHeaderBar は使えないということじゃないか。
詰めが甘いのか意図的なのかは解らないけど。
GtkStack, GtkStackSwitcher, GtkListBox は問題なく使えるようです。

GtkHeaderBar and GStreamer | PaePoi

GTK+ 3.10 なのだからこの動画の画面が出ない症状は同じだった。
いや GNOME だと真っ黒だけど Unity だと透明になる、音だけなのは同じ。
でも Totem 3.12 は GtkHeaderBar 採用になっているんだよな。
このあたりは Fedora 21 の時に。

appmenu

ApplicationMenu は GNOME と同様になるようにしたようです。
なのに何故か Nautilus 等のメニューバーは古いものを採用。

nautilus_gnome

menubar_ubuntu

同じ Nautilus 3.10.1 のはずなのに何だよこの違い。
というかこれなら 3.8 のままでいいじゃないか、と思うのだが。

他にも GNOME 3.10 を知っている人ならツッコミ所が多々。
3.10 で GtkStackSwitcher になった部分が全部 GtkNotebook に変更って。
ユニバーサルアクセス設定等の GtkListBox も同様、これは古いアプリのまま?
GtkHeaderBar 以外は特に問題ないのに何故古いままな UI に戻すやら。

他にも GNOME がボタンをアイコン化した部分等も何故か文字列ボタンに戻している。
GNOME プロジェクトの成果物に昔ながらの UI をわざわざ被せた感じ。
おかしいな、Unity ってタッチパネル向けに振った UI じゃなかったか?

独自にやっていたらベースの GNOME アプリ側もやってきたので色々あるだろうけど。
3.12 は Gedit も Totem も GtkHeaderBar になるんだが、どうするのだろう。

当面 GTK+ アプリは Unity 環境専用ビルドを別途で用意する必要あり。
なんて嫌だぞこのやろう。

Gjs I/O Stream

以前下記で Seed, Python で Gio による読み書きをやったのを Gjs にしてみた。
Gio Streaming I/O @ Seed and PyGI | PaePoi

GCancellable 等を指定(null でいい)しないといけなかった。
他色々と Seed より Python に似ていて困惑。

/*
    Gjs Streaming I/O File Read and Write Sample
*/

const Gio = imports.gi.Gio;
const Format = imports.format;

String.prototype.format = Format.format;

let filename = "test_gjs.txt";
const lines = "Japan\n\n日本語";

// Write
let f = Gio.file_new_for_path(filename);
let fstream = f.replace(null, false, Gio.FileCreateFlags.NONE, null);
try {
    // Error, This is no Exception.
    // let dstream = new Gio.DataOutputStream(fstream);
    // g_output_stream_write: assertion 'G_IS_OUTPUT_STREAM (stream)' failed
    let dstream = new Gio.DataOutputStream({base_stream:fstream});
    dstream.put_string(lines, null);
} catch (e) {
    // Without meaning
    log("*** ERROR WRITE: " + e.message);
}
fstream.close(null);

// Read
f = Gio.file_new_for_path(filename);
fstream = f.read(null);
// Same as above
let dstream = new Gio.DataInputStream({base_stream:fstream});
while (1) {
    let [text, len] = dstream.read_line_utf8(null);
    if (text == null) break;
    print("%s(%d)".format(text, len));
    // or print(text + "(" + len + ")");
}
fstream.close(null);

/* output
Japan(5)
(0)
日本語(9)
*/

DataOutputStream 等の引数は json で指定しないと認識してくれない。
現時点では理由が解らない、GOutputStream のサブクラスと認識できないのか?
とにかく Error で困ったら json 指定にすればなんとかなるっぽい。

しかも GError 引数なのに例外にならず普通にエラー。
try ブロックを書いたけど無意味だった、これはちと困る。

おまけで let 変数のスコープは try ブロック内でも有効だと解った。
Python と同様にするには var を利用、注意しよう。

// var is OK
let f = Gio.file_new_for_path("a.txt");
try {
    // var fstream = f.replace(null, false, Gio.FileCreateFlags.NONE, null);
    let fstream = f.replace(null, false, Gio.FileCreateFlags.NONE, null);
} catch (e) {
    //
}
fstream.close(null); // ReferenceError
# Python is OK
f = Gio.file_new_for_path(filename)
try:
    fstream = f.replace("", False, Gio.FileCreateFlags.NONE, None)
except Exception as e:
    pass
fstream.close(None)

Seed にある c_new という意味不明な指定が無いのはちょっぴり嬉しいね。
それ以外は全部 Gjs のほうが面倒臭いけど。

戻り値が Python 同様に 2 つ以上である場合がある。
Python はタプルなんだけど、タプルが無い言語でもこの手があったか。
まあどちらも引数に渡された変数の値を変更できない言語だし。

どうも PyGObject の手段を参考に作っているような気がする。
いや逆かも、というか GLib 側の意向でこうなったのかな?

とにかく Python 屋なら Seed より Gjs のほうがなじみやすいという結論で。

Gjs is JavaScript

最近知ったけどガールフレンド(仮)というスマホゲームって普通にスマホのブラウザ上で動くブラウザ版ってのがあるんだね。
他にも同様なものがあるらしい、つまり HTML5 と JavaScript 製なのか。
スマホアプリは Objective-C, JAVA しかないと思っていたよ。

そういえば Google Chrome エクステンションも JavaScript だ。

ところで筆者のパソコンは Fedora で GNOME を愛用している。
何を今頃と思われそうだけど gnome-documents って Gjs 製なんだね。

gnome_documents

こんなところにも JavaScript が。
知らぬ間にあらゆるものが JavaScript になっていってる。

もう毛嫌いしている場合じゃない、普通に使えるくらいにはならないと。

ということで久々に Gjs を。
Seed プロジェクト側はヤル気が無いみたいだし。

http://ftp.gnome.org/pub/GNOME/sources/seed/
http://ftp.gnome.org/pub/GNOME/sources/gjs/

二年くらい前に少し触った頃と随分変わった気がする。
単に情報が色々出て来ただけだが、やはり日本語情報は皆無に近いけど。
とりあえず gnome-documents のコードを参考にしてウインドウを作ってみる。

const Gtk = imports.gi.Gtk;
const Gio = imports.gi.Gio;
const GLib = imports.gi.GLib;
const Lang = imports.lang;

const TestWindow = new Lang.Class({
    Name: 'TestWindow',
    Extends: Gtk.ApplicationWindow,

    _init: function(app) {
        this.parent({
                application: app,
                width_request: 300,
                height_request: 200,
                title: "TitleBar" });
        // or let button = Gtk.Button.new_with_label("Click!");
        let button = new Gtk.Button({ label: "Click!" });
        // or button.connect('clicked', Lang.bind(this, this._onButtonClicked));
        button.connect('clicked', function() {
            button.set_label("DDDone!");
        });
        this.add(button);
        this.show_all();
    },
    /*_onButtonClicked: function (button) {
        button.set_label("Done!");
    }*/
});

const Application = new Lang.Class({
    Name: 'Application',
    Extends: Gtk.Application,

    _init: function() {
        // TaskBar Title
        GLib.set_application_name("Test");
        // property
        this.parent({
                application_id: 'apps.test.Test',
                flags: Gio.ApplicationFlags.FLAGS_NONE });
    },
    // override activate signal
    vfunc_activate: function() {
        new TestWindow(this);
    }
});
let application = new Application();
application.run(ARGV);

GtkApplication は Gjs からも使えるようになったみたい。
というか gnome-documents が普通に使っていた。

class みたいに扱う時 Seed は GType、Gjs は Lang.Class。
Name 指定は必須、継承元は Extends にて指定、コンストラクタが _init ね。
なんとも奇妙だが JavaScript 仕様に class は無いので慣れるしかない。

プロパティセットは Python が __init__ で Gjs が parent にて可能。
普通にドットから代入でもいいけど。

# Python
self.props.title = "new Title"
// Gjs
this.title = "New Title";

シグナルハンドラは Vala のように無名関数が利用できる。
connect でもいいんだけど何故こんなに面倒な書き方なんだろう。
Python でも使えるといい気がするけどインデントが台無しになるお。

オーバーライドは Python が do_ で Gjs が vfunc_ のようだ。
無駄な connect を書かずにすむのは嬉しいね。

const Gtk = imports.gi.Gtk;
const Lang = imports.lang;

const TestWindow = new Lang.Class({
    Name: 'TestWindow',
    Extends: Gtk.Window,

    _init: function() {
        this.parent({ title: "TitleBar" });
        this.show_all();
    },
    vfunc_delete_event: function() {
        Gtk.main_quit();
    }
});
// Initialize the gtk
Gtk.init(null, 0);
new TestWindow();
Gtk.main();

GtkApplication 使用時は不要だけど Gtk.main では init() 必須。
というより Python だと init 呼び出し不要なのが変ということだが。

Gtk.Button.new_with_label が使えたのは何故か不思議な感じ。
そういえば JavaScript は何でもアリだったな。

こんなことをやっても Web やスマホアプリを作りたい時の参考にならない気も。
とはいえまったく文法を知らないよりはマシだからもう少し続けるかも。

g_list_foreach

STL(C++) の std::list と GLib の GList で foreach してみた。
C と C++ の微妙な違いがあってなかなか興味深い。

C++, STL

#include <iostream>
#include <list>
#include <algorithm>

void
show_data(std::string s) {
    std::cout << s << std::endl;
}

int
main (int argc, char **argv) {

    std::list<std::string> l;
    std::string s;

    for (int i=0; i<3; i++) {
        std::cout << "input " << i << " : ";
        std::cin >> s;
        l.push_back(s);
    }
    // for_each @ algorithm
    std::for_each(l.begin(), l.end(), show_data);
    return 0;
}

GLib

#include <glib.h>

void 
show_data(gpointer data ,gpointer user_data) {
    g_printf("%s\n",data);
}

void 
delete_data(gpointer data ,gpointer user_data) {
    g_free(data);
    data = NULL;
}

int
main (int argc, char **argv) {

    GList* list = NULL;
    gchar s[256];
    gint i;

    for (i=0; i<3; i++) {
        g_printf("input %d : ", i);
        scanf("%s", s);
        //list = g_list_append (list, s); // All Last Data
        list = g_list_append (list, g_strdup(s));
    }
    /* foreach */
    g_list_foreach(list, show_data, NULL);
    /* free */
    g_list_foreach(list, delete_data, NULL);
    g_list_free( list );
    return 0;
}

ビルド結果は同じものが作られるはず。

glist

std::for_each, g_list_foreach 共に関数ポインタを使っている。
GLib はソックリにしようと思ったのでしょうか?
STL は関数オブジェクトが使えるとかもろもろは置いておいて。

ところで for 文等を使わずにズラズラ並べるなら当然下記でもいい。
スタックのメモリ領域なので当然破棄処理も不要。
実際のアプリケーションでこんなコードになることはまずありえないですが。

list = g_list_append (list, "YAMAHA");
list = g_list_append (list, "HONDA");

for 文でコレをやると当然だけど全部同じ s ポインタを参照になる。
なのでデータを拾う毎にヒープに領域を作ってそのポインタを入れていく必要あり。
当然破棄も必須、C++ の std::string は全自動でやってくれているだけだし。

ただ知ってのとおり std::list は整数による添字アクセスができない。
というか何をするにもループ必須で正直使い勝手がよくない。
GList は一応こんなことができるようです。

gchar* c;
/* 3 番目を表示 */
c = (gchar*)g_list_nth_data(list, 2);
g_printf("%s\n", c);
/* 3 番目を削除 */
c = (gchar*)g_list_nth_data(list, 2);
list = g_list_remove(list, c);

STL を少し知っているなら直感的に書くことが可能、かつちょっぴり便利。
でも class は使えないからデストラクタで破棄とかはできないよってか。
むりやり std::list と同じにしようとしたのではないようで面白い。