Tag Archive for Python

12 3月 2014
Linux • Python • 技術

libwnck (ウィンドウマネージャ操作ライブラリ)

サイネージというほどのものではないけど、それ的なもののソフトウェアをつくるために、X上で外部プロセスのウィンドウをいじってどうにかするみたいなのを探した。

いろいろ当り最終的にlibwnckを見つけた。ウィンドウマネージャの操作ライブラリ。Pythonバインディングのpython-libwnckもある。

import wnck, gtk
screen = wnck.screen_get_default()
screen.force_update()
windows = screen.get_windows()

これでウィンドウリスト (WnckWindowのリスト) が得られる。これに対して、

w = windows[0]
w.get_name() # Window Name
w.get_application().get_name() # Application Name
w.get.get_class_group().get_name() # Class Name

こんな感じで情報を取得し、

w.set_geometry(wnck.WINDOW_GRAVITY_CURRENT, wnck.WINDOW_CHANGE_X | wnck.WINDOW_CHANGE_Y, 100,100,0,0)
w.set_title("新しいタイトル")
gdk_w = gtk.gdk.window_foreign_new(w.get_xid())
gdk_w.set_decorations(0) # デコレーションの削除
# 反映させる
gtk.gdk.window_process_all_updates()
gtk.gdk.flush()

こんな感じにウィンドウが操作できる。

uWSGIと併用時のエラー

ちなみに、python-wnckを使用するWebアプリをuwsgi上で動かしたらこんな感じのエラーが出てしばらくこまった。

172.29.4.50 - - [12/Mar/2014:22:59:39] "GET /info HTTP/1.1" 200 4 "" "Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0"
[pid: 15271|app: 0|req: 6/6] *.*.*.* () {32 vars in 508 bytes} [Wed Mar 12 22:59:39 2014] GET /set_center/info => generated 4 bytes in 6 msecs (HTTP/1.1 200) 4 headers in 138 bytes (1 switches on core 0)
Wed Mar 12 22:59:41 2014 - !!! uWSGI process 15270 got Segmentation Fault !!!
Wed Mar 12 22:59:41 2014 - *** backtrace of 15270 ***
Wed Mar 12 22:59:41 2014 - uwsgi(uwsgi_backtrace+0x25) [0x431ea5]
Wed Mar 12 22:59:41 2014 - uwsgi(uwsgi_segfault+0x21) [0x431f81]
Wed Mar 12 22:59:41 2014 - /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7fa477a794f0]
Wed Mar 12 22:59:41 2014 - /usr/lib/libstartup-notification-1.so.0(sn_xcb_display_new+0x109) [0x7fa47201fa89]
Wed Mar 12 22:59:41 2014 - /usr/lib/libstartup-notification-1.so.0(sn_display_new+0x2d) [0x7fa47201fb3d]
Wed Mar 12 22:59:41 2014 - /usr/lib/libwnck-1.so.22(wnck_screen_get+0x117) [0x7fa474660617]
Wed Mar 12 22:59:41 2014 - /usr/lib/python2.7/dist-packages/gtk-2.0/wnck.so(+0xa809) [0x7fa4748ac809]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x56fd) [0x7fa47521d04d]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7fa475304647]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyInstance_New+0x7b) [0x7fa4752ec58b]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6917) [0x7fa475274917]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x11c1ac) [0x7fa4752ea1ac]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2a57) [0x7fa47521a3a7]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x848) [0x7fa47521e2e8]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xa6806) [0x7fa475274806]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0x184810) [0x7fa475352810]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(+0xcbdf6) [0x7fa475299df6]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x4e) [0x7fa475303d3e]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x27dd) [0x7fa47521a12d]
Wed Mar 12 22:59:41 2014 - /usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5b7b) [0x7fa47521d4cb]
Wed Mar 12 22:59:41 2014 - *** end of backtrace ***
Wed Mar 12 22:59:41 2014 - DAMN ! worker 2 (pid: 15270) died :( trying respawn ...
Wed Mar 12 22:59:41 2014 - Respawned uWSGI worker 2 (new pid: 15296)

最初はなんかcherrypyかuWSGIのスレッドが有効になっちゃってて変な事がおこっているかと思ったけど、どうやらPython初期化後にforkしてからGTKとかX11のAPI使っているから発生しているよう。(断定的に調べていないので違うかも。)

uWSGIのlazyオプションを指定するとfork後の初期化になるようなので、それで改善した。

| コメントは受け付けていません。 | Tags: , , , , ,
31 1月 2013
Gentoo • 技術

Gentoo-Prefix上でMercurialのSSL関連エラー

Gentoo-Prefix@MacでMercurial使おうとしたら謎のエラー。

user@hogehoge ~/projects $ hg clone https://***.com/***
abort: Python SSL support not found

Python用のSSLが入っていないようだ。

とりあえずpythonをemerge -avしてみる。

taka@mobuild ~/projects $ emerge -av python

 * IMPORTANT: 3 news items need reading for repository 'gentoo_prefix'.
 * Use eselect news to read news items.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-lang/python-3.3.0:3.3::gentoo [3.3.0:3.3::gentoo_prefix] USE="ipv6 ncurses readline sqlite* ssl threads xml -build -doc -examples -gdbm -tk -wininst" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

おやおや、SSLフラグは入っている。おかしいなぁ。

と思ったらPython 3をemergeしていた。スロット分けされている2.7の方をemerge -avしてみると・・・

taka@mobuild ~/projects $ emerge -av "<=dev-lang/python-3.0"

 * IMPORTANT: 3 news items need reading for repository 'gentoo_prefix'.
 * Use eselect news to read news items.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-lang/python-2.7.3-r2:2.7::gentoo [2.7.3-r2:2.7::gentoo_prefix] USE="aqua ipv6* ncurses readline* sqlite* ssl* threads (wide-unicode) xml (-berkdb) -build -doc -examples -gdbm -tk -wininst" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

ビンゴ。sslフラグが入ってませんでした。

Gentoo Prefixはデフォルトではsslフラグ入って無いんですね。Python 3のほうは入ってるのに。まぁなんか事情があるんでしょう。

とりあえず無事にhg cloneできるようになりましたとさ。

 

| コメントは受け付けていません。 | Tags: , , , , , , , ,
08 1月 2013
Gentoo • Linux

ibus-anthy

ひさびさにemerge worldをしたあと、例のごとくいろいろと不具合が起こるわけですが。

今回は日本語入力にそれなりにハマる。これはもう英語で過ごせというお告げか。

さすがにそれは無理なのでとりあえず調べてみる。
ibus-daemonのログをとってみる。起動したままibusのバックエンドをAnthyとそうじゃないやつで切り替えてみる。

$ killall ibus-daemon
$ ibus-daemon -v
IBUS-Message: 22:06:40.512056: Engine xkb:us:altgr-intl:eng is already registered by other component
Traceback (most recent call last):
  File "/usr/share/ibus-anthy/engine/main.py", line 26, in <module>
    import ibus
ImportError: No module named ibus

どうやらibusのPythonモジュール読み込み失敗しているらしい。とりあえずemergeしてみる。

# emerge -av ibus
 * IMPORTANT: 8 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] app-i18n/ibus-1.4.99.20121006  USE="X dconf gconf gtk gtk3 introspection nls python -deprecated {-test} -vala" 0 kB

pythonは入ってるから大丈夫なはずなんだけどなぁ、と思ったけどふと「-deprecated」が怪しく感じてonにしてemergeした。
そしたら無事ibus-anthy自体は動くようになった。
ここからさらに。なぜかGnome 3.6での「Zenkaku_Hankaku」キーがショートカットとして使えない。
いろいろと探すと、VineSeedにそれらしいパッチがあった。

http://riksun.riken.go.jp/archives/Linux/vine/VineSeed/SRPMS.main/gnome-settings-daemon-3.6.3-1vl7.src.rpm

こんなかにある「gnome-settings-daemon-3.6.3-input-source-switch-zenkaku-hankaku.patch」を当てるverのebuildを作成してre-emergeしてみたが、ダメだった。

仕方ないので、xbindkeysを使用して無理やり解決。

まず切り替えスクリプトの用意。
(/usr/sunaga-lab/bin/switch-ibus-method)

#!/bin/bash

ENGINE=`ibus engine`
if [ s$ENGINE != "santhy" ]; then
	ENGINE="anthy"
else
	ENGINE="xkb:jp::jpn"
fi
ibus engine $ENGINE

次にxbindkeysの設定。

$ emerge xbindkeys
   ...
$ cat .xbindkeysrc
"/usr/sunaga-lab/bin/switch-ibus-method"
  Mod2 + Zenkaku_Hankaku

あとは.xprofileにxbindkeysを追加して終わり。

とりあえず使えるようになった。初回だけちょっともたつくけど。仕方ない。

| コメントは受け付けていません。 | Tags: , , , , ,
28 5月 2012
技術

電灯のインターネット制御

P1020144

※漏電や火災、落下などの危険性があるので、よいこはマネしないでねっ！

まえまえからやってみたいなぁと思いつつ結局ずーっとできずにいた。しかしとうとうやってみることに。まぁなんか、インターネット制御とかっていってますけど、やりたいことはソフトウェア制御ですよね。とりあえずはPythonからプログラム制御できるところまでやった。

まずは電灯に電子制御のスイッチを入れるにはどうすればいいか考える。ホームセンター探って、使えそうなパーツを物色してたら↓みたいなものがあった。これ結構便利だった。

P1020132

これの内部は物理スイッチになってるので、それをOFFにした状態で、リレーなりをはさめばOK。ということで穴を作ってSSR (リレー的なもの) をつけた。これで黄色いコネクタからの入力信号で制御できる。

P1020133

しかしこのSSRは40A対応のもので、ややオーバースペック。電灯一個精々100W程度なので、数アンペアぐらいのものがあればよかった。

実際に電灯につけてみたの図。

P1020150

そして制御部本体。今回は秋月のH8/3069Fネット対応ボードを使いました。 LANでつながっています。

P1020144

黄色コネクタがそれぞれ出力信号線、白が電源線 (5VとGND)、黒が入力信号線という感じになってます。H8上のプログラムは自分で適当に書いたプログラムです。ただひたすらLANと通信しながらI/O制御してくれます。

いちいちPCから操作するようにすると面倒過ぎるので、もちろんスイッチもつけました。

P1020154

シングル押下でそこの電気のみ、ダブルクリック的に押すと部屋の全部の電灯が消えるようにした。

と、まぁこんな感じで部屋の電灯がソフトウェア制御できるようになったのである。ということでPythonで適当なコントローラをつくった。

scr2

今後は電灯以外も制御したいですね。例えばあれとか、あれとか、後はあれとか。

あとはソフトウェアで点灯時間の管理とか可視化とかをすれば、なんか節電云々で流行に乗れてる感じなんですかね。いやなんか制御で余計に電気食ってるだろって話も。

・・・えっ？なんだって？だから新規性なんて一切ないってば。こんなの完全に使い古されている。

| コメントは受け付けていません。 | Tags: , , ,