Archive for the ‘Linux’ Category

PHPをバージョンアップする件。手始めに自分のPCでやったら、予想外に面倒な事態になってしまった。

僕のPCのLinux(のパッケージ)には最新のPHPが提供されていないので、PPA(昔流行った「ペン―」じゃないですw)という第三者のパッケージで手軽にバージョンアップしようとした。それを使ってPHP自体の更新はうまく行ったのだが、その後がいけなかった。そのPPAには、どういう訳かPHP以外のパッケージが山ほど入っていたのだ。PHPを入れて少しして、別のパッケージの更新の通知が大量に出て、不思議に思ってそれらの中身を調べたら分かった。

知らない(馴染みのない)パッケージが(通常はないほど)沢山出て来て嫌な感じがしたのだが、その時は少し迷ったものの、「まあいいか」と更新した(これが最悪の選択だった・・・)。が、あとで良く考えてたら、PHPだけでも第三者に依存するのはリスクがあるのに、他の多くのパッケージまで依存するのは危険なことに気付いた。例えば、更新されたパッケージには重要な通信モジュールである、OpenSSLが入っていたのだ。親切で入れたのか、パッケージを分けるのが面倒だったのか、PHPと依存関係があるのか分からないが(更新する前から問題なく動いていたし、依存関係があるなら最初から自動でインストールされるので、最後は理由ではなさそうだ)、さすがにちょっと怖い。今までのPPAではこんなことはなかったので、おかしいと思う。

それで、仕方ないのでPHPのバージョンアップはOSを更新して(OSの正式パッケージで)行うことにして、更新したばかりのPHPを戻した。OSのものはバージョンが一つ古いが、しばらくは使えるだろう。更に、さっき更新されたパッケージも戻そうとしたら、それが一筋縄では行かなかった。。。

パッケージを戻すには、一旦アンインストールして入れ直すか古いバージョンを指定してインストールする必要があるのだが、更新されたパッケージは既にいろいろな依存関係にはまっていて、素直にアンインストールできなくなっていた。いろいろ調べて四苦八苦して、多くは戻せたが、全部は無理だった。

OSを更新(バージョンアップ)すれば直る(リセットされる)可能性はあるが、直らない可能性もあるし、最悪の場合、OSの更新が失敗することもあり得るし、更新するまでおかしな状態のままなのは嫌なので、どうしても元に戻したい。

もう少し試行錯誤はするが(上書きインストールができないかなど)、今のところは、バックアップからリストアするしかなさそうな感じになっている。まったく溜息だ・・・ 手抜きや良く考えずに"OK"を押すのは良くないね。

(22:47) どうしてもリストアは気が進まなかったので(余計なものが残ったり、事態を更に悪化させる可能性があるため)、良く分からないなりにパッケージ管理コマンド(aptitude)を試行錯誤したら直った。基本的には、今までやったとおり、古いバージョンを指定してインストールするか不要パッケージを削除するので良かった。

ただ、ポイントは、それで問題が生じる場合に解決するための対処候補が出て、最初の候補は依存するいろいろなパッケージを削除するとか出て怖いのだが、何度か次候補を出して行くと、仕舞いには問題のパッケージをダウングレードする候補が出る(ことがある)ので、それを実行することだ。そうすると、依存関係がガチガチのものも、魔法のようにうまく直った。それでも駄目な時は、パッケージの依存関係を調べて、インストールや削除の順序を変えるといいようだ。

今日インストールしたパッケージのバージョンを調べた限り、元に戻せたようだが、まだ不安はあるし、とても疲れた。。。 変なPPAには充分注意する必要があるが、なかなかできない。

最後に書かなくてもいい一言: PPAは嫌いでも、Linuxは嫌いにならないで下さいw

 

PS. 最新のPHPにする方法を検索すると、このPPAを使う方法が当たり前のように出て来るが()、みんなこういうことは気にしないのだろうか(気付いていない?)。まあ、Linuxの正式なパッケージだって、信頼性は保証されていないが、どこの誰とも分からない第三者(個人)の作るものなので、そこには誤りや最悪の場合には(提供者が意図するかしないかに関わらず、)マルウェアなどの混入の可能性がある(今は問題なくても、将来の更新時におかしくなる可能性は0ではない)と思うのだが、そうでもないのだろうか。みんな、人柱になる気が充分なのか。

今回特に嫌だったのは、このPPAには目的のパッケージ(PHP)以外のものが多数入っており、目的のパッケージは確認したり使ったりするので問題ないことが分かるにしても、自分が使わない・意識していないパッケージが異常だとかマルウェアだったとしても気付かない可能性が高いことだ。

PS2. PHPを最新にするには、もう一つ方法がある。自分でソースをダウンロードして、ビルドするのだ(これをやった人がPPAを作って提供していることがある。だから、PPAを使うと楽になるのだ)。が、パッケージと違って、状態を最新に保つには、PHPが更新されるたびにビルド・インストールする必要があって、なかなか手間が掛かる。特に、マシンが何台もあると面倒だ。まあ、ビルド・インストールを自動化すればいいが、結構怖いものがある。 でも、それもいいかも知れないと、今思ったw いや、ちゃんとやるなら依存関係のあるモジュールも芋づる式に更新する必要が出て来るから、やっぱり現実的ではなさそうだ。 (12/15 8:13)

  •   0
  •   0

先日ちょっと書いた、Linuxではマウスホイールの加速ができない(ディストリビューションやデバイスによってはできるかも知れないが、僕の使っているLinux Mint Xfceにはない)件だが、できるようにする方法が見つかった。まだアイデアの実現性が確認できた(PoC)段階だが、一応使えるようになった。

はじめに書いておくが、現状でも、ウインドウサーバ(X11)の設定などでマウスホイールの加速をすることはできる。例えば、imwheelコマンドを使えばホイールの倍率を設定できる。ただ、それは今一つ実用的でない。僕も以前試してうまく行くと思ったのだが、問題があって止めた(そのことを忘れていた)。

その問題は、設定やimwheelは常に加速する(「加速」というより、「倍率」という方が正しい)ので、例えばVivaldiブラウザでタブ一覧をホイールで選ぼうとすると、1ノッチしか動かさなくても設定した倍率のノッチ分(例: 3ノッチ)動いてしまって、まともにタブが切り替えられないことだ。imwheelは設定で対象のウインドウを指定または除外できるが、Vivaldiのタブ一覧は子ウインドウではなさそうで、除外できなさそうだった(実際には子ウインドウなのだろうが、容易には分からなかった。もし分かったとしても、自分が使うすべてのアプリについて調べるのは、実用的でない)。

そのため、単なる倍率設定でなく、本当に加速する機能が必要だ。その、「本当に加速する」は以下の定義とする。

  • ホイールの回転速度(以下、速度)が速い時にホイールの変化数を増やす。
  • ホイールの速度は、ある時間内のホイールの変化数(ノッチの変化数)とする。
  • 増やす値は、例えば、ホイールの変化数にあらかじめ設定した値(加速係数)を掛けて求める。

上記の定義を実現する処理の概要を以下に示す。

  1. マウスをLinuxのウインドウサーバ(X11)(のイベントドライバevdev)が無視するように設定する。ホイールだけ無視できるなら、そうする。
  2. マウスイベントを取得する。
    • 通常のX11では、ホイールはマウスのボタン4と5に割り当てられているので、それらのイベントを取る。
  3. ホイール以外のイベントは、そのまま発生させる。
  4. ホイールのイベントは、加速処理をしてイベントを発生させる。
    • ホイールの速度は、所定の時間内に(連続して)取得できた同一イベント数から求める。イベントの有無の判定にはselectを使った。
    • ホイールの速度に比例させてホイールイベントを追加発行する。
      • 例: 2イベント発生、速度= 40イベント/s、加速係数= 0.1 → 0.1*40*2 -2= 6イベント追加

イベント処理の概略図

イベント → ホイールイベント処理プログラム → ウインドウサーバ (X11)
                 ホイールイベント: 加速処理をして出す
                 他のイベント: 何もしないで出す

次に、本方式の実現性を確認するためのテストプログラムを作成した。C言語は手間が掛かるのでPHPを用いた。この時、evdevの設定変更のたびにX11を再起動したくなかったので、上記1番のevdevがホイールを無視するように設定する処理について、evdevと並行してイベントを読めるか試したら読めたので(ただし、通常の設定ではrootの権限が要る)、実装を保留して残りの処理を実装した。また、evdevと並行動作させるため、他のイベントを発生させる必要もないから、上記3番の実装も行っていない

なお、加速処理で追加のホイールイベントを発生させる処理は、速度や負荷の点から、本来はネイティブなX11のライブラリを使うべきだが、今回は実現性の確認が主な目的なので、xdotoolコマンドで発生させた(例: xdotool click 4 (または5))。

作成したプログラムは(予想に反してw)期待どおり動いた

最初は想定していなかったのだが、この処理はウインドウサーバ(X11)の処理と並行して動作できるので、X11への変更は全く不要で、プログラムの追加だけでできた。そのため、最初は仮想環境で動作確認や修正をしようと思って準備したのだが、全然使わなかった。

以下に、本方式のデモを示す。

○ページのスクロール (ホイールを6回、速く動かした場合)

通常(ホイール加速なし)の場合 (スクロール速度は変わらず遅い)

 

本方式の場合 (スクロール速度が高速)

 

○タブの切り替え (ホイールをゆっくり動かした場合)

imwheelの倍率を有効にした場合 (複数タブ分飛んでしまう)

 

本方式の場合 (タブが正常に切り替えられる)

 

考案した方式でホイールの加速が実現できることが分かったが、現状では以下のような問題点や不足点があるので、追って改良して正式版にしたい。

  • ホイールイベントの追加数が多い場合(加速が大きい場合)、スクロールが遅い(終わるまでに時間が掛かる)。そのせいか、今一つ感触が悪い(「スムーススクロール」に似た、ぬるぬるした感じ)。 → 不具合の修正と動作・パラメタの調整で解消し、きびきび動くようになった。
    • 追加数が一定値以上の場合はホイールでなくPage Up/Downにすると良さそうだが、アプリの対応状況に依存するので、単純ではない。
    • 追加イベントの発行にxdotoolを使わなければ速くなるのか、要確認。 → xdotoolのイベント発行間隔(--delay)を指定する必要があった。
    • Windowsでの動作を調べる。
    • 設定(しきい値、加速係数など)を調整する。
  • 追加イベント発行中(スクロール中)にマウスを動かしてウインドウが切り替わると、別のウインドウにホイールイベントが行くので、思わぬ結果になる。 → スクロール開始時のアクティブウインドウにイベントを発行するようにしたが、まだ不十分な点もある。 → 上記のスクロールが遅い不具合を修正したため、ほとんど問題にならなくなった。
    • ウインドウが切り替わったらイベント発行を停めたいが、結構難しそう。
    • Windowsでの動作を調べる。
  • マウスのイベントデバイス(/dev/input/event*)を自動検出する。 → 対応した(複数のマウスがある場合は、最初のものに対応することにした)。
  • ホイールイベント発行にxdotoolでなく、ネイティブなX11のライブラリを使う。 → 対応した。
    • PHPから容易にイベントを発行できるX11ライブラリが見つからなかったため、XTestを使ったサンプル(fakeMouse)を元にして、標準入力からマウスのボタン番号などを読んで対応するイベントを送信するプログラムを作り、本プログラムとパイプで接続して、ホイールイベントを送信できるようにした。
      • 構成: 本プログラム(標準出力) → [ボタン番号] → (標準入力)マウスイベント送信プログラム → [マウスイベント] → X11
      • イベント送信プログラムはネイティブライブラリを使っているし、イベント送信のたびにプログラムを起動せずに済むので、速度や負荷は問題ないはずである。 → 何となく、スクロールがスムーズになった気がする。
  • 設定の最適化
  • その他、設定変更機能、異常対応処理や細かい機能の追加。

 

(12/15 7:51追記) 使っていて大きな問題はないが、一部のアプリ(NixNote2)でホイールを高速に動かすと誤動作(逆方向にスクロール)する。そのアプリ固有の問題なのか、イベントの出し方に何かコツがあるのかは不明だ。ただ、xdotoolでイベントを出していた時は無視されたし、他にもこれとは関係ない問題が若干あるので、NixNote2固有の問題の気がする。

 

(12/13 8:31 改良・修正結果を反映; 9:54 若干修正、デモビデオを更新; 19:13 xdotoolを止めた件などを反映)

PS. これはいくら検索しても出てこなかったので、まだ誰もやっていないと思うが、どうだろうか? 誰かは居るかな。

PS2. もし、ご入用・ご興味のある方がいらっしゃいましたら、コメントなどでお知らせ下さい。公開を検討します。

  •   0
  •   0

○現状維持の話

先日思い付いて少し試していた、ウインドウマネージャーを入れ換える件は、結論としては止めることにした。OS(正確にはディストリビューションやデスクトップ環境)の入れ換えまでも検討したが、僕にはメリットがなさそうだった。僕の要求を満たすウインドウマネージャー・デスクトップ環境がなかったのだ。

重要な条件は以下である。

  • カスタマイズ性がいい(容易に自由に・細かく設定が変更できる)。
  • 重くない(CPU負荷が高くない、メモリ消費量が多くない)。ただし、機能は充分であること。
  • デザインがしょぼくない。
  • Xfceのように中身が古臭くない。
  • 開発が継続している。

特に、カスタマイズ性が重要だ。例えば、今回の発端となった、ウインドウ枠の幅(実際にはリサイズ時につかめる幅)を自由に変えられることだ。逆に、機能として、見た目が「すごい」こと(例: アニメーション効果)は全く不要だ。

それで、以下のようにいろいろなウインドウマネージャー・デスクトップ環境を検討、試用したが、どれも現在のXfceから移行する価値があるとは言えなかった。

ウインドウマネージャー

検討したもの: Compiz, cwm, Enlightenment, Fluxbox, FVWM, Gala, KWin, Marco, Mutter, Muffin, Openbox, Sawfish, Awesome, XMonad

まず、カスタマイズ性の点から、思想が相容れないElementary系は却下した。また、個人的にKDE系にはいい経験がないので却下した。それから、余りにも古く感じるMotif系やそれ以前のもの却下した。あと、馴染みない・余りにも汎用性のない言語でカスタマイズするもの(XMonad, Sawfish)も却下した。

それから、残ったいくつかの候補を仮想環境(VirtualBox)上のLinux Mintにインストールして試した。また、Linux Mint Xfceで切り替えて使える、Metacity+ComposingとCompizも試した。

試用結果(概要):

  • Awesome: 使い勝手が悪く(例: リサイズが枠でできない)、設定が面倒(テキストファイル)。
  • Mutter: 見た目はXfce4と変わらない。ウインドウマネージャー単体では使えず(不便・意味がない)、設定アプリなどが別途必要。
  • Metacity+Composing: Mutter同様、ウインドウマネージャー単体では使えない。(だったら、何のために入っているのだろうか??)
  • Compiz: 不安定(設定を間違えると動かなくなる)、余計な視覚効果(ウインドウの移動がぬるぬる)が多い。

デスクトップ環境に含まれているウインドウマネージャーは、それだけを入れても意味がないことが分かったので、ディストリビューションやデスクトップ環境も入れ換えてみることにした。

ディストリビューション・デスクトップ環境

検討したもの: Budgie (Solus Linux, Ubuntu Budgie), GNOME 3 (Ubuntu GNOME, Debian, Fedora), Manjaro, KDE Plasma (Ubuntu), Cinnamon (Linux Mint), MATE (Linux Mint), LXQt, Debian, Lubuntu, Arch Linux

上記と同様いい経験がないので、KDEとFedoraは却下した。MATEは今と同じLinux Mintであり、しかもCinnamonとXfceの中間で、敢えて移行する意味が余り感じられないので、却下した。LXQtなどは今より更に軽量系で高機能は期待できないので、却下した。また、純粋なGNOMEは評判が悪いので、却下した。そのため、GNOMEが標準のディストリビューションも却下した(ただ、KDEもGNOMEも駄目だと、かなり選択肢が減ってしまう)。

試用結果(概要):

  • Solus Linux (Budgie)
    • Solus: 日本語対応に問題あり(ソフトウェアセンターにfcitx, mozcなし)かつ対応ソフト不足(使うソフトがソフトウェアセンターにないことが多かった)。
    • Budgie: カスタマイズ性が特にいいとは言えない。ただし、(ウインドウの枠幅は狭く、設定変更は不可だが、)リサイズ時につかめる領域が広い。
  • Linux Mint Cinnamon
    • Budgieと同様に、ウインドウの枠幅は狭く設定変更は不可だが、リサイズ時につかめる領域が広い。
    • デスクレット(デスクトップに置く部品)、アプレット(バーに置く部品)がいろいろあって便利そう。
    • Xfceで自分でやっていたことの多くが、最初からできている感じ。
    • パネル(バー)の設定の使いやすさやカスタマイズ範囲は今一つ。設定項目は少ない感じ(意味不明な設定もあった)。Xfceの方がいろいろできるかも。
  • Manjaro (Xfce): KDEを推しているようだが嫌なので、OSを評価するためにXfceで試した。
    • パッケージのソフトがUbuntuより若干少ない感じなので、敢えて移るメリットはなさそう。
    • Xfceなので、デスクトップ環境の使い勝手は同じ(外見は違う: テーマの違いか?)。

結局、特別にカスタマイズ性その他のメリットのあるものが見つからなかったので、換えるのは止めた。そういう点では、Xfceは僕に最適なことを実感した。ただ、簡単に移行できるなら、Linux Mint Cinnamonは悪くないと思った。あと、ウインドウの枠幅は狭い(設定変更も不可)が、リサイズ時につかめる領域が広い(枠外でもある程度の範囲でつかめる)ものがあったのは、なるほどと思った。合理的で全く問題ない。しかも、見た目も(枠が太くならないので)ダサくない。ずっと前にではあろうが、進歩したことなのだろう。この点はXfceは駄目だ。僕は自分で何とかしたが、直す気がないのは余りにも意固地だと思う。

少し考えたら、リサイズ時に枠外でもつかめるようにするには、その範囲(枠の周囲)を透明な子ウインドウにするか、ある線の近くにマウスが来たらイベントを出す仕組みがあるのならそれを使う必要がありそうで、今のXfceの構造とはかなり違って来るから、簡単にはできなさそうだ。でも、前者はできそうな気もする。枠を透明な画像にすればいい?? → 試したくなった! → 駄目だった(透明部はウインドウがないことになるようで、マウスポインタが変わらなかった)。

余談だが、ウインドウマネージャーなどを試す時にマウスホイールの設定も見てみたのだが、全部同様だった(というか、ホイールの設定がない)。今のLinuxのマウスホイールのサポートは貧弱(加速しない)で、結構不満に思っている。何ページもスクロールすると指が疲れるので、そういう時は気が重くなる。何かいいソフトがないか、時々探している。もし、加速に対応しているものがあったら、万難を排して移行したかも知れないw

○非現状維持(現状打破ではない)の話

ウインドウマネージャーは現状維持でいいのだが、逆に、偶然、駄目なものを見つけた。PHPである。今はOSのパッケージにあった7.0を使っているのだが、何かのついでに、7.0のサポートが終わることを知った。今まで全く注意していなかったのが悪いのだが、寝耳に水だった。調べたら、最新は7.3のようで、全く浦島太郎状態だ。。。 0.1や0.2くらいなら見過ごすが、これはさすがに放置できない。

仕方ないので移行する方針にして、準備のために、ドキュメントでバージョン間の違いを調べたのだが、さすがに山ほど違っていて見切れないし、読んだって、自分で作っていないソフトに関しては全く判断できない(自分で作ったものでも分からないw)。仕方ないので、他者のソフトについてはその資料で対応しているかを調べ、不明なものや自分で作ったものについては、動かして試すことにした。

あと、今使っているPHPのモジュールが最新版にもあるかを調べて気になったのは、mcryptが廃止になったことだったが、インストール履歴を調べたら、今は使っていないソフトのために入れたものなので、問題なさそうなことが分かった。他には、今使っているソフトで更新が停まっていて(おそらく開発終了)、最新のPHPに対応しているか不明なものがあった。もし駄目なら、別のソフトに入れ換える必要がありそうなので、面倒だ。

○まとめみたいなこと

どっかの役人のように金科玉条のごとく現状維持しかしないのは、愚の骨頂だ。そんなの要らない。一方、Linux Mintのサイトのバージョンアップの案内には、「やみくもにバージョンアップするのは良くないです。問題なければそのままでいいんですよ」というようなことが書いてあって、この業界では結構珍しく、共感できた。まさにそのとおりだ。そして、毎年だか毎月だか知らないけど、常に素晴らしい最高の「何か」を出して強制的に更新させた挙句に問題を起こす会社には、アフォとしか言いようがない。

  •   0
  •   0

先日ちょっと書いた、ウインドウマネージャーを換える件でいろいろ調べて、試しもしている。そっちについては(余りいい話がなさそうなのだが)あとで書くとして、おもしろい記事を見つけた。

The Linux desktop: With great success comes great failure (2018): ほとんど僕と同じ意見。だからLinux(デスクトップ)は普及しないんだよ。

Major Linux Problems on the Desktop, 2018 edition: 書いてあることは概ね正しいのだが、敵意あるいは私的な恨みに満ちている。

実際には、終わりの方に提案やLinuxのいい点も書いてあるので、本音はそうではないようだが、書き方(言葉遣い、文句の列挙)が印象を悪くし、反発をかっている。個人サイトだからいいけど、同じことだって最初の記事のように書けばいいのに・・・ (と書いていて、自分に言ってる気がして来たw)

読んでいて、僕も感じていた、オープンソースコミュニティのある種の閉鎖性(彼は(自分を棚に上げつつも)「敵意丸出し」と書いている)は、やっぱりあるのだと思った。(「オープン」と言いつつ、閉鎖的・排他的なのが笑える。彼らの「オープン」は"open source"の字面どおり、プログラムだけなんだろう。と、なぜか憤ってしまったw)

でも、そんなことをやってたら、「ある日、気付いたら、IBMだのMSだのに乗っ取られていた」になるんじゃないかな。いや、それならまだましで、「気付いたら、誰も居なかった」ってこともあり得る・・・

ところで、Summaryの最初の"No stability, bugs, regressions, regressions and regressions"はWindowsでも同じではないだろうか? Windowsは安定していてバグもないんだっけ?? いつからそうなった? 誰がそんなこと言った?w

この人は随分ゲームが好きなようだ。Linuxで本気でゲームをやりたい人も居るんだと思ったw

以下は本題とは関係ないが、こっちの方がためになったかも。

2番目のサイトは、むしろコメントが英語の勉強になったり、他人の意見を知ることができるのでためになると感じた。読んでいて、"snowflake"の意味が分からなくて検索したら、"英語 with Luke"というためになりそうなサイトが見つかった。でも、ざっと見たら、確かにおもしろいけど、実際には後で見ることは少なそうだw

"snowflakes"は、日本で言えば、「ゆとり世代」とはちょっと違うようだが、今の多くの怒りっぽい(「悪い」ことを見ると、すぐにSNSで吊るし上げる)日本人みたいな印象を受けた。あるいは「意識高い系」?

というのは、スラング、流行語、映画やTVなどでの言葉が主なので、おもしろいけど実用性が低い感じなのだ。いや、ネイティブと接する機会がないから貴重ではあるのだが、それ以前の力を付けたい。言い方を変えれば、こういう良くある断片的な「生の英語の豆知識」ではなくて、英語圏の考え方とか行動とか生活にどっぷり浸かりたいのだ。そうでないと実際には使えないし、そもそも英語を使うことが本質ではないので、意味がないと思う。

PS. snowflakeの他に、"suck"(これともう一つの単語(何だか忘れた)の区別が付かないので、)がいい意味なのか悪い意味なのか分からなかったので検索したら、見つかったページでは"suck"は"f**k"よりは(女性でも)気軽に使えるとか書いてあったが、ホンマかいなと思った。

  • 英語 with Luke

    英語 with Luke

    英会話、日本人英語学習者が犯しやすい誤りに関する記事の他、クイズ、語彙、スラングなどについて取り上げ…

  •   0
  •   0

去年、Xfce(xfwm4)のウインドウ枠(上を除く)を太くした。それには概ね満足していたのだが、ことあるごとに上辺も太くしたいと思っていた。というのは、上をつかんでリサイズすることも多く、そのたびに神経を遣うからだ。それに、上だけ例外というのは癪だ。それで、昨夜、うっかり取り掛かってしまったw

ただ、去年も書いたように、元々できない(と思っていた)ので、まずは、まだ/本当にできないのか検索し、やっぱりできなさそうなことが分かった。仕方ないので、プログラムを改造しようと思って、ソースを見て直すべきところを探した。コードの見た目は綺麗なのだが、他人が書いたせいか、どうにも分かりずらくて苦労した。

結構時間が掛かったが、ようやく、どこでどうやって枠を処理しているかが分かった。それぞれの枠画像を本体の子ウインドウにしていて、そこにマウスが入ったらマウスポインタを変えるなどし、ドラッグされたらリサイズなどの処理を実行するようだ。

次に、その枠画像を読み込むところを探したら、settings.cのloadTheme()だった。それを読んだら、思わぬことが分かった。上辺はタイトルの枠画像(実際には枠ではなかった。以下、タイトル)だけだと思っていたら、その上にトップの枠画像(以下、トップ枠)があるのだ。全然知らなかった。改めて検索したら本当にそうだった(→ 参照: "Titlebar decorations"の項。見ても意味不明だが・・・)。以下に、それぞれの枠画像の位置関係を示す。ただし、実際にはそれぞれの枠画像は細分化されている(トップ枠については後述)。

トップ枠

タイトル

(ウインドウ本体)

下枠

つまり、今はトップ枠(太字)の画像が存在しないからデフォルト値が使われていて細い※のだが、太いものを作ってテーマに追加すれば、他の辺と同様に太くできそうなのだ。

※今気付いたのだが、元々トップの左と右角の画像はあったので、(デフォルト値とは別に)それが細かったのかも知れない。

さっそくやってみた。実際のトップ枠は以下のように7個に分割されているので、それぞれを準備した。上段は画像ファイル名の先頭、下段は内容(用途)である(内容は推測を含む)。

top-left top-1 top-2 top-3 top-4 top-5 top-right
左上角 左ボタン領域の上 タイトルの左余白の上? タイトル文字列の上 タイトルの右余白の上? 右ボタン領域の上 右上角

また、他の枠同様、それぞれにアクティブ時(-active)と非アクティブ時(-inactive)の画像が要るので、トップだけで合計14個もの画像を用意する必要がある。ただし、角以外(top-?-*)は同じでいいので、top-1-*をsym-linkして同じものを使った(もしかしたら、同じものはなくてもいいのかも知れないが、面倒なので確認しない)。

分からないことや謎があって随分苦労したが、できた。図示が難しいが、実際に、リサイズでつかめる領域が広くなった(気がする)。「気がする」と書いたのは、確かに他の辺と同様の使い勝手になったし、確認のために境界を表示すると想定どおりなのだが、どうも代り映えしないからだ。広くなったのが数画素(他と同様に枠を7画素にしたので、デフォルトに4画素程度追加)に過ぎないせいだろうか? まだ何か間違っている可能性もある。

分からないことは、例えば以下だった。

  • 枠画像ファイルの場所
    • すっかり忘れていた。 ~/.themes/(テーマ名)/xfwm4 の下だった。
  • トップ枠を広げ過ぎるとタイトルが狭くなる。高さに制限があるのだろうか? そもそも、それらは別の領域ではないのか?
  • トップ枠の色を他の枠と同じにしたのに合わない(暗く見える)。上から光が当たっている効果が付いているようで、タイトルの背景も指定より明るくなっている。 ← 上記の参照ページを良く読んだら原因が分かった。枠画像のディレクトリにαチャネルを持つpngのファイルがある場合、それが被せられるためである。元となったテーマのpngファイルが残っていて、それが明るくしていた。pngファイルを削除したら、想定どおりになった(ただ、見栄えが少し悪くなったので戻した)。
    • その、色を明るくする効果の指定場所は不明だったので、画面で実際の値を調べて調整した。そのため、テーマを変えたりすると色が合わなくなる可能性がある。
    • なお、画像ファイル(xpm)中の色は名前で指定できるので、テーマの設定ファイル(themerc)で指定して各ファイルから参照するようにし、あとで変更する時に整合性が保てるようにした。以下に設定した名前を示す(なお、これらを使うのが適切なのかは不明だが、設定しても問題が起こらなかったので、使った)。
      • active_color_1: トップ枠(アクティブ時, top-*-active.xpm)の本体色
      • active_color_2: タイトル枠(アクティブ時, title-*-active.xpm)の本体色
      • inactive_color_1: トップ枠(非アクティブ時, top-*-inactive.xpm)の本体色
      • inactive_color_2: タイトル枠(非アクティブ時, title-*-inactive.xpm)の本体色
    • それぞれの名前のデフォルト値はテーマで指定するのだろうが、(themercでなく、)GUIではどこで変更できるのかは不明だった。

 

それにしても、xfwm4のこのようなしょうもない(例: アナクロな)仕様を見るにつけ、「美しくない!」と思うし、何人もが太くしてほしいという要望を出しているのに「それは仕様」、「非対応」と言い放って対応せず、実際にはやればできるのに情報を公開しない態度は大嫌いだが、自分では作る気になれないし、おそらく作れないので我慢して使うしかない。でも、他にもっといいウインドウマネージャがあれば試してみたい。

ただ、ウインドウマネージャはデスクトップの肝なので、失敗すればシステムを壊す可能性があるし、ウインドウマネージャが変わればテーマも別になるので、せっかくカスタマイズしたテーマを捨てて新たに最初から作るのは面倒そうなので、二の足を踏んでいる。そもそも、ウインドウマネージャを変えるのであれば、デスクトップだってXfceでなくてもいいことになりかねず、ちゃぶ台返しになりそうだ(それでも使い勝手が良ければいいけど)。

  •   0
  •   0

昨日も書いたが、システムトレイのアイコンも減らしてバーの空きを広げたい。具体的にはDropboxのアイコンを消したい。というのは、今までまともに表示も動作もしていなかったからだ。アイコンは駄目なマークになっているし、押してもメニューは空だった。通常なら「インジケータープラグイン」または「通知エリア」の設定で消せるはずなのだが、なぜか出ないので消すことができない。

今朝、消す方法を調べていたら、その問題の解決方法が見つかり(→ 参照: ecosseman Mar 22 '16 at 9:09など)、アイコンもメニューも正常になった。どういう訳かは分からないが、以下のようにDbusの環境を設定してDropboxを起動するといいようだ。

dbus-launch dropbox start

ただ、僕はDropboxが動いていれば良く、状態を調べたり操作することはまずないので、やっぱりアイコンを消したい。それで更に調べたり試したりしたのだが、どれもうまく行かなかった。しかし、最後に思わぬ方法に気付いた。Dropboxのプログラム(Pythonだった)の中を見たところ、非ウインドウ環境でも動くようにできているので、その状況であるかのように(Dropboxを騙)して起動すればいい。具体的には以下である。

unset DISPLAY
dropbox start

簡単だが、これだけで消えた。まったく拍子抜けした。

もちろん、この状態で起動していてもdropboxコマンドは通常どおり使えるので、Dropboxの状態を知ること(dropbox status)などはできる。開始(dropbox start)以外なら、アイコンが増えることはないようだ。なお、実際に使う時にはスクリプトに入れると便利だろう。また、Dropboxの「ログイン時に自動的に起動」の設定はoffにし、ログイン時にそのスクリプトを自動起動させる必要がある。

ちなみに、Dropboxのプログラムの中を見ることを思い付いたのは、別のフォーラムの投稿(marcelo spitteler: 2016-02-24)からだった。

  •   0
  •   0

先日のデスクトップの改良は、そもそもアイコンが多くてサイドバーに入り切らないことがあるのを何とかしたいこともきっかけの一つだった。そのために、バーを2列にすることも試したが、不格好なので止めた。

一方、アイコンの中には、通常は操作しないから表示しなくていいものがあるので、それが消せれば少しは空くのにと、ずっと歯がゆく思っていた。devilspie(またはgdevilspie)というコマンドを使えば容易に非表示にできるのだが、再度表示させるのが手間だ(一時的にdevilspieの設定を変えて、アプリを再起動する必要がある)。WindowsやMacなら右クリックで容易にできるのだろうが、Linux(Xfce)では簡単ではない。そもそも、Xfceのバーにはそんな機能はないw それで、先日は他のバー(ドック)を試したのだが、どれもうまく動かず機能も不充分だったので、諦めた。

それでも、今日、しつこくいろいろ調べたら方法が分かったので、やってみた。基本的にはwmctrlというコマンドが使える。これは比較的新しい(と言っても、十年以上前からあるようだ)コマンドのようで、初めて知った(それで今まで思い付かなかった)。wmctrlの機能の一つに、ウインドウの属性を設定するものがある。そして、バーにアイコンが出るかどうかはskip_taskbar(_NET_WM_STATE_SKIP_TASKBAR)という属性で決まるので、アイコンを出なくしたい時にそれを設定し、出したい時に解除すればいい。

基本動作は以上だが、マウスで簡単に使えるようにしなければ今までと同じでやらないので、zenityというアプリを使って簡単なアプリ、xskip-taskbarを作った。いろいろ実装したい機能はあったのだが、とりあえずは、ウインドウ一覧で対象のウインドウを選択してOKを押すと、そのウインドウのskip_taskbar属性を反転させるようにした。下の例では、oclockというアナログ時計のアイコン(黒いもの)を非表示にしている。非表示にするとバーの空き領域は増えるのだが、残念ながら2個減らしたくらいでは、ちょっと見ただけでは分からない感じだ。

なお、一覧にウインドウを全部出すと、選ぶ時にスクロールするのが大変だし間違いやすいので、設定変更しそうな(したい)ウインドウだけをフィルタリングして表示するようにした。全部のウインドウを出せるようにもするとか、マウスでウインドウを選べるようにもするとか、属性の反転以外に設定・解除もできるようにするかという構想はあったのだが、今のままで充分なので、多分作らないだろうw

ちなみに、xskip-taskbarは至って小さいスクリプトだ。大きく2つの部分に分かれていて、前半ではウインドウ一覧を表示して選択されたウインドウのIDを取得し、後半では選択されたウインドウに属性を設定(反転)する。それぞれの中心となる処理は1行である。とはいえ、前半はいくつもの処理を連結しているので、呪文のように長いw

これで、滅多に操作しないウインドウは(devilspieの機能で)起動時にアイコンを出さないようにしておき、操作したい時だけこのアプリで出し、操作が終わったら消すようにできた。最終的にアイコンが4個減らせたので、バーに表示するアイコンのサイズを少し(数画素)大きく(= バーの幅を広く)することができた。それで、バーに入れているデジタル時計の文字をわずかに(0.5-1ポイントまたは画素)大きくできた。何ともセコい話ではあるが、切実な問題だw 他に、間違って閉じる(終了させる)と音が出なくなる重要なアプリ(jack-rack)のアイコンを出さないことで、間違って閉じたり設定を変えてしまうことを防げるようになった。これも長らくやりたかったことで、結構うれしい。

こういうのは、まったく、以前書いた「さあ、作ろう!」の典型だ。僕はおもしろいけど、WindowsやMacに慣れた人には結構な障壁だろう(そもそも、それらに機能が不足していたとして、こういう芸当が簡単にできるかは疑問だ。Windowsはコロコロ仕様が変わってすぐに動かなくなりそうだし、Macはさまざまな秘密に邪魔されそうだ)。

PS. 上述の通常のアイコンの他に、バーを狭くしているもう一つの原因のトレイアイコン(システムの状態を示すアイコン。Windowsのシステムトレイのアイコンに相当)も一部を非表示にしたかったのだが、それは消すことすらできていない。設定ではできないことは分かっているが、今回のように、何かのコマンドでできるのかも知れない。

  •   0
  •   0

デスクトップ(画面)には、「高い場所」と「安い場所」があるようだ。効き手や言語やデスクトップの設定やディスプレイの配置にも依るだろうが、「左高右低」で左上が一番高いように思う。

僕は、今までデスクトップの左上に時計を配置していたのだが、近頃、それが無駄に場所を食っているように感じて来た。というのは、時計の上にウインドウを置くと時刻が見えなくなるし、それを防ぐために時計を常に最上層で表示すると、ウインドウの中身が見えなくなったり操作できなくなる。結局、時計のある左端が帯状に使えなくなってしまう。

それで、時計を小さくしたりサイドバーを狭くしてみたのだが、焼け石に水というか、本質的でないように感じた。それで、最初に書いたデスクトップの「地価」に気付いて、時計を右上に移動してみた。本当は、メインディスプレイ右のサブディスプレイに置くのが最適なのだが、Thunderbird, Spotify, Spotifyとgmusicbrowserのミニプレーヤと、さまざまなものを詰め込んでいるために、ほとんど空きがない(そこまで詰め込まなくてもいいとは思うのだが、メインディスプレイに余裕を持たせたいのだろう)。左端の中央だけは奇跡的に空いているが、あまり落ち着かない。一方、メインディスプレイの右上は空いているし、(日本語や英語の)文字が左から右に書かれる関係でウインドウの表示も右側が空いている場合が多いので、あまり邪魔にならなそうだと思ったのだ。

それで、時計を右上に置き、透過率を調整して常に最上層で表示するようにして試してみたら、結構良さそうだ。ただ、少し使ってみたら、ちょっとした問題に気付いた。ウインドウの操作ボタン(閉じるなど)が右上に配置されているので、その部分が時計の下にある時には操作できなくなってしまうのだ。それで、操作ボタンを左側に移動した。その時、普通は閉じる(×)ボタンを一番外側に配置するだろうが、不意に押して閉じてしまうのを防ぐため、敢えて内側に配置した。何となくMacに近づいてしまった気がするが、偶然だw それに、閉じるボタンの(変態的な)位置はオリジナルだ。これなら大丈夫そうだ。

(12/5 6:47) PS2に書いたように、バーの幅を2行にすると、不格好ではあるのだが、時計(元々の時計とは異なる)がバーの中に入り、そもそもの問題(左上の時計が邪魔)も解決できそうなことが分かったので、少し試してみることにした。あとで気付いたのだが、これなら、ウインドウ操作ボタンは元の右側で大丈夫だ。

サイドバーの幅を2行にしてみた。

(12/5 17:06) 一日使ってみたのだが、どうにもダサく(無駄な隙間が多いが、設定などでは解消できない)てしっくり来ないし、時計も小さくて見にくいので、いろいろ調整したが駄目なので、元の状態(バー: 1列、時計: 右上、ウインドウ操作ボタン: 左)に戻した。

(12/5 21:12) バー最上部のデジタル時計とアナログ時計が左右に泣き別れ状態なのがどうも気に入らないし不便なので、どうしたものかと考えていたら、コペルニクス的転回(いつもながら大げさだw)で、サイドバーを右に移してみた。まあ、慣れるまでは大変だが、時計がまとまっていい感じだ。そして、やる前は、バーのアイコンを押した時にメニュ―などが右に出て悲しいことにならないかと思っていたのだが、予想外にちゃんとしていて、そんなことはなかった。しかも、芸が細かいことに、メニューが出るボタンのマーク(▶)も◀に反転していたのだ。これはすごく意外で、「やればできる子じゃん!」と思ってしまったw

(12/5 21:25) 今気付いたが、これの欠点は、仮想的に一つの画面を構成する、メインとサブディスプレイがサイドバーで分断されてしまうことだ(「ベルリンの壁」?)。ただ、現実には一つのウインドウをメインとサブディスプレイにまたがって表示することはない(可能だが、使いにくいのでしない)ので、概ね大丈夫そうだ。あとは、バーが右にあって本当にいいのかという懸念はある。バーのように頻繁に使うものは、地価の高い左にあるべきなのかも知れない(例えば、マウスの移動量が増えそうだ)。まあ、おいおい分かるだろう。

 

(12/5 6:06 一部の画像を改良、若干修正; 12:03 わずかに加筆)

PS. WindowsやmacOSではどうだか知らないが、Linux Mint (Xfce)では、追加ソフトなどは不要でウインドウ操作ボタンの移動や配置換えが簡単にできるのが嬉しかった。

PS2. そういえば、もう一つ問題があった。サイドバー(通常はディスプレイ下部のタスクバー)が混雑していて、ウインドウが多いと足りないことがあるのだ。下部ならまず不足しないが(ただ、横長ディスプレイを有効に使うために横に置いているので、下に置くことはありえない)、横なので、アイコンを置ける数が少ないのだ。

バーの幅は広くできるが、不格好になってしまうのでなかなか解決できない(アイコンが増えた時だけ広くなるとかできればいいのだが・・・)。とりあえず、アイコンを小さ目にして対処しているが、焼け石に水だ。 (12/5 6:28)

ただ、不格好なのを我慢して設定を調整したら、まあまあ許せる感じになった。 (12/5 6:40)

  •   0
  •   1

先日書いたように、JACKのパッチベイアプリ、Catiaの動きがどうも怪しい(勝手にPulseAudioを直結する)ので、代わりにPatchageを動くようにした。

Patchageの問題は、起動するとすぐに下記のエラーで強制終了してしまうことだ。

BDB2034 unable to allocate memory for mutex; resize mutex region
cannot open DB environment: Cannot allocate memory
Segmentation fault

メモリ不足と出ているので、設定で直らないかと思って調べたのだが、関係するものは見つからなかった。それで、このエラーがどこから出るか調べたのだが、実は2箇所に分かれており、最初の2行と最後の行は別の要因で出ているようだ。ただ、最初の問題があるために2番目の問題が出ている可能性もある。

まず、最初の問題(BDB2034)は、JACKのライブラリ(libjack)の関数jack_client_open()で起こっていることが分かったが、原因は分からない。検索すると、このエラーは他のプログラムでも出るのだが、明確な解決策はないようだ。また、他のJACKクライアント(例: jack_lsp)でも出るが、問題なく動作しているので、致命的な問題ではなさそうだ。近頃Linuxのカーネルを更新したので、それに関係しているのかも知れない。それで、ひとまずこの問題には対処しないことにした。

次に、2番目の問題(Segmentation fault)もJACKライブラリの関数jack_get_property()の中で起こっていることが分かった。jack_get_propertyの使い方は正しいようなので、JACKライブラリ自体の問題か、関数の仕様が変わったのかも知れない。あと、記憶ではしばらく動いていたので、何度も試行錯誤するうちにシステム(OS?)の状態がおかしくなっているのかも知れない(そうであれば、再起動すれば直るだろう)。あるいは、上に書いたようにLinuxのカーネルを更新した影響かも知れない。幸い、この関数は1回しか使われておらず、しかも、その処理をスキップしても大きな問題がないので、そうすることにして無事動くようになった

ただ、前にも書いたように、使い勝手の問題があったので、それも何とかした。一番大きな問題は、ウインドウ内のJACKクライアント(モジュール)の表示位置が保存されない(再起動すると位置がおかしくなる)というものだ。ただ、Patchageのウインドウを見ると、全部のクライアントの位置が保存されない訳ではなく、入力または出力だけのものが駄目(入出力があるものの位置は保存される)なことが分かったので、その部分(Configuration.cpp: Configuration::save())を修正した。

それから色を調整して(プログラムの変更は不要)、最終的には大分いい感じになった。これなら、充分にCatiaの代わりになりそうだ。

思ったより簡単にできて気分がいいが、前にも書いたように、やっぱりJACKは枯れていないことを実感した。あと、この修正を作者に知らせるのはいいと思うのだが、今まで(別のプログラムで)何度も無視されて来たので、躊躇している。

(15:32) 気分が良かったのも束の間で、Patchageを使っていても変な接続が起こってしまった。結局、システム(JACK、PulseAudio、OSのいずれかまたは全部)がおかしくなっていたようなので、再起動したら、すべての問題が起こらなくなった(Catiaでの勝手な接続も、Patchageがエラー(BDB2034やSegmentation fault)で起動しないのも起こらなくなった)。とりあえず直ったのはいいが、原因不明なのでまた起こる気がする。

そして、Patchageのクライアント位置の保存の修正は有用だが、Catiaに問題がなかったので、わざわざ使う理由がなくなってしまった。まったく何とも言えない・・・

 

補足: プログラマーは、プログラムを修正することや修正のためのモジュールを「パッチ」と言います。単純なバグ修正の場合も多いですが、(何だか良く分からない問題などで)根本を直さずに対症療法的に修正することをそう呼ぶことも多いです。Windowsで山ほどあるもの(KB*)ですw

  •   0
  •   0

(12/1 15:42訂正) 新しい投稿にも書きましたが、本文の勝手に接続される問題は、Catiaが悪いのはでなく、システム(JACK、PulseAudio、OSのいずれかまたは全部)が異常になっていたためなので、初めに訂正します。


昨夜だったか今朝だったか、JACK(Linuxのオーディオ)のちょっとした問題(余計な信号入力ができてしまう)を修正しようとしていたら、動きがおかしくなった。なぜか、PulseAudio(もう一つのLinuxのオーディオ)の接続が勝手にできてしまって、本来の接続と重複してしまうのだ。接続図を使って説明すると、本来は、信号を

本来の接続

のようにA→B→C→Dと接続しているのに、なぜか、

おかしい接続 (再現図: 赤枠内が余計)

のようにAとDを直結する接続(図の赤枠内)ができていることがあるのだ(この状態で音を出すと確実におかしくなる)。それで、自作のJACK開始プログラムの不備かと思って修正したり、PulseAudioの設定も変えてみたりしたのだが、一向に直らない。ところが、ふと、Catiaというパッチベイ(音の配線をするもの。上図がそう)アプリを起動したり起動していると問題が起こることが多いことに気付いた。それで、試しに別のプログラムにしたら嘘のように問題が起こらなくなった。それでCatiaが悪さをしている(自分で接続状態を保存しているのか、頼んでもいないのに勝手に配線するようだ。日本人でもないのに、余計なお・も・て・な・しはやめろ! むしろ空気読めよ、クソボケw)ようなので、使わないことにした。

そういえば、この問題は以前にもあった覚えがあるし、最初に書いたそもそもの問題もCatiaが原因だったようだ。確かに、接続を見るとおかしくなっているのだが、再生していておかしいと感じたことはなかったので、Catiaを起動する時におかしくなっていた可能性が高い。

が、「別のパッチベイプログラム」といってもいいものがない。いくら探してもほとんどなかった。一番まともなのはClaudia(開発元はCatiaと同じ)だが、使い勝手がCatiaに劣る。次はPatchageだが、何度も試行錯誤したせいか、エラーで起動しなくなってしまった。OSを再起動すれば直るのだろうが、問題が起こるたびに再起動したくはないので、使いたくない。そもそも、Patchageは使い勝手も余り良くない(QjackCtlやPatchMatrixの10倍くらいいいが・・・)。

CatiaやClaudiaだの、名前が紛らわしいアプリが何個もあって、しかも、それぞれの機能や操作性が微妙に違うのを見ると、開発元(KXStudio)はなってないと思う。まあ、お世話になっているし、そもそも、中身がどうであろうと使える物を出すことは重要だし、"Studio"とは書いているものの、個人でやっている雰囲気もあるので強くは言えないが、もっとうまくやればいいのにと思う。同じ部分には同じ部品を使えば(当たり前のことなのだが、それができない)、機能や操作性が同じにできるうえに、手間も省けると思うのだが・・・

やっぱりCatiaが使えないものかと思って、プログラムの取得元を変えてみることにした。今まではOSのパッケージ版を使っていたのだが、開発元(KXStudio)の版はパッケージのものとは違う(開発元のものなのに、なぜかバージョンが古い)ので試したら、ちゃんと動いた。気持ちが悪いが、とりあえずは今までどおり使えるようになったので良しとした。が、また忘れた頃に問題が出て、今日のように無駄に苦しみそうだ。

(20:57) 早くもその問題が出た。古いCatiaもClaudiaも、起動すると勝手に接続してしまう(それらを起動せずに別のプログラムで接続一覧を出すとその接続はないので、確かだ)。なかなか困った。。。

(12/1 8:24) その後、Catiaの設定を削除すると問題が起こらないことが分かった。何かの設定が悪いのだろうか。いずれにしても、どうせそのうち駄目になりそうだ。なお、Patchageの設定を削除しても、エラーは直らない。

JACKは僕にはすごくいい(でも、何がいいのだろうか? テクニカルなところか?w)のだが、情報は少ないし、そのせいで最初にまともに使えるようにするのが大変だし、今回のように、たまに変な問題が起こったりするせいか、余り使われていないようで、いいアプリが少ない点が難点だ。それに、システムもアプリも古く、10年くらい前から更新されていないものがザラにある(それでもちゃんと動くところがすごい)。ユーザーが減って、誰も新しいものを作る気がなくなってしまったかのようだ。みんなはどうしているのだろうか? Linuxでまともにオーディオや音楽をやる人は絶滅してしまったのだろうか。演奏のミックスやマスタリングなど、ヘビーに使う人はMac(かWindows)に移り(というか、最初からLinuxに来てもいないw)、Linuxの残りの人はPulseAudioで音が出れば事足りているのかも知れない。確かに、配線とかイコライザとか細かくをいじる人でない限り、PulseAudioで充分ではある。

 

蛇足: 題の「枯れる」は、僕らは、ソフトなどを作ってから時間が経って、(不具合が出尽くして、)落ち着いた状態を差します。そういう意味で、JACKと関連ソフトは随分時間は経っているものの、まだまだ枯れていないようですが、その前に朽ちているのかも知れません。将来が心配です。

  •   0
  •   0