全く異なる2つのソフト(Tcl/Tk, digiKam7)に関する話だが、どちらも小さいこと(でも、すごく苦労したものもある)なので一つの稿に書く。いずれも、本来はそれぞれのソフトのフォーラムなどに書くべきだが、フォーラムがなかったり(digiKamにはバグ報告の手段はあるが、KDEのBTSなので なんか気軽に書けない雰囲気だった)、ソフトが余りにも古くて(Tcl/Tk)、フォーラムがあるか調べるのも無駄そうだし(→ 現代的なフォーラムはなかった。大昔の「ニュース」(アーカイブ?)だけだった)、連絡しても修正されそうもない気がするので、とりあえずここに書くことにした。

こうして書けば、少なくとも日本(語)の人には検索されるだろうし、今は海外でもキーワードが翻訳されて検索にヒットするようなので、全くの無駄ではないと思う(そもそも、本文に英語のキーワードも書いてあるから、やる気のある人は そこだけ見ればパッと分かりそうだw)。それから、題やカテゴリではLinuxとしているが、実際にはどちらも他のOSでも動く。が、Linux以外で問題が起こるかは不明だ。

(10/4 15:53 その後もう一個対処したので、3として追記する。)

 

1. Tk(wish)のtextウィジェットの高さがおかしくなる。

問題の詳細

一つのtextウィジェット(ワードラップ)にサイズの異なる(タグで指定する)数種類の文字列を入れて表示すると、Tkの認識する高さ(表示行数)と実際が食い違って、高さが低く表示され、文字列の終わりの方が表示されない場合がある。一行が長くて自動改行(wrap)される場合に起こりやすいが、一つのtextウィジェット中に複数のサイズの文字列が存在することが大きいようだ。

以下のような3つの部分からなる内容(各部分を指示しやすくするために、それぞれの頭に番号を付けた)のtextウィジェットを約250pxの幅、ワードラップで表示すると、最後の3の部分(アルバム名)が途中(ラップで改行する手前)で切れる

  1. 北ウイング - 30th anniversary mix
  2. 中森明菜
  3. ベスト・コレクション 〜ラブ・ソングス&ポップ・ソングス〜 (2012)

表示例(左側がおかしい)

原因(推定)

一つのtextウィジェット内で複数のフォントサイズを使い、ワードラップをさせている場合に、Tk内部の表示行数(displaylines)の計算・処理がおかしくなるようだ。

上の例の場合、textウィジェットのdisplaylinesは6(この値は表示されている行数の5より多いので、ある程度はサイズの違う文字列への対応がされているが、完全でないように思える)だが、それを高さ(configure -height)に設定すると不足する(この場合は7でないと完全には表示されない)。

対処

textウィジェットのフォントサイズの異なる部分ごとに高さ(displaylines)を求め、それらの合計を高さに設定する。

上の例では、1(曲名)、2(アーティスト名)、3(アルバム名)の各部分で高さ(部分の先頭から最後の文字までの表示行数: 例: .textWidget count -displaylines 1.0 end)を求めたら、それらの合計は7行(上: 3, 1, 3)となり、正しい高さで表示された。ただ、2の部分は改行を除外しないと1行高くなってしまうので、謎はある。

また、正しい高さで表示されれいる場合でも、全体の高さ(表示行数)を求めると6行のままなので、Tk内部の行数の処理がおかしいようだ。

なお、表示が完全か(目視以外で調べる)は、textウィジェットの外側(親)の高さ(なぜか正しい)とtextウィジェットの高さ(どちらもpx単位)の比較と、textウィジェットのyviewの内容から判定している。

この時、textウィジェットのsyncコマンドでは表示(内部的な処理?)が完全に終わらないようで、取得できる値がおかしいことがあるので、Tcl(Tkでない)のupdateコマンドを実行する必要がある(最初はこれが分からずに苦労した)。

上の例では、textウィジェットはgridウィジェットで配置しているので、外側(親)の高さはgridのtextウィジェットを配置している行(row)のbboxから求められる。また、textウィジェットの高さはyviewから求められる。また、yviewが空だったり、yviewの最初と2番目の要素が0, 1.0でない場合(例: 0.0, 0.8)には表示が完全でない(欠けている)。ただ、2番目の要素(最後に表示されている文字列の割合)はいつも1.0になる訳ではなく、1.0に近い値(例: 0.98)でも「完全」とみなす(許容する)必要がある(あるいは、最下部に広目の空白が入ること許容することで1.0(全く欠けがない)を守れるが、見た目が良くない)。

結果

以下のように、Minispの表示が正常になった。30曲くらい再生して表示を確認しているが、今のところ問題が起こっていない。備考に書いた高さの調整処理も行われていない(最初に設定した高さのままで完全に表示されている)。

備考

簡単に書いたが、何が原因で表示がおかしくなるのか分からず、調査にも対処にもとても苦労し、時間が掛かった。

なお、上記のようにまだ謎があるため、textウィジェットの高さの計算がうまく行かなかった場合に備えて、表示(高さ)を調整する処理も実装した(実はこれを先に作った)。基本的は処理としては、textウィジェットが完全に表示されているかを調べ(上記の方法)、そうでなかったら、完全になるまで1行ずつ高さ(行数)を増やすものである。また、高さが高過ぎた場合には減らす必要があるので、その処理も実装したが、今は使っていない。

この問題は、PCのOSをLinux Mint 20に更新した時に自作のSpotifyのミニプレーヤー(Minisp)で再発した問題である。以前は原因が分かっていなかったので、対処が不充分・不的確だった。

 

2. digiKam7でGoogle mapsの地図が表示されない。

問題の詳細

位置情報のある画像の地図をGoogle mapsで表示しようとすると、地図ペインが空白のまま。また、小さいおかしなウインドウが出て消えない。

なお、地図がMarble Virtual Globeの場合は問題ない。

原因(推定)

digiKam7がルート証明書(libnssckbi.so)がロードできない。digiKam7の想定するディレクトリ構造と実際の位置が異なるためのようだ。

Ubuntu 20系の場合、libnssckbi.soは/usr/lib/x86_64-linux-gnu/nssにあるが、digiKam7は/usr/lib/x86_64-linux-gnuを想定しているようだ。

digiKam7のログに以下のように出るので分かる。

[12345:23456:1234/23456.34567:ERROR:nss_util.cc(748)] After loading Root Certs, loaded==false: libnssckbi.so: cannot open shared object file: No such file or directory
[12345:23456:1234/23456.34567:ERROR:cert_verify_proc_nss.cc(969)] CERT_PKIXVerifyCert for maps.google.com failed err=-8179

対処

ライブラリのパスにlibnssckbi.soのあるディレクトリ(Ubuntu 20系でx86の場合、/usr/lib/x86_64-linux-gnu/nss)を、以下のいずれかで追加する。

  • digiKam7を起動するシェルなどの環境変数LD_LIBRARY_PATHに追加する。
    • 例: export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/nss:$LD_LIBRARY_PATH
  • AppImage中の起動スクリプトAppRun内のLD_LIBRARY_PATHに追加する。
    • 例: export LD_LIBRARY_PATH=$DIR/usr/lib/:/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/nss:$LD_LIBRARY_PATH

念のため、上では/usr/lib/x86_64-linux-gnuも追加した。

AppRunを見るには、AppImageのファイルに--appimage-mountオプションを指定して起動する。 → マウントポイント(/tmp/.mount_digika*)直下にAppImageがある。

修正したAppRunでdigiKamを起動する方法は各自で考えること(一番簡単なのは、AppImageを展開して修正することである)。

なお、消えない小さいウインドウは、地図表示がエラーの時に出るようなので、一旦、地図を表示しないようにしてdigiKam7を再起動すれば出なくなるし、地図が正常に出ていれば出ない。

結果

digiKam7の地図のペインにGoogle mapsの地図が表示されるようになった。

備考

digiKam5の時も同様な問題があり、その時はGoogle mapsのAPIキーが期限切れで出なくなっていたので、今回もそれかと思ったが違っていた。digiKam7は今年の7月に出て、落ち着いてから移行しようと思って居て、もういいかと思ったのだが、まだ早過ぎたようだ。

こういう問題が起こるのは、digiKam7がOSのパッケージでなく、AppImageという(良く分からないけど、)手抜き的なパッケージで配布されているからだ。もちろん、数多くのディストリビューションごとにパッケージなんて作ってられないのは分かるが、始末が良くない話だ。実際、digiKamはAppImageのために日本語入力できないという問題もある(これも、以前自力で解決した)。

その後、PS2の問題(マウスカーソルがおかしい)を調べているうちに、どうもdigiKam 7はまだ駄目な気がして来た。digiKam 7にして良くなったことは特にない(むしろ、悪いことが多い)ので、digiKam 6に戻した。もう少ししたら試してみたい。 (10/2 13:31)

 

3. Spotifyの音量がなぜか下がることがある。

問題の詳細

Xfce4のパネルやJACKを再起動すると、Spotifyの音量が下がる(大体7dB以上下がるので、半分以下になる)。

原因(推定)

パネルのPulseAudioプラグイン(実体はlibpulseaudio-plugin.so)が再起動する時に悪さをするようだ。それを無効にしたら、パネルやJACKを再起動してもSpotifyの音量が下がらなくなったので。

ただ、なぜJACKを再起動するとPulseAudioプラグインが再起動するのかは不明(正確には、この時はPulseAudioプラグインが再起動したかは確認しなかったので、別の経路なのかも知れない)。

対処

PulseAudioプラグインを使うのを止め、同等の機能のアプリ(pavucontrol)を使うことにした。僕はJACKを使っているからPulseAudioの調整はほとんどしないので、アプリで充分だ。

結果

パネルやJACK(、もちろんpavucontrolも)を再起動してもSpotifyの音量が下がらなくなった。

備考

どうも、Mint 20のXfce4にはいろいろバグが多い感じだ。digiKamの外に こっちも早まった感じ・・・

余計かつまともに動かないものは入れておきたくないので、PulseAudioプラグインなど(下記)を削除(アンインストール)した(PulseAudioプラグイン以外は動くが余計)。

xfce4-pulseaudio-plugin xfce4-xapp-status-plugin xfce4-eyes-plugin xfce4-verve-plugin

(10/4 15:53 追記)

 

PS. 書いたあとで気付いたが、BTSとかTkとか、偶然だけど音楽の意味もあって なかなかおもしろいw

PS2. digiKam7にはもう一つ気に入らないことがある。マウスをサムネイルに載せた時のカーソルが酷いのだ。6では普通だったのに、「1980年代ですか?」って感じだ。いつも思うが、KDEの(アプリ以外も)センス(デザイン以外も)は全然好みでない。でも、他にいいアプリがないから使っている。

ちなみに、このカーソルのファイルがどこにあるのか分からず、なかなか直せない。 (10/2 4:58)

気に入らないdigiKam7のマウスカーソル

(10/2 11:19) いろいろ調べたり試したりしてみたのだが、直接的には、digiKam7が使うQt5のアイコン(Qt::PointingHandCursor: 指で指す形状)が見つからないようで、その代替としてX11のcursorフォントの文字hand1(0x3a)が使われているようだ(だから、80年代は当たっていたw)。

どうも、digiKam7のAppImageとOS(Linux Mint 20)の折り合い・相性が悪い感じだ。ただ、digiKam6では同じ環境で問題なくそのカーソル(実は、このカーソルもそんなにいいとは思わないが)が出るので、(本文に書いた)Google mapが出ない問題と同様にdigiKam7側に何か問題があるように思う。それが何かはまだ分からない。

いずれにしても、ちょっと早まってしまったようだ。。。

  •   0
  •   0

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL