うん、あまりキレイな方法じゃないけど、タスクバーが表示しようと移動する度にウィンドウをクリアすることで、なんとか背景が透過されている感じが出た。隠れる時は何もしていないけど、ま、いっか。
ユースハローワークには以前にも 2度程行ったんだけど、その時はめぼしい職が見つからなかった。選り好みしているというか、具体的な職務内容が想像できないんだ。
その時も個人情報の後悔(汗)をしていたんだけど、内容が適当なのに、毎週 1社ずつ会社案内が送られてくるのに気が引けて、公開を止めてもらったのだ。(その時が 2度目の利用。それだけのために利用したと言っても過言じゃないような(汗)。)
実際に会社案内を送ってきた募集の内容を大別すると、派遣、新規プロジェクトの人材募集、それとネットワーク構築がいくつかあったな。
派遣はこりごりだったけど、新規プロジェクトは良かったのかもしれないな。しかも嫌いじゃないカーナビだったし。GPS関連の業務が絡めばその知識をモバイルにも応用できたかもしれないのに(笑)。あ、NDA義務違反かも(汗)。でも、なんとなく気が進まず、面接も行かずに断ってしまった。
これについて、別に後悔はしてません。
後悔するとすれば、もっと早くに『まともなバイトを見つけていればっっっ!!』くらいだ。無駄な時間を過ごしてしまったな。貯金も底をついたし(寂)。
rebootした時、クライアント側で、サーバーの diskだけを使って make worldしていたのだけど、reboot完了とともに(2行程nfs関連のメッセージを出力しただけで)ちゃんと処理が再開されてる。は〜、NFSってしっかりしてるなあ。
ところで、その rebootのおかげで、netbootしていたクライアントマシンとの network速度が低下したようで (なんだか 100baseなのに10baseの速度しか出てない感じ)、クライアントから ifconfig down/upしようとしたところ、自爆してしまった(涙)。
なんで自爆かって?!
それは実行したのがクライアントで、完全な disklessマシンだから。
ifconfig downした途端に、サーバーとの接続回復手段が存在しないことに起因する『鍵は金庫の中』状態で、接続を回復させるための ifconfigコマンドを読み込むことができない。(NFSって、クライアント側ではデータを一切 cacheしないのだった.....。)
CTRL-ALT-DELすら効かない。仕方ない、今日はもう寝よ電源断!
(ま、local diskはマウントしていないから、filesystemに対する影響が無いってのがせめてもの救い)
あいや、マウントしていたっけ。上書きインストール用に。(内容は消えてもいいんだけど。)
気を取り直し、今度は座標を調整して立ち上げると、背景が灰一色。おい(汗)
XWindowBackgroundPixmap(3X11)の仕様を考慮すると、背景が透過される条件として、Pixmapとして ParentRelativeが設定されており、なおかつ、設定後に XClearWindow(3X11)もしくは XClearArea(3X11)を使用した時に、はじめて設定した背景(この場合透過モード)で描画される。
また、root windowの画像を透過させる場合は、目的の最前面ウィンドウの親 windowが、すべて ParentRelativeに設定されていなければならず、また、目的のウィンドウが移動する度、その親 windowに対し、(一番祖先の親から順に) XClearWindow(3X11)を行なわなければ、その位置での root windowの画像が反映されない(ハズ。あいや、原理から行くとこうなんだけど、未確認デス。もしかしたらどこかの部分で XClearWindow(3X11)や XClearArea(3X11)を省略できるのかもしれない。信頼性の低い情報でスマぬ)。
今回の目的は root windowの画像を『取得』することなので、新たに windowを作らなくても、透過した画像を直接使えばいいやんという安易な考え (上記の問題が見事全部当てはまる...が、トーン調整しない場合と処理はほとんど同じ) や、別の透過パッチのように XCopyArea(3X11)を使うとか (これだと xclock等の画像が紛れ込むこともなく、動作が安定している) 色々考えが浮かんできた。
ということでしばらく試行錯誤をしていたのだが、偶然にも面白い現象に遭遇してしまった。
windowの枠 (window managerにより表示される windowの枠) が透明になったのである。画像のトーン調整と組み合わせると、なんとも美しい、『クリスタル』な ktermが出来上がってしまった。(流行りでスケルトンと呼んでもいいかもしれない)
これは本格的に採用したいような気もする…。そもそも window managerに、クリスタルな枠の機能があればいいのだ。もう qvwmを改造するしか!(笑)
あと、あと、やっぱ透明な枠にも光の加減を付けて、立体的にする機能も欲しいなっ!
そうか、トーン調整機能が重いのは、画像を読み込み、変更し、転送するからだから、もう一枚 windowを重ねて、メッシュ画像を描画すれば少しは楽かも.....。
いかん、またもや芋蔓式の予感.....。まずはrelief機能をちゃんと仕上げて、話はそれからだ。
ただ、このパッチにもまだいくつか問題があり、root透過モードだと (qvwmとの組合せで) Exposeイベントに反応しないとかいった問題が確認されています。せっかくだから直さなきゃ。
また、ボクのやりたかった reliefは実現されてないし (縁取りパッチなら別件で見つけたけど)、文字の背景色属性も無視されたままのようなので、これをベースにして改造するつもりです。
なお KTerm壁紙パッチのページのとなりには他のソフトに対する壁紙パッチもあり、かなり面白いことができそうでした。
画面描画ルーチン一式をでっちあげないとダメみたいだ。
それには、文字描画と消去、スクロール処理を区別して、また Expose等による再描画処理、全部必要みたい。
影文字は重い処理なので、空白に対する省略処理 (0x20の空白文字 fontを描かずに、背景による消去だけを行なう) も欲しいような、余計なお世話のような。
また、アンダーラインや反転属性のブロックに対する影も欲しいところ。
行き着く先は出力サブシステムの総書き換えって感じかな。
ここまでくると、もう ktermとは呼べないかもしれない。(いや、呼べないじゃなくって、完全な別バージョンだ。)
さらにさらに、反転属性の文字は逆に凹んだ感じを出したいと欲が出てきた。そこで Enable reverse videoオプションを試したところ、通常文字のところでちゃんと凹んだ感じが出たので、この感じを反転属性のところでも出したい。
色々試したけど、やっぱ reliefは明るめの壁紙に設定した時にこそ映えるようだ。実現できれば最強かも。
また話がそれるけど、暗めの壁紙で凹んだ感じの文字色設定(fg:black/bg:white)にすると、文字の彫り物をした感じになって結構面白いことを発見。また一段と relief機能が欲しくてたまらなくなった。
それから、PC-9801テキストVRAMエミュレートとして、ポート6ahに40hを出力できるように(汗)。(省略時は 41h) (synopsis: -out6ah40h)
意味が判らない方は、実際に試してみるか (試しても気付くかどうかわかりませんが)、無視してください。
というのはちょっと寂しいので、ktermが自前で bold fontを作る時とか、relief(影付き文字)表示する場合に役立つハズで、設定した場合『テキスト文字』を、1ドット左にズラします。(最右端の影救済措置)
これに自由な色が付けられれば、最強かもしれない。
いや、軽快な動作の理由は、重い hilit19や font-lockが動いていないからだ。今気付いた。
さらに muleのマウスでカーソル位置を変更できる機能は特に不要だと感じる今日この頃。マウスは領域選択にだけ使いたい。それに、cut bufferも Xの cut bufferを共用するのは止めて欲しい感じだ。(←んじゃ設定しろってね)
PC-9801を使ってた時は、文字の見やすさに関連するから暗くしていたんだっけ。ソフトにもそういう機能があったし。
それに比べて現在までのしばらくは文字と背景が重なることがなかったから、気付かなかったのかな。
いや、確かに目の痛さを感じてディスプレイ側を調整してはみたんだけど、それだけじゃどうもしっくりこなくって、でもその原因が判らないのでその時はそれであきらめたんだっけ。
そう、文字と背景のコントラストがとても重要なことに今やっと気付いた。
薄暗くした壁紙に、割と明るめの文字。今のこの設定はとても見やすい。この文字の見やすさにしては、目への刺激もそれほど強くない。
そういえば、壁紙に画像を貼れるソフトで、画像ファイルを変更せずに直接トーンを変更できるソフトが無いぞ。
root windowに貼った場合だったら、root windowのトーンを調整するだけのソフトを書けばいいけど、各アプリが自分で貼る場合はアプリ自身で対応しないとお手上げだ。
ホントにやってみたい。
デフォルトは透過モードで起動。(resourceで調整可)
壁紙を指定すると、壁紙モードで起動。(トーン調整機能がほしいな)
reliefは画像モードでのみ有効。(デフォルトで有効、resourceで調整可)
完成したら portsにしないとダメだね。こんな面白いソフト、公開しなきゃつまんないっ!
あと Linuxとか、他の UNIX系にも流れて欲しいな。本家 ktermに取り込まれたら、そりゃ面白いいや、嬉しいけど、これは実用性とは無関係な拡張だから、取り込まれなくてもパッチ集として流通するといいな。
もう一つ。ボクは個人設定で 1行スクロールに設定しているんだけど、折り返し行に差し掛かる度、デフォルトの半画面スクロール処理が行なわれてしまう。結構鬱陶しい挙動なんだわ、これが。
何度も挑戦しているんだけど、どこで判断処理が行なわれているのかさっぱりわからん。
さらに、viのように 1ストロークでの半画面スクロールを追加したいな。
もっと贅沢を言えば、terminal画面モードでも基本色だけの faceを実現して、font-lockや hilit19を動かしたい。これができれば、telnetアクセスでも楽しい UNIXライフが送れるのに。
まずは wpパッチの方から。
私は ktermを visible bellに設定しているのだが、画面がフラッシュするタイミングで、画面上の文字がキレイに全部消えてしまう。
その後は壁紙とカーソルだけが寂しく残っている。
こりゃ使えねぇ(涙)。
画面がフラッシュしないので、そこらヘンの処理にバグが混じってしまったのでしょう。
tpパッチの方は、ktermを半分程画面からはみ出させた後、再び全部を見える場所まで戻すと、画面更新を何度も繰り返す無限ループに陥る。
こりゃ使えねぇ(涙)。
このパッチは backing-storeを使っているせいもあって exposureイベントが来ないので、移動時の書き換え処理のために別のイベントを要求しているハズなので、そこらヘンがおかしく、気付かずに自分が処理するイベントを自分で発行してしまっているのかな。
backing-storeなんか使わなくてもいいのに。でも exposeと move(正確にはどのイベントだったかな?)が入り乱れるのは処理的に嫌かも。
また、kterm起動直後の透過画像の位置がおかしく、root window左上の画像になっている。(ま、これはそれでもいいんだけど.....)
両方のパッチに共通している問題点。
画像モードを有効にすると、バックスクロールがヘン。なんか、表示される情報がオカシイ.....全然バグってるよぉ(涙)。
こりゃ使えねぇ(涙)。
またさらに画像モードを有効にしていると、文字の背景色属性が無視され、一切背景色が付かない。
だから、FDcloneとか、背景色が無いとわかりにくいソフトが見難くなる。別に背景色くらい付いててもいいやん。
そのくせ反転属性だけは有効なんだけど、反転文字の文字部分が透明じゃない(笑)。
唯一背景色が使われる場所なんだけど、背景色のままじゃ寂しいので、いっそのこと、透明にしよ!
| ( | 30番台の色指定 | にオプションで | 7番の反転 | を加えた時とかも!) |
上記のことが全部解決できてこそ、古(いにしえ)の PC-9801環境を再現したといえるのだ。背景の無い寂しい PC/ATよりも、やっぱ壁紙のある 98だよねっ。
fontは既に 98ANK+maru98のひらがなfont+skjmによる 98漢字のまる文字化済み。新jis化していないのがイマイチ実用的ではないけど。(便利な font editorがあればね。)
ちょっとたわごと。
なぜ、wpパッチの方が tpパッチよりも動作が速いんだろう?
どっちも XCopyAreaを使えるはずだし、root windowは backing-storeを使ってるハズなので、どっちも条件は同じだと思ったんだけど。
何気にパッチを見ていたら、kterm 16色パッチにもちょっとしたミスがあることを発見。FreeBSD ports-current('99/09/07現在)に含まれているヤツだ。
8〜15番の背景色が使われないというちょっとしたこと。条件チェックしてるんだけど、両方とも同じ値を返していたら意味無いやんって感じ。
はやく生活費を稼がねば。マジで金が無い。