Mandriva GNOME 版で Qt3 アプリのメニュー

Mandriva 2010.0 GNOME 版で Opera を使うとメニューがおかしい。
メニューがボタンのようになっていてクリックしないとサブメニューが出ない。
Opera は Qt3 製だ、これは qtconfig を使って設定を変更するしかなさそうだ。
しかしソフトウエア管理からは Qt4 用しか見つからない。

conf01

qtconfig_qt4

/usr/lib/qt4/bin/qtconfig

に入る、インストールして端末から qtconfig を実行するとコレが起動する。
ちなみに設定ファイルは以下

~/.config/Trollteck.conf

実は Opera を入れると Qt3 用 qtconfig は入るようだ。

/usr/lib/qt3/bin/qtconfig

を実行すれば Qt3 用 qtconfig が起動できる、設定は以下のようだ。

~/.qt/qtrc

qtconfig_qt3

デフォルトでは GUI Style が Motif になっている。
コレを Windows に変更、てか KDE 版は Windows になっている。
これでメニューがボタンみたいで使いにくい不満は解決できる。

mandriva_opera_menu

でも Opera は大半が独自描写なのでメニューくらいしかコレで変更できない…

日本語入力ができなくなる場合があるのは Ubuntu で使っていた時と同じか。
一度右クリックメニューを出してしまえば入力できるようになるんだが何故だろう。
コレで XIM Input Style を変更しても同じ結果、KDE 版でさえ同じ結果なのよね。

Linux Opera Starting Check in ps command

せっかく Y901x を Mandriva KDE に対応させたのだから SeeMe もやりたい。
問題は Python の wnck モジュールだ、KDE 版にはデフォルトで入っていない。

seeme102_kde

動画プレイヤーならともかくコイツはモジュールを入れてくれにしたくない。

基本的に私は得に何もインストールさせないで使えるものを作るのがポリシー。
Windows で .NET は IronPython しかやらなくなったのはそのポリシーから。
だって 7 や Vista なら .NET 自体は最初からあるし SDK もコンパイラも必要無い。

ということで wnck を使わずに Opera が起動しているかどうか判別する方法は…

まてよ、Linux は Windows とは違ってコマンドライン OS に GUI が被さっているだけだ。
Window を探して名前を調べなくてもコマンドからチェックできるんじゃないの？
探せば他も見つかるだろうけど単純に ps コマンドの出力から調べられるかも。

#!/usr/bin/env python
#-*- coding:utf-8 -*-

"""
    opera_init_check.py
    Find in "ps ax" command output
"""

import commands

r = commands.getoutput("ps ax")
if "/usr/lib/opera/opera" in r:
    print "starting Opera"
else:
    print "not starting Opera"

こんな手抜きバリバリなコードでアッサリ判別できてしまった。
Linux は多分この位置にしか Opera 本体が入らないだろうからイケそうだ。
Windows 的な考え方がまだ抜けていないみたいだな私は。

この判別方法に書き換えて VirtualBox 上の KDE 版で動かしてみよう。

seeme103_kde

問題なく起動できるようになった、Opera の起動判別もバッチリ。

ということでバグ修正を含めて SeeMe for Linux 1.0.3 公開。
ただダウンロード数が強烈に寂しいんだがコイツ…

Python property Decorator

INotifyPropertyChanged and databinding in IronPython WPF

Wonderful!
私が書いた下記を「理想的じゃネェ」と断言しているだけある。

ぱぇぽぃ２ ? Blog Archive ? WPF ListView DataBinding for IronPython

OnPropertyChanged を先に呼ぶことになるのが気になるけど…
問題なく動くから多分 OnPropertyChanged は Queue に入るのだろう。
組み込み以外で Decorator の実用的な使い方を初めて見た。

PyGtk 製 Y901x にて

@dbus.service.method("org.y901x.Interface1")
def set_uri(self, uri):
	###

と使っているが何故これで D-Bus 経由で別インスタンスから関数が呼べるのか実は知らない…
自身で関数を呼んでいるのではないし、もっと調べると面白い使い方ができそうだ。

とにかく良いものを見つけた、こんな Blog をやっているといいことあるよ。
てかこの Blog へのリンク元を見ると海外からばかり、co.uk とかもあるし。
日本の Python 屋って非実用的コードばかり書いている人が多いですからね。

Y901x 0.2.0 release

Y901x 0.2.0 公開、トップページから。

beta からの変更点、せっかくだから Mandriva KDE 版にも対応。
Dolphin 及び他からのファイルドロップに対応するためにこうした。

def on_drag_data_received(self, widget, context, x, y, selection_data, info, time):
    # D&D FilenNmes split CRLF or LF
    if "\r\n" in selection_data.data:
        drop = selection_data.data.split("\r\n")[0]
    else:
        drop = selection_data.data.split("\n")[0]
    if "//" in drop:
        self.set_uri(drop)
    else:
        self.set_uri("file://" + drop)

Nautilus は CRLF 区切りで file:// の URI で送られてくる。
Dolphin は LF 区切りだ、後は file:// になっているかで振り分ければいいだろう。
これで多分どんな場合でもドロップに対応できる…かもしれない。

それより Mandriva には install というコマンドがあるお！
./ を付けてでは…しかたがないのでインストールスクリプトは名前を変更！

KDE での D-Bus については dbus-python を入れてくれでいっちゃえ！
試しに入れてみたら動いたからそれでいいや。

GtkAspectFrame の件はかなり前に Blog に書いたのに公開版はまだやっていなかった…

てなわけで思ったより差があるので 0.2.0 とマイナーバージョンアップということにする。
しかし気がつくとトップページの更新を 1 か月以上忘れていた、反省。
やっぱり Blog というか CMS のほうが楽なのでコッチばかり更新になってしまう。

Visual Studio x64 build test

時間が掛かりすぎるので休日にしかできない仮想 Vista 構築の続き。

前回はただ OS のインストールだけで終わったので Vista に SP を当てないと。
Windows Update では自動で当ててくれないのが忌々しい。

sp1 を当てないと sp2 が当てられないのね、面倒すぎ。
4 時間使ってやっと両方が終わったところで IE8 への自動更新が出る。
一度にやってくれよ、何回再起動させればいいのやら…

やっと Visual Studio をインストールする環境が揃う。
インストール DVD を立ち上げ今回は忘れずに「すべて」を選択。

vs_all

やっぱり一時間半掛かって、んで一時間使って MSDN ヘルプを入れて…
そして sp1 にするのにまた一時間半と、更に Update が掛かって…
そして今回も丸々一日使うはめになったとさ。

あーもうなるべくコイツは使いたく無い、Visual Studio 専用 OS にしよう。
FTP ができないと困るがこれでやればイイや。

[IE]Internet Explorer で FTP サイトのパスワードを入力する方法

Explorer のエディット部にコレやればとりあえずファイル転送はできるのよね。
パーミッション変更とかはできるはずがない、それらはホストの Mandriva からやる。
パスワードに記号とか入れている人は URI 変換をお忘れなく。
でも何故か Windows 7 ミニノートからではできない…

とにかく minipoli のソースを落として実験だ。
Visual Studio 起動、初回は遅いけど二回目以降は起動が早いというより一瞬。
仮想 OS になっても Vista の SuperFetch は完璧である。
でなきゃ困る、だから XP も 7 も持っているのに Vista を使うんだから。
7 の SuperFetch は効きがイマイチなんだよなぁ…

select_x64

「すべて」を選択したので今回はしっかり x64 の選択肢があった。
ソースコードはまったく弄くらずに minipoli をビルド、何事もなくビルド完了。
ちょっと拍子抜け、本当に 64bit 用にビルドされたのかな？
実験で 32bit であるこの Vista で使ってみる。

minipoli64.zip

32bit_test

わーい 64bit ですってエラーになった！
次に x64 Windows 7 であるミニノートに持っていき試す。

64bit_test

あたりまえのように動く、マジでコードは一行も変更しないで済みそうだ。
後は 64bit 用インストーラを作成すれば minipoli の x64 化は完了。
それがやりたいだけの為に二回も休日を全部使ってしまった…
好きでやっているのだから別にイイのだが。

OSASK 公開停止か? – スラッシュドット・ジャパン

いやいや、皆が何を言いたいかよく解るなぁ。
開発者が望んでいるようなユーザーが一人でもいるなんて奇跡に等しい世界ですから。
情報公開もオープンソースも自己満足、それでいいじゃない。