Tag Archives: gnome

Permalink to single post

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後の初期化になるようなので、それで改善した。
Permalink to single post by Linux, Python, 技術 ,
Permalink to single post

GDM-3.8.4-r2@GentooでOh no something has gone wrong!

いろいろとパッケージアップデートしたらGDMで「Oh no」画面が出てログインできずに。 とりあえずログを見る。 
# cat /var/log/Xorg.0.log
・・・
[   184.547] (II) NOUVEAU(0): [XvMC] Extension initialized.
[   184.547] (==) NOUVEAU(0): DPMS enabled
[   184.547] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   184.547] (--) RandR disabled
[   184.550] (EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (libLLVM-3.1.so: cannot open shared object file: No such file or directory)
[   184.550] (EE) AIGLX: reverting to software rendering
[   184.550] (II) AIGLX: Screen 0 is not DRI capable
[   184.550] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (libLLVM-3.1.so: cannot open shared object file: No such file or directory)
[   184.550] (EE) GLX: could not load software renderer
[   184.550] (II) GLX: no usable GL providers found for screen 0
[   184.553] (II) NOUVEAU(0): NVEnterVT is called.
[   184.580] (II) NOUVEAU(0): Setting screen physical size to 677 x 381
[   184.580] resize called 2560 1440
・・・
どうやらlibLLVM-3.1.soの読み込みに失敗している模様。まずそれが存在しているか、またldconfigで検索できるか確認する。 
# locate libLLVM-3.1.so
/usr/lib32/llvm/libLLVM-3.1.so
/usr/lib64/llvm/libLLVM-3.1.so
# ldconfig -p | grep libLLVM-3.1
(※なし)
#
存在はしているようだけど、ldconfigで検索できていないっぽい。
とりあえずld.so.confに追加する。(今回は /etc/ld.so.conf.d/05llvm.conf として追加した)
追加したあとにldconfigも忘れずに。 
# cat /etc/ld.so.conf.d/05llvm.conf
/usr/lib32/llvm
/usr/lib64/llvm
# ldconfig
これでgdmをリスタートしたら直った。 
# systemctl restart gdm
めでたし。 これはパッケージか何かのバグだろうか。
それとも何か設定が違っていたのだろうか。。。
Permalink to single post by Gentoo, Linux
Permalink to single post

[Arch Linux] Xでキーボードやマウスでの入力ができない

Arch Linuxにxorgとgnomeをインストールして、startxをしてみたところ、マウスやキーボードの入力を一切受け付けない、という現象に一瞬悩まされた。

xorg.confを古い環境からコピーしてきていたので、入力デバイスの設定がかかれていた。
evdevに認識させるためには、どうやらその設定が邪魔になるっぽいのでとりあえず削除。

しかし動かない。

いろいろ調べた挙句、HAL(Hardware Abstraction Layer)をインストールしたら解決。

・・・それにしても自分無知すぎる。

参考情報: Arch Linux Wiki: HAL

Permalink to single post by コメントをどうぞ Arch Linux, Linux , , , , , , , , , , , ,
Permalink to single post

gnome 2.22.2

久々にemerge world中

前にgnomeが2.20→2.22になって、依存関係とかやたら複雑だったので
後回しにしてました。

依存関係でいくつか古いモノを削除しながらやった

あとfirefoxがどうも2系にダウングレードされるから調べたらyelpが原因だったらしい。
ebuildを見たらxulrunnerをUSEフラグに入れれば大丈夫らしい。

何とか終わるといいな。。。

ていうか更新146pkgとか大杉

Permalink to single post by コメントをどうぞ Gentoo, 技術 , , , , , ,