GtkPixBuf は SVG 画像をもそのまま扱えて普通に描写できる。
線や図形の描写 – L’Isola di Niente
上記コードで普通に表示できると確認できます。
しかし拡大すると…

eog は綺麗に引き伸ばしされているのに対し、コッチは超ギザギザ！
MComix で試してもギザギザ、Shotwell は表示すらできない。

eog ってショボイと見せかけて実はこんなに優秀だったのかよ…
ではなく。
どうすれば綺麗に表示できるか考えて調べて色々試してみよう。

ーーーーー

自前ソースがギザギザなのは少し考えれば当然だと解る。
なにせ svg を一度 Bitmap 化して引伸す工程にしているのである。
これではベクターデータである svg での曲線が滑らかという恩恵が無い。
結果 jpeg 画像等と何も変わらないギザギザになる。

つまりベクターデータのまま拡縮して直接描写する必要がある。
メタデータを直接編集すればなんとかなる。
って、だからベクターデータの加工には面倒が付き纏うんだよ。

もしコレが特定ライブラリを使えば Easy Mode になるのだったら…
なんて誰でも考え付くよね。
いきなりそのものズバリを見つけてしまった。

RSVG Libary Reference Manual
librsvg – Wikipedia

GtkDrawingArea は GTK3 から cairo で描写している。
なので cairo から rsvg を使う方法を探す。

Cairo: A Vector Graphics Library: Cairo: A Vector Graphics Library

Fedora 21 で rsvg モジュールはデフォルトでは入っていない。
だけど gir には Rsvg が最初からあった、コレを使おう。

cairo って PostScript や PDF も扱えるのか。
面白そうだけど今回は細かいことは置いておいて。
Python 用 cairo ライブラリから SVG を描写する方法を。

Surfaces ? Pycairo v1.10.0 documentation

サーフェス（面）のサイズを変更するには Matrix を使うのか。
1,4 番目引数で x,y のサイズということみたい。
ということで、サーフェスなので paint でなくレンダリングする。

#!/usr/bin/env python3
 
from gi.repository import Gtk, Gdk, Gio, Rsvg
import cairo, sys
 
class Win(Gtk.ApplicationWindow):
    def __init__(self, app):
        """
            DnD SVG Viewer
        """
        Gtk.Window.__init__(self, application=app)
        # svg
        self.svg = None
        # DrawingArea
        self.da = Gtk.DrawingArea()
        self.da.connect("draw", self.on_draw)
        self.add(self.da)
        # DnD
        dnd_list = Gtk.TargetEntry.new("text/uri-list", 0, 0)
        self.drag_dest_set(
                Gtk.DestDefaults.MOTION |
                Gtk.DestDefaults.HIGHLIGHT |
                Gtk.DestDefaults.DROP,
                [dnd_list],
                Gdk.DragAction.MOVE )
        self.drag_dest_add_uri_targets()
        # self
        self.set_title("DnD SVG Viewer")
        self.resize(200, 200)
        self.show_all()
 
    def do_drag_data_received(self, drag_context, x, y, data, info, time):
        """
            On Drop
        """
        uris = data.get_uris()
        f = Gio.File.new_for_uri(uris[0])
        path = f.get_path()
        # Recreate svg
        self.svg = Rsvg.Handle.new_from_file(path)
        # invalidate
        self.da.queue_draw()
 
    def on_draw(self, widget, cr):
        """
            Draw x5 SVG
        """
        if self.svg:
            # x5 size
            matrix = cairo.Matrix(5, 0, 0, 5, 0, 0)
            cr.transform (matrix)
            # Render
            self.svg.render_cairo(cr)
 
class App(Gtk.Application):
    def __init__(self):
        Gtk.Application.__init__(self,
                application_id="apps.test.dnd",
                flags=Gio.ApplicationFlags.FLAGS_NONE)
         
    def do_activate(self):
        Win(app)

app = App()
app.run(sys.argv)

これならギザギザにならずに拡大することができる。
別途でインストールするものは何もないのに、Linux 恐るべし。
いやまあ全部 GNOME プロジェクトのおかげなんですけど。
結論、cairo って実はこんなに面白いんだyo!

前々回。
「g_content_type_guess だと ContentType は拡張子依存みたい」
と書いた手前、筆者的には当然の結果だけど一応試してみた。

#!/usr/bin/env python3

from gi.repository import Gio

# Doesn't exist a File.

ans = Gio.content_type_guess("Not Found.txt")
print(ans)
#=> ('text/plain', False)

# File Create (No Ext).

with open("found", "w") as f:
    f.write("#!/usr/bin/env python3\n")

# g_content_type_guess

ans = Gio.content_type_guess("found")
print(ans)
#=> ('application/octet-stream', False)

# Gio Query

obj = Gio.file_new_for_path("found")
info = obj.query_info(
    Gio.FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE,
    Gio.FileQueryInfoFlags.NONE )
ans = info.get_content_type()
print(ans)
#=> text/x-python

やっぱり拡張子の有無で関数の違いが出るんですね。
Gtk, GLib と付き合いが長いので結果は解っていたけどこういうこと。

つまり面倒臭い手段を使えば予定通りな結果が得られる。
GNOME プロジェクトは計画的にやっているんだろうな、と思ってしまう。
何故こうなるかは割愛、これは GNOME 関連では単純なほうだyo!

VTE といってもホンダのバイクじゃありません。
Virtual Terminal Emulator の略であります。

Gedit 標準プラグインに Python コンソールがありますが全然違う。
gnome-terminal そのものみたいなエミュレーターです。

GNOME wiki の VTE Terminal Widget Library ページ。
Apps/Terminal/VTE – GNOME Wiki!

バージョンがややこいけど 2.91=0.39 のようだ。
例によって GNOME プロジェクト作だから合わせたかったのかな。
vte291-devel-0.39.90-1.fc22.armv7hl.rpm | RPM Info | koji

Fedora にはしっかり gir で入っていますね。
多分 gnome-terminal 採用のディストリなら大抵あると思う。
2.91 は見当たらないので 0.39 のドキュメントを見ればいいだろう。
VTE Reference Manual: VTE Reference Manual

参考が欲しいのでサンプルコードを探す。

c – gtk+ vte scrollback not working – Stack Overflow
python – How to add vte terminal widget in GTK3? – Ask Ubuntu

C や Python から使う方法は海外でアッサリ見つかった。
日本語情報は今のところ皆無、いつものことだ。

しかし古いようで vte_terminal_fork_command 関数は 2.91 で使えない。
どうやら現行は vte_terminal_spawn_sync 関数を使うようだ。

ということで。
早速 Python バインディングにて書いてみよう。

#!/usr/bin/env python3

from gi.repository import Gtk, Vte, GLib

class VteWindow(Gtk.Window):
    """
        Vte Sample (v2.91)
    """
    def __init__(self):
        Gtk.Window.__init__(self)
        # Create a virtual terminal 
        terminal = Vte.Terminal.new()
        # Exit of Ctrl+D
        terminal.connect("child-exited", self.on_terminal_child_exited)
        # Sync
        terminal.spawn_sync(
                Vte.PtyFlags.DEFAULT,
                GLib.get_home_dir(),
                #["/bin/sh"], @ List of Execute Command
                ["/usr/bin/python3"],
                None,
                GLib.SpawnFlags.DO_NOT_REAP_CHILD,
                None,
                None,
                None)
        self.add(terminal)
        self.set_title("Virtual Terminal")
        self.connect("delete-event", Gtk.main_quit)
        self.show_all()

    def on_terminal_child_exited(self, vteterminal, status):
        Gtk.main_quit()

VteWindow()
Gtk.main()

spawn_sync の引数については devhelp で詳しく。
三番目引数を sh や perl に変更すれば当然それらが起動する。
それと上記は起動したコマンドの終了を検知して自分も終了させている。
後はお好みで弄ってみてください。
今後バージョンで変わると思うので 2.91 と念を押して。

/bin/sh で起動してソコから Python を始めるとかも可能。
Ctrl+D で Python を終了すると sh に戻る、マジで普通の端末。

しかし自分で試して驚いた、こんなにアッサリ実装できるとは。
自分好みに拡張したオリジナル端末を作るだけでも面白そう。
ただ一言、日本語の情報がまったく無いのはキビシイze!

テキストエディタの色分け表示については Gedit は超強力です。
実はコレ Gedit ではなく GtkSourceView 自体の機能だったりする。
下記ディレクトリに定義 XML ファイルがある時点で解るだろうけど。

/usr/share/gtksourceview-3.0/language-specs

プログラミングは基本や計算ばかりじゃ面白くないよね。
やはり GUI のほうが楽しいですよね。
今回は GtkSourceView でこの色分け機能を使う方法でも。

GtkLanguageManager を使います、驚くほど簡単です。
読み込むファイルを用意するのが面倒なので自分の Python コードを。

#!/usr/bin/env python3
  
import sys
from gi.repository import Gtk, GLib, Gio, GtkSource, Pango

# My src
FILENAME = __file__
  
class ColorLang(Gtk.Window):
    """
        GtkSourceLanguageManager Sample
    """
    def __init__(self):
        Gtk.Window.__init__(self)
        #
        # GtkSourceView
        self.view = GtkSource.View()
        self.view.set_show_line_numbers(True)
        # Set Monospace Font
        font_desc = Pango.font_description_from_string("Monospace 10")
        self.view.override_font(font_desc)
        #
        # LanguageManager
        manager = GtkSource.LanguageManager.new()
        lang = manager.guess_language(FILENAME)
        """ or ContentType
        contype, result = Gio.content_type_guess(FILENAME)
        lang = manager.guess_language(None, contype)
        """
        buf = self.view.get_buffer()
        buf.set_language(lang)
        # Read
        with open(FILENAME) as f:
            s = f.read()
            buf.set_text(s)
        sw = Gtk.ScrolledWindow()
        sw.add(self.view)
        # append the filename and ContentType
        hbar = Gtk.HeaderBar()
        hbar.set_title(GLib.path_get_basename(FILENAME))
        hbar.set_subtitle(Gio.content_type_guess(FILENAME)[0])
        hbar.set_show_close_button(True)
        self.set_titlebar(hbar)
        self.add(sw)
        self.resize(400, 400)
        self.connect("delete-event", Gtk.main_quit)
        self.show_all()

ColorLang()
Gtk.main()

ファイル名か ContentType を指定すると推測して定義ファイルから探し当てる。
ソレを set_language で突っ込む、マジでこれだけ。

でも g_content_type_guess だと ContentType は拡張子依存みたい。
本気で拡張子否依存にするなら自力で取得する必要有り、のようです。

で、まあ当然のように Gedit とまったく同じ色分けになりました。
これじゃつまんない、自分で定義したいという人は定義 XML を作って
gtk_source_language_manager_set_search_path でセットする。

GtkSourceView 3 Reference Manual: GtkSourceLanguageManager

しかし language という名ではつい gettext 関連と思ってしまいます。
いや、筆者が今までそう思い違いしていたというオチだyo!

最近 GUI をやっていない。
コマンドラインばかりじゃつまんない。

で、実用的かもしれないディレクトリ内容の変更を監視し出力するウインドウを。
いや、随分前にやって上手くいかなかったのだが原因がやっと解ったので。
GUI は C では面倒すぎなので Python で。

#!/usr/bin/env python3

"""
    $HOME を監視するサンプル
"""

from gi.repository import Gtk, Gio, GLib

class Win(Gtk.Window):
    def __init__(self):
        Gtk.Window.__init__(self)
        self.view = Gtk.TextView()
        self.view.set_editable(False)
        sw = Gtk.ScrolledWindow()
        sw.add(self.view)
        self.add(sw)
        #
        # ファイル監視も同様、現在存在していない場合でも監視してくれる
        #f = Gio.File.new_for_path(GLib.get_home_dir() + "/test.txt")
        f = Gio.File.new_for_path(GLib.get_home_dir())
        #
        # GFileMonitor は他メソッドで使わなくても必ずアトリビュートにする
        # しないと __init__ 抜けた時点で破棄されてしまう
        #
        self.monitor = f.monitor(Gio.FileMonitorFlags.NONE)
        #self.monitor = f.monitor(Gio.FileMonitorFlags.SEND_MOVED)
        self.monitor.connect("changed", self.on_monitor)
        # self
        self.connect("delete-event", Gtk.main_quit)
        self.resize(300, 200)
        self.show_all()

    def on_monitor(self, monitor, f, other_f, event):
        """
            ディレクトリ監視は隠しファイルの変更も感知します
            ( /.bash.history 等 )
        """
        buf = self.view.get_buffer()
        s = f.get_path()
        if event == Gio.FileMonitorEvent.CHANGED:
            # ファイルの内容が変更された時
            buf.insert_at_cursor("CHANGED: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.CHANGES_DONE_HINT:
            # ファイルの情報が変更された時
            buf.insert_at_cursor("CHANGES_DONE_HINT: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.DELETED:
            # 削除（リネーム、移動含む）された時
            buf.insert_at_cursor("DERETED: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.CREATED:
            # 作成（リネーム、移動含む）された時
            buf.insert_at_cursor("CREATED: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.ATTRIBUTE_CHANGED:
            # パーミッションが変わった時
            buf.insert_at_cursor("ATTRIBUTE_CHANGED: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.PRE_UNMOUNT:
            # Gio.FileMonitorFlags.WATCH_MOUNTS 指定時のみ
            buf.insert_at_cursor("PRE_UNMOUNT: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.UNMOUNTED:
            # Gio.FileMonitorFlags.WATCH_MOUNTS 指定時のみ
            buf.insert_at_cursor("UNMOUNTED: {0}\n".format(s))
        elif event == Gio.FileMonitorEvent.MOVED:
            # Gio.FileMonitorFlags.SEND_MOVED 指定時のみ
            buf.insert_at_cursor("MOVED: {0}\n".format(s))
        # Gio.FileMonitorFlags.WATCH_MOUNTS 指定時に、あれ？
        if other_f:
            buf.insert_at_cursor("other: {0}\n".format(f.get_path()))

Win()
Gtk.main()

で、結論。
GFileMonitor のインスタンスは self のアトリビュートにする必要がある。

今迄は他メソッドから参照する必要が無いものは self にはくっつけなかった。
すると全然シグナルが飛んでこない、バグだとずっと思っていた。
しかし今日 self を付けただけであら不思議。

よく考えたらガベージコレクションだから当然である。
GUI 部品なら親ウインドウにくっついているのだから何かしら参照がある。
しかしメインループで動いているだけの部品はどこからも参照されていない。
結果ガベージコレクタの破棄対象に、何かで参照しないといけない。

PyGObject を作っている皆様、コッソリ疑っていてごめんなさい。

もしかしてアレも、と思い付くのがチラホラ。

しかしファイル監視は存在しないファイルを指定してもいいんだね。
新規作成で CREATE と CHANGES_DONE_HINT のシグナルが飛んでくる。
CHANGES_DONE_HINT はちょっとうっとうしい。

それと $HOME を監視したまま gnome-terminal を終了すると解るけど。
~/.bash_history とかの隠しファイルへの書き出しにも反応する。
コレはハンドラ側で見分け等をする、でいいのかな。

SEND_MOVED 指定も試してみた、なるほどそうなるか。
ディレクトリ移動だと結局 DELETED になる、リネームしか意味が無い。
しかし *other_file 引数は何だろう？

それよりリネーム後のファイル名が得られないと困るんだが。
バ…いやいや、コレも手段が悪いだけなのかもしれないし。
というか、使い道が思いつかないしどうでもいいかなと。

おまけで、GDataOutputStream での上書き保存のみ。

#!/usr/bin/env python3
 
from gi.repository import Gio

f = Gio.file_new_for_path("output_stream.txt")
fstream = f.replace("", False, Gio.FileCreateFlags.NONE)
dstream = Gio.DataOutputStream.new(fstream)
dstream.put_string("BKB BKB")
fstream.close()

OutputStream ってこんなことをやっていたの！
当然の話だが Gedit の上書き保存もまったく同じ。
いやいや、監視してみると色々面白いことが解るNE!