何を今頃気になった。
前記事のように C/C++ という特定言語での GUI デバッガは Nemiver で賄える。
っって Vala みたいな別言語へのジェネレーターだとどうなるんじゃ？
gdb 直使いな人も気になる所かも。
経験値が多いなら出力された C ソースへリンクと予測できる。
でもやってみなきゃ断言できないな、試すとしよう。
valadoc.org がしばらく見ない内に色々進化していた。
ソコらはもっと詳しい人にまかせてと。
このページにある vala ソースを gedit にこんな外部ツールで Nemiver に渡してみる。
全然面白くない結果になってしまった。
Vala から使っても生成された C ソースへのリンクになるってことね。
コレだと Vala で書いているソースコードの直接的デバッグにならないんですが。
Vala という超マイナーな言語で書ける人という時点で（以下略
現状ならソレでいいけどさ。
未来なんて誰も断言できないから。
スマートフォンがココまで普及すると予測できた人なんているのか？
Gedit の外部ツールは便利だが自分で設定したショートカットキーを忘れる。
簡単なキーに割付けたくてもできないことも多いし。
特に C ビルドで GLib や Nemiver の利用を振り分けしたい場合とか。
本格的に作るものなら当然 Makefile を用意するので問題ない。
けれどチビッと試したいコードのためにそんな面倒したくないですよ。
プログラミング関連は全部 F5 キーだけでまかなえないものか。
そうだ、’GLib.h’ という文字列が含まれているかどうかで振り分けできないか？
ものは試しだ、こんなツールを作ってみた。
#!/bin/sh
PYTHON="text/x-python"
GJS="application/javascript"
HTML="text/html"
BASH="application/x-shellscript"
VALA="text/x-vala"
CSRC="text/x-csrc"
echo @MIMEtype $GEDIT_CURRENT_DOCUMENT_TYPE
if [ $GEDIT_CURRENT_DOCUMENT_TYPE = $PYTHON ]; then
python3 $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $GJS ]; then
gjs $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $HTML ]; then
google-chrome $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $BASH ]; then
sh $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $VALA ]; then
vala $GEDIT_CURRENT_DOCUMENT_PATH
elif [ $GEDIT_CURRENT_DOCUMENT_TYPE = $CSRC ]; then
src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
case $src in
*gtk.h*)
echo "Gtk Build"
gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0` ;;
*glib.h*)
echo "GLib Build"
gcc $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0` ;;
*)
echo "Gcc Build"
gcc $GEDIT_CURRENT_DOCUMENT_PATH ;;
esac
else
echo Non Support File
fi
全部読み込んで case 文にしたのは inclide が一行目とは限らないので。
ぶっちゃけ効率ガン無視だがチョコッとビルド用途なのでいいよね。
ついでに Nemiver 用も
#!/bin/sh
src=`cat $GEDIT_CURRENT_DOCUMENT_PATH`
case $src in
*gtk.h*)
echo "Gtk Build"
gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs gtk+-3.0`
if test $? -eq 0; then
nemiver debug
fi
;;
*glib.h*)
echo "GLib Build"
gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH `pkg-config --cflags --libs glib-2.0`
if test $? -eq 0; then
nemiver debug
fi
;;
*)
echo "Gcc Build"
gcc -g -o debug $GEDIT_CURRENT_DOCUMENT_PATH
if test $? -eq 0; then
nemiver debug
fi
;;
esac
これで F5 を押すだけで筆者が使う言語は全部まかなえるぜ。
あと PHP があるけどこれは Apache 経由でしか使わないので。
いや、本当はモードごとに書いたほうがいいのだろうけどね。
ツールが一つで自力振り分けのほうが筆者はメンテが楽なだけ。
GFile で g_file_set_display_name すると普通にリネームするんだね。
#!/usr/bin/env python3
import sys
from gi.repository import Gio
f = Gio.File.new_for_path(sys.argv[1])
f.set_display_name("nae_yuki.jpg")
存在しないファイルでこの関数を使うと「存在しないよ！」とエラー。
こうなってしまったので気が付いただけですが。
なるほど、メモリ上のデータではなくファイルポインタなのね。
ちなみに、これを利用してリネームツールをとか考えたけど。
mvにサヨナラ！renameコマンドのイケメンぶりが半端ない | techiela
rename コマンドってこんなに便利だったのか…
mv しか使ったことがなかったYO!
あれ、今まで Widget ギャラリーページなんてあったかな？
Widget Gallery: GTK+ 3 Reference Manual
Widget 画像をクリックするとそのページにジャンプできる。
これは微妙に便利。
てか GtkPlacesSidebar というものが 3.10 時からあったのか。
このページのおかげで今頃知ったぞ！
しかしどう見ても Nautilus の左ペインそのまんまだが何だこれ。
試してみるのが一番速いな、ということで。
#!/usr/bin/env python3
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk, Gio, GLib
class SidebarTest(Gtk.Window):
"""
Nautilus Sidebar
"""
def __init__(self):
Gtk.Window.__init__(self)
# GtkPlacesSidebar
sidebar = Gtk.PlacesSidebar.new()
# Select Documents Directory
doc = GLib.get_user_special_dir(GLib.UserDirectory.DIRECTORY_DOCUMENTS)
f = Gio.File.new_for_path(doc)
sidebar.set_location(f)
# Add Shortcut
f = Gio.File.new_for_path("/home/sasakima-nao/doc/html")
if f.query_exists():
sidebar.add_shortcut(f)
# Signal
sidebar.connect("open-location", self.on_sidebar_open_location)
# etc...
#sidebar.set_show_recent(False)
#sidebar.set_show_other_locations(True)
#sidebar.set_show_enter_location(True)
self.add(sidebar)
self.show_all()
def do_delete_event(self, event):
Gtk.main_quit()
def on_sidebar_open_location(self, sidebar, location, open_flags):
"""
location @ GFile
"""
uri = location.get_uri()
self.set_title(uri)
SidebarTest()
Gtk.main()
外付け USB HDD を繋いだら普通に認識までしてくれたぞ。
ブックマークも同じ、本当に Nautilus の左ペインそのまんまじゃないか。
でも何故か 3.18 で「他の場所」部に移動した root が表示される。
ショートカットの追加も可能、ただし実在している必要があるようだ。
一部は非表示にもできるけど基本 Nautilus と同じってことみたい。
うーん、これってどういう場面で使うのだろう？
外部機器の接続監視やサーバーログインを自前でやる必要が無いのはいいが。
オリジナルな「開くダイアログ」以外の使い道が考え付かない DESU。
以前 GtkFlowBox の使い道が解らないとか書いた。
GtkFlowBox | PaePoi
よく考えると Totem のサムネイルに使われていたりする。
そうか、GtkIconView の代わりみたいなものかな。
つまり GtkScrollView を噛ませて画像表示なんかで便利かも。
試しにディレクトリ画像サムネイルを作ってみよう。
#!/usr/bin/env python3
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk, GLib, Gio, GdkPixbuf
NAE_PATH = "/home/sasakima-nao/pic/game/gf/nae_yuki_ssr"
class FlowBoxTest(Gtk.Window):
"""
Easy GtkIconView
"""
def __init__(self):
Gtk.Window.__init__(self)
# GtkFlowBox
flowbox = Gtk.FlowBox.new()
flowbox.set_valign(Gtk.Align.START)
self.get_all_picture(flowbox)
#flowbox.set_selection_mode(Gtk.SelectionMode.MULTIPLE)
scroll = Gtk.ScrolledWindow.new()
scroll.add(flowbox)
# self
self.index = 0
self.add(scroll)
self.resize(400, 300)
self.show_all()
def do_delete_event(self, event):
Gtk.main_quit()
def get_all_picture(self, flowbox):
"""
Thumbnail JPEG File
"""
d = Gio.file_new_for_path(NAE_PATH);
# Get GFileEnumerator
enum = d.enumerate_children(
Gio.FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE,
Gio.FileQueryInfoFlags.NONE)
for info in enum:
# info is GFileInfo
content_type = info.get_content_type()
if content_type == "image/jpeg":
name = info.get_name()
fullpath = "{0}/{1}".format(NAE_PATH, name)
thumbnail = GdkPixbuf.Pixbuf.new_from_file_at_scale(fullpath, 100, 100, True)
image = Gtk.Image.new_from_pixbuf(thumbnail)
flowbox.add(image)
FlowBoxTest()
Gtk.main()
GtkIconView より圧倒的に簡単だった。
専用のセルレンダラは不要で Widget をそのまま使える。
便利というより簡単で判り易いという使い道みたい。
いや、どんな Widget でも入れられるメリットもある。
でもデータの入れ替えが頻繁な場合は逆に面倒臭くなるなと。
「ドキュメント／ビューアーキテクチャ」とはいったい何だったのか。
ってデータをほとんど入れ替えないならコッチのほうがいいよね。
ということで、優木苗(cv日高里菜)は本当にカワイイです（gf は放置中