本日の Fedora アップデートでこんなのが出た。

LOKDocView って何だ？

Development/Integrating LOKDocView and GNOME Documents – The Document Foundation Wiki

libreoffice 文書を GNOME Document で表示する API なのか。
ということは gir でバインドされているのかな。

普通にあったわ、コレって今まであったっけ？
まあそれはいいや、さてサンプルコードを探してみよう。

GitHub – pranavk/lokdocviewer: An application for testing LOKDocView

js/py 両方用意してくれているとは親切ですね。
しかし new メソッドの引数が PyGObject は 2 つで Gjs は 3 つ。
Gjs らしく new キーワードに書き換えるとコアダンプ。

#!/usr/bin/gjs

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

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

    _init: function(app) {
        this.parent({
            application: app
        });
        // Segmentation fault
        //this.view = new LOKDocView.View();
        this.view = LOKDocView.View.new(null, null, null); // OK
        this.view.open_document(
            "/home/sasakima-nao/syokumu.odt",
            "{}",
            null,
            Lang.bind(this, function() {
                this.view.set_edit(true);
            }),
            null);
        let sw = new Gtk.ScrolledWindow();
        sw.add(this.view);
        this.add(sw);
        //
        this.show_all();
    }
});

let app = new Gtk.Application();
app.connect("activate", function() {
    new LOKWindow(app);
});
app.run(null);

前々回みたいな問題があるし…
GNOME はぶっちゃけ Gjs に全面移行したいのだろうけどまだ問題が多いなぁ。
てか Python はサードパーティなのに対応っぷりがスゲェ。
当面は Python と併用が続くのだろう。

コレを使って何か作るかな、ここんとこネタ切れなのは秘密だよ。

おまたせ、Comipoli Gjs 版が遅くて出せない原因が判明しました。

#!/usr/bin/env python3

import gi
gi.require_version('Clutter', '1.0')
gi.require_version('GdkPixbuf', '2.0')
from gi.repository import Clutter, Cogl, GdkPixbuf

Clutter.init()

PICTURE = "burgman400.jpg"

pixbuf = GdkPixbuf.Pixbuf.new_from_file(PICTURE)
image = Clutter.Image()
image.set_data(
    pixbuf.get_pixels(),
    Cogl.PixelFormat.RGB_888,
    pixbuf.get_width(),
    pixbuf.get_height(),
    pixbuf.get_rowstride()
)

と

#!/usr/bin/gjs

const Clutter = imports.gi.Clutter;
const Cogl = imports.gi.Cogl;
const GdkPixbuf = imports.gi.GdkPixbuf;

Clutter.init(null);

const PICTURE = "burgman400.jpg";

let pixbuf = GdkPixbuf.Pixbuf.new_from_file(PICTURE);
let image = new Clutter.Image();
image.set_data(
    pixbuf.get_pixels(),
    Cogl.PixelFormat.RGB_888,
    pixbuf.get_width(),
    pixbuf.get_height(),
    pixbuf.get_rowstride()
);

で

何ですかこの圧倒的なスピード差は！！！
というより Gjs のこの異様な遅さは何なんだ？
GdkPixbuf を使うだけなら特に差が無いのに。

憶測だけど PyGObject は get_pixels でバイナリ出力を直接使っていると思う。
Gjs は多分バイナリ出力を Uint8Array オブジェクトに変換している。
言語仕様の制限だろうからセット関数の追加が無いかぎりこのままだろうね。

ClutterImage に画像セットはコレしか手段が無い、これは困った。
Gjs でいくなら ClutterCnavas で cairo という手しか無いっぽい。
でもそれなら GtkDrawinArea でいいじゃん、ということになり…

結論、Clutter で画像を使うのに Gjs は絶望的に向いていません。