Arch Linux まぁだだよ

前回、Xサーバの起動を確認したので、デスクトップ環境の整備や
日本語まわりの設定をやりたいところだけど、せっかくなので、
ウィンドウマネージャ無しの状態をもう少し味わってみる。

先ずは現状を確認するために、デフォルト（共有の設定ファイル？）
として読み込まれる
/etc/X11/xinit/xinitrc
を覗いてみる。

xinitrc は大きく三つの部分に分かれているように見える。

前段は、XresourcesやXmodmapが存在した場合は、それらを読み込む。
（但し、特別に用意しなければデフォルトでは存在しなかったり、非推奨な
設定ファイルなりなので、ここは気にしなくて良いと思う。ってヲイ！）

中段は、/etc/X11/xinit/xinitrc.d ディレクトリ内の実行可能ファイル
（スクリプト）を順次実行させる。

後段が、

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

twm（ウィンドウマネージャ）、xclockはインストールしていないので、
"command not found"と言われる。
（このエラーでXの起動工程が止まる訳じゃない）

xterm（端末エミュレータ）は、"-geometry"で、サイズ、位置を指定して
起動される。
一般的にサイズは、横幅x高さをピクセル単位で指定するが、
xterm の場合は文字数x行数になるので注意されたし。

/etc/X11/xinit/xinitrc を適当に書き換えて xterm を一つだけ起動し、
そこから別のウィンドウを起動させる。
プロセスIDを指定して kill すればウィンドウを閉じることもできる。
（画像では、xterm しか起動していないので、その上で exit するば良いけど）

Puppy Linux でKDEを使っちゃおう

Precise Puppy 5.7.1JP にKDEのSFSを読み込ませたら、簡単に動いた。

本家（英語版）フォーラムの　KDE 4.10.1, 99mo !　から kde4.10.1.sfs をダウンロードし、
読み込ませる。
「Bootマネージャ」から「起動時にどの追加SFSファイルをロードするかを選択」あるいは、
「SFS-Load オン・ザ・フライ」を使用するだけなので、超簡単。

「起動時にどの追加SFSファイルをロードするかを選択」の場合、文字通りに起動時に有効になるので、
再起動してから、一旦プロンプトに戻り、xwin startkde　とする。

「SFS-Load オン・ザ・フライ」なら、再起動は必要ないので、そのままプロンプトに戻り、
xwin startkde　とする。

このままでも良いのだけど、Puppy Linuxのシステムトレイを表示させるため(?)に、
/root/.xinitrc に編集を加える。

上の図のように、exec startkde の前に /usr/sbin/delayedrun & を追加。
（その上の /sbin/pup_event_frontend_d & に関してはコメントアウトの有無による違いを確認できてません。）

これで、システムトレイが表示される。
ボリュームコントロール（ミキサー）が二つになっているのはご愛嬌。片方を消せば良い。

さて、賢明なる読者諸兄に於かれましては、上のエディタ画像右側を目にして、お察しのことだろう。
今回の .xinitrc への変更は、スクリプトの前半部分に行っている。
（元々の .xinitrc がKDEに関しては、この位置に記述している。）
パネルを読み込んだり、ピンボード機能を有効にする前の段階で、exec startkde として、
デスクトップ環境を立ち上げている。

ならば、Xfceも同様に、前段階でデスクトップ環境を立ち上げてしまえば、後の諸々は必要ない
のではないか？

（やってみましたが、大丈夫そうですよ）

aho が Puppy Linux で使うパネルとは？

前回の「Puppy Linuxのプロンプトで xwin aho としたら」に引続き .xinitrc の話題。
もし、「AO_o10yanのやってることはPuppy Linuxの意図しない使い方だ」と思ってるならば、
以下は読まないでください。
/root/.xinitrc を読んで、「あれ？これってスクリプトの書き方として変じゃね？」って思った人は、
読んでも良いかもしれません。但し、既にそう思っている人には目新しい話では無いですが。

それでは、、、。

前回提示した画像を改めて見てみる。

これを見て、気付いた人もいると思う。
そう、ウィンドウマネージャはJWMなのに、画面下部に表示されてるパネルは、標準のトレイでは
ない。ここで表示されているのはLXPanelだ。
私は、Openboxを使用する際に表示するパネルとしてLXPanelを入れている。

LXPanelの表示を上にすれば見慣れたトレイが現れる。

上の画像を見れば分かる通り、標準トレイは表示されていたが、LXPanelに隠れて見えなかった、
ってこと。

これは、私がJWMのトレイとLXPanel の両方を表示させたかった訳ではなく、単純に
.xinitrc にそうなるように書かれているからに過ぎない。

#v3.95 support fbpanel tray/taskbar...
#only launch tray for w.m. without inbuilt tray...
if [ "$CURRENTWM" != "jwm" -a "$CURRENTWM" != "icewm" ];then
if [ -f /usr/bin/fbpanel ];then
#a bit of a hack: when 3builddistro runs fixmenus, which calls variconlinks,
#which populates /var/local/icons with symlinks, /usr/local/lib/X11/pixmaps
#is not yet populated (happens at first boot, from default icon theme)...
[ ! -e /var/local/icons/home48.png ] && ln -fs /usr/local/lib/X11/pixmaps/* /var/local/icons/
fbpanel &
fi
[ -f /usr/bin/lxpanel ] && lxpanel &
fi

じゃあ、それは　xwin aho　とした時だけの問題かって言えば、一目瞭然。

↓この画像を見てね。

Xfceで下部パネルが重なっている。

/etc/windowmanager に jwm と icewm 以外の記述があった場合、
lxpanel の存在を判定して、lxpanel があればそれを起動。

/etc/windowmanager に startxfce4 って書いてあっても同じじゃないのか？

私は取り立てて特別なことをしているつもりは無い。
パッケージマネージャからXfce4を入れているだけだ。
Presice Puppy 5.7.1から、Ubuntuのリポジトリを利用してパッケージのインストールが
できるようになったらしいので、それならば、それなりの対応をしないと駄目なんじゃないか？
と思う。
狭い範囲で、謂わば特殊な環境のみを対象にしたディストリビューションであることは、
エクスキューズに使えなくなってるんじゃないのか？との疑問を持ちつつある。




※　余談　※
.xinitrc の中に、下の記述を見つけた人もいるでしょう。

if [ "$CURRENTWM" = "xfwm4" ];then
if [ "`which xfce4-panel`" != "" ];then
xfwm4 --daemon #note, starts xfce-mcs-manager daemon also.
exec xfce4-panel
fi
fi

そう。単体のウィンドウマネージャとして xfwm4 を動かした場合に、xfce4-panel を
起動しておく記述。
単体で xfwm4 を動かしたことのある人なら疑問に思うでしょう。
「LXPanelが表示されないじゃん？重複しないじゃん？」って。

私も、デスクトップ起動後に端末から # lxpanel として、

tray: another systray already running

となりつつも、LXPanel が表示されることを確認したり、
試しにこのブロックを、上述の lxpanel 起動部分の下へ移動してみました。
そして、起動する順番を変更すると、パネルが重複して表示されることを確認しました。

確かなことは分かりませんが、順番と、デスクトップ環境からセッションで起動するとの違い
なのかと、感じています。（←「感じ」ってのも変ですが）

Puppy Linuxのプロンプトで xwin aho としたら

Puppy Linuxのプロンプトで

# xwin aho

としたら、JWMが起動するが、メニューのシャットダウン関係の項目が
効かなくなる。

当然だ。
そんな aho なウィンドウマネージャ（以下WMと表記）など存在しないから。
じゃあ、存在しないWMを指定して起動させた場合のPuppy Linuxの挙動は
これで良いのか？

馬鹿を言っちゃいけない。
ahoな指令はちゃんとエラーを出すか、代替のWMを起動させるなら、それが正常に
動くようにしなくちゃ駄目でしょう！！

/usr/bin/xwin の77行目のコメント以下81行目まで。
xwin に渡された引数を $1 で参照してはいるものの、引数の有無を見ているだけで、
何ら評価が行われていないんじゃないのか？

渡された文字列は何でも良いのですか？
WMを起動しろと言うコマンド、あるいは起動用のファイル名、
それが実行可能なのか、ファイルが存在するのか、それはWMを指定しているのか、、、。
それらの評価がない。
だから、aho な文字列を渡したら、それを /etc/windowmanager ファイルへ書き込んでしまう。
そこの注意書きには「/root/.xinitrc use this file.」と記されている。

ちょっと、意図を推し量りかねる。

Puppy Linuxでは、 /etc/windowmanager を読んで、使用されているWMを特定し、
それを使うスクリプト等が存在する。シャットダウン関連の項目もその例だろう。
実際に使用しているWMがJWMなのに aho を終了させようとしたって、そりゃ無理ですわ。

何故こんなことになるのか。
xwin での書き込みも重用だが、それを読み込む .xinitrc にも疑問がある。

.xinitrc では諸々の設定が終わった最後の方で、WMを実行している。
そこの記述。

which $CURRENTWM && exec $CURRENTWM
[ -x $CURRENTWM ] && exec $CURRENTWM
exec jwm

素人が見て分かる範囲では、
busybox に含まれる Unix コマンドの which を使って、
実際にコマンドの場所を指定し、あれば実行。
[ -x]でファイルが実行可能かを判定して実行。
最後の exec jwm は上記が否定された場合に実行。
（上記が実行されれば以下は無視？）
だろうと思われる。

えっ？

ってなるよね！！
$CURRENTWM が否定された場合、そのままなの？
変数を読み込んだ元ファイルの /etc/windowmanager は修正しないの？
そこを、実際に実行する jwm に書き換えておけば、起動後 /etc/windowmanager を
読み込むスクリプト等が動いても、齟齬を来すことはないはず。

実際には、$CURRENTWM で読み込まれている文字列が、WM以外のコマンドや実行ファイル名と
重複していないか、判定しなければならないだろう。
逆にいえば、Puppy Linux で対応できるWMを予め列挙した文字列をデータに持ち、
それに該当しない文字列ならば、強制的に jwm として処理する方法をとれば良い。
（xwin で書き込む際に判定しても良いはず）


「xwin aho なんてのは想定していません。そんなことする人は使わなくて良いです」
って、言われればそれまで。
私が悪かったです。申し訳ありません。

which $CURRENTWM && exec $CURRENTWM
[ -x $CURRENTWM ] && exec $CURRENTWM
echo -n "jwm" > /etc/windowmanager
exec jwm

↑のように "jwm" を書き込む1行を加えるだけでも、対症療法にはなると思うんだけどな、、、。