ciguwerao

2017/06/14の記録:ちょっとした実験

久しぶりにフラッシュプレイヤーの更新があった。

このブログの右のメニューの下の方に、アドビのフラッシュプレイヤーのバージョン確認ページヘのリンクがあるので、どのような環境の方も最新のものになってるかどうか、確認されることをお勧めする。

それはそれとして、僕の場合Debianでは手動でアップデートしなきゃならんので、その作業をやった。

Firefox(その他)用の "flash_player_npapi_linux.i386.tar.gz" と、Opera(その他)用の "flash_player_ppapi_linux.i386.tar.gz" とを落としてきて、解凍した書類を適切なところに入れる。

そのやり方は前に書いたのでそちらを参照していただきたいが、前者の方は、解凍すると "usr" というフォルダができ、その中に "share" というフォルダがあり、さらにその中にはアイコンのたぐいが入っている。

大事なのは "libflashplayer.so" という書類だけでアイコンは別に毎回更新することもないのだが、今回はやっておこうと思った。

が、更新が久しぶりだったので、各種アイコンを
/usr/share/
以下に入れるんだったか
/usr/local/share/
以下に入れるんだったか、忘れていた。
(僕自身がどちらに入れてきたか、という話で、どっちに入れても機能はする)

確認してみると、どっちにも入っている。

前にやった時に、その時の気分で適当に入れたと思われる。

これも前に書いたが、自分でなにかインストールするときにはとりあえず
/usr/local/
以下に入れとくのがルールになってる様なので、こっちが正解と見て、今日はこっちにしといた。

これで更新完了なのだが、それはそれとして、上の二つの選択肢の両方に同じ名前の書類を入れた場合どっちが優先されるのかが気になったので、実験してみた。

予想では後者優先。

で、後者の方に入れた(更新した)
/usr/local/share/icons/hicolor/16x16/apps/flash-player-properties.png
と、同じ所に入ってた
/usr/local/share/icons/hicolor/16x16/apps/vivaldi.png
とで、名前を入れ替えてみた。

結果は次の写真のとおりで、vivaldiのアイコンがflashplayerのものになっている。

予想が正しかったということ。

まあそうだろうな。

以上、非常に個人的なメモ。

| Linux関連 | 19:34 | comments(0) | trackbacks(0) |

2017/04/21の記録:IcedoveがThunderbirdへ

メモ。

環境はDebian Jessie。

IcedoveがThunderbirdに切り替わった。

に記事にしたIceweaselからFirefox ESRへの切り替えの時から予想できたことで、むしろ、なかなか切り替わらないな、と思っていた。

ついにその時が来たか、という印象。

アップデート直後にはまだメニューにIcedoveが残っていたので一旦それを起動させてみたら、自動でデータを移してくれたみたいだ。【

一回やるともうIcedoveはメニューから消えていた。

寂しいことだ。

メニューには当然Thunderbirdも追加されたわけだが、「Thunderbird電子メールクライアント」と表示されていて、うるさい。

「電子メールクライアント」は削った。

メニューの当該部で右クリック、「プロパティ」をやって削るわけだが、そうすると
ホーム/.local/share/applications/
に自動的に新しくデスクトップエントリファイルが作られるように、LXDEはなってる。

他の環境のことは知らないが、自分でそういう作業をすれば同じことになるだろう。

/usr/share/applications/thunderbird.desktop
をコピーして持ってくる。

このファイルを直接いじるという手もある(要root権限)。

デスクトップ環境にもよるんでないかと思うが、このファイルはファイルマネージャ上では「Thunderbird電子メールクライアント」という名前で出てくるので、それをエディタで開いて、"Name[ja]" の行をいじる。

(今自動で作られたやつを確認してみたら、"Name[ja]" の行は「Thunderbird電子メールクライアント」のままで、"Name[ja_JP]" という行が別に追加され、そっちが「Thunderbird」になってる。が、自分でやるなら "Name[ja]" をいじればいいと思う)

== 04/25追記 ==

後で気づいたのですが、データを移したわけではなくて、もともとのIcedoveの個人データが入ってる
ホーム/.icedove/
というディレクトリを残したまま、それへの、Macで言うところのエイリアス、シンボリックリンクが
ホーム/.thunderbird
という名前で作ってありました。

いらないものを置いておくのは好まないので、シンボリックリンクは捨てた上で、".icedove" の名前を ".thunderbird" に変えてみたら、それで問題なく機能しました。

== 04/26追記 ==

母のところに行く用があったので、いつものようについでに母のパソコンのアップデートもしました。

母のパソコンにもDebian Jessieを入れていますので、当然、この記事で書いたことが起こるわけですが、何故かは知りませんが僕のパソコンで起きたことと多少の違いがありましたので、メモしておきます。

まず、パッケージマネージャでアップデートをやってThunderbirdがインストールされると、その時点でメニューからIcedoveが消えていました。

また、(これはもともと僕のとは違い)下のアプリケーション・ランチャーに入れてあったIcedoveは、そのまま残ってはいたものの押しても機能しなくなっていました。

メニューから(自動で付け加わった)Thunderbirdを起動させると、僕のでメニューに残っていたIcedoveを起動した際と同様に、自動でデータの引き継ぎ(上の追記に書いたようにシンボリックリンクが作られる)をやってくれ、Icedove時代と変わりなくThunderbirdが使えるようになりました。

つまり、IcedoveからThunderbirdへ切り替わった際は、Thunderbirdの初回起動時にデータ処理を自動でしてくれる、ということで、それはいいのですが、アプリケーション・ランチャーのほうが手間取りました。

アプリケーション・ランチャーのIcedoveは機能しなくなったので、それは削除しておしまいですが、代わりにThunderbirdを入れようと「アプリケーション・ランチャーのところで右クリック>アプリケーション・ランチャーの設定」をやっても、Thunderbirdが追加項目の選択肢に出てきません。

Thunderbirdへの切り替えがアプリケーション・ランチャーの設定アプリケーションが利用するデータに反映されていない、ということでしょう。

仕方ないので、
ホーム/.config/lxpanel/LXDE/panels/panel
という書類をエディタで開いて、

    Button {
      id=pcmanfm.desktop
    }
    Button {
      id=menu://applications/Internet/firefox-esr.desktop
    }

となってる部分に

    Button {
      id=menu://applications/Internet/thunderbird.desktop
    }

を付け加えることで対処しました。

| Linux関連 | 11:22 | comments(0) | trackbacks(0) |

2017/04/13の記録:Recollの不調

メモ。

環境はDebian Jessie LXDE。

ファイル検索ソフトとして、 "Recoll" というのを使っている。

その詳細については2014/09/16の記録に譲るが、左上のアイコンや "Tools" メニューから行える "Advanced/complex Search" がうまくいかず、それをやろうとすると機械は延々と動き続けるもののRecollがうんともすんとも言わなくなってしまうことに気づいた。

いつからそうなったかは今となってはわからないものの、ひと月ほど前にやった比較的大きなアップグレードでどうやら仕組みが大きく変わったらしかったので、問題はそこにあると踏んでそれ以前の状態に戻すことを考えた。

ひと月ほど前にやったアップグレードというのは、パッケージマネージャで
http://www.lesbonscomptes.com/recoll/debian/
という専用のリポジトリを追加して行った(やり方は公式ページの当該部分参照)のだが、今回、この専用リポジトリを無効にした上で一旦Recollそのものをアンインストールし、再度インストールし直すことにした。

Recollのバージョンが最新のものからDebian Jessie公認のものに下がる。

これでこの前のバージョンアップに伴って生じた不具合が避けられると思ったのだが、案に違って状況は変わらない。

症状は作業前とまったく同じく見えた。

というわけで、馬鹿馬鹿しいが専用リポジトリを再び有効に戻したあとでアップグレードをし、作業前の状態に戻した。

別の方向性を探り、Recollの設定ファイルを探してみると、どうやら次の二つのディレクトリにあるらしい。

  • ホーム/.recoll/
  • ホーム/.config/Recoll.org/

このうち前者の方が中が複雑になっていて、検索用に作られるインデックスなんかはこっちにあるらしい。

こちらは後回しにして、とりあえず後者の方をディレクトリごとゴミ箱に放り込んでからRecollを起動させ、Advanced/complex Searchをやってみると、当たり前のようにその専用ウィンドウが開いた。

試しに適当に条件を入れて検索してみても、特に問題なく機能する。

拍子抜けするほどあっさりと問題が解決した。

バージョンダウンとかする前に、こっちを先に試せばよかった。

これはあくまで僕の推測だが、この前のバージョンアップから不具合が生じたというのは当たっていて、その際にこのディレクトリにある設定書類の書式か何かが変わったのを、うまく引き継げなかったのではないかと思う。

それを捨てたので、また新しく適切なのが作りなおされ、うまく機能するようになったのではないか。

| Linux関連 | 18:40 | comments(0) | trackbacks(0) |

2017/04/05の記録:フォント設定メモ

環境はDebian Jessie LXDE。

僕はPlayfair Displayというフォントを気に入っていて、
ホーム/.config/fontconfig/fonts.conf
という書類でこれはセリフフォントですよ、という指定をした上でセリフフォントの筆頭に置いているのだが、今日ちょっと用があってLibre OfficeのWriterをいじっていて、ローマ字仮名まじりの文を試しにPlayfair Displayで表示させてみたら、ローマ字はちゃんとPlayfair Displayになるものの、仮名の部分がセリフ=明朝で表示されず、サンセリフ=ゴシックのVL PGothicで表示されてしまうことに気づいた。

世界標準のセリフフォントであるところのTimes New Romanを指定した場合は、問題なく明朝フォントが使われる。

Playfair Displayがセリフフォントであるという指定がうまくいっていないと考えられる。

/etc/fonts/conf.d/
というディレクトリに "46-latin-plus.conf" という書類を作り、"45-latin.conf" に倣って

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

<!--
  Serif faces
 -->
  <alias>
    <family>Playfair Display</family>
    <default><family>serif</family></default>
  </alias>

</fontconfig>

と書いてシステムを再起動してみた。
(その後いろいろ試しているうちに別にシステムの再起動は必要なく、Libre Officeだけ再起動すれば良いことがわかったが)

思ったとおり機能して、Playfair Displayがカバーしていない仮名の部分は明朝系の日本語フォントで表示されるようになった。

これはこれで良いのだが、できれば
/etc/fonts/conf.d/
をそのままいじるのではなく、ローカルの設定をしたいと思ったので、"46-latin-plus.conf" は削除した上で、ローカル設定書類であると思われる
/etc/fonts/local.conf
にまったく同じ内容を書いてみた。

が、これではうまく機能しない。

今回書いたような内容は、この書類では機能しないようだ。

そもそも、もともと使っていた
ホーム/.config/fontconfig/fonts.conf
という書類は "local.conf" の個人設定版と言えるものだと思われるので、そっちで機能していなかったということは "local.conf" でも機能しなくて当然なのかもしれない。

これらの書類が機能するのはどういう場合なのかはよく分からんが。

もうひとつ、
/etc/fonts/conf.d/50-user.conf
という書類を見ると、
ホーム/.config/fontconfig/conf.d/
というディレクトリを作れば
/etc/fonts/conf.d/
でするような設定を個人設定としてできるっぽく思われたので、試しにそっちに "46-latin-plus.conf" を置いてみた。

が、これも機能しなかった。

結局おとなしく、
/etc/fonts/conf.d/
に "46-latin-plus.conf" を置くことにした。

ついでに、Playfair Display以外にも "45-latin.conf" で漏れているセリフフォントがあったので、全部 "46-latin-plus.conf" に書いておいた。

ところで、上で使った写真で (Source Han Serif) と書いてあるが、ここまでの内容にはSource Han Serifは全く関係ない。

何でこんなことが書いてあるかというと、昨日新しく出たSource Han Serifを試し、2015/08/04の記録を使って確認してエムダッシュがつながると喜んだのだが、MacのSafariでも試してみたら雲行きが怪しくなったので、いろいろ確認していたのが事の発端だから。

DebianでもMacでも、Operaなら2015/08/04の記録の(昨日新たに付け加えた)Source Han Serifのところを見ると、ちゃんと一文字幅のきれいなエムダッシュが表示されるのだが、Safariでは、つながってるにはつながってるのだが、一文字幅ではない上にややぶっとく、きれいとは言いがたいエムダッシュが出てきてしまう。

OperaのきれいなエムダッシュはSource Han Serifのエムダッシュではないのではないか、という疑いが出てきてしまったのだ。

で、DebianのLibre Officeに2015/08/04の記録から当該部分をコピーして試してみたら、残念ながら、やっぱり無様なエムダッシュになってしまった。

(ちなみにMacのLibre Officeでも結果は同じ)

きれいなエムダッシュはSource Han Serifのエムダッシュではないと判断せざるを得ない。

ならこれは何なのか。OperaがSource Han Serifの別の文字、例えばホリゾンタルバーを気を利かせて呼んできてくれてるのだろうか。あるいは別のフォントから呼んできているのだろうか。

そもそもLibre Officeでの無様なエムダッシュも、Source Han Serifのエムダッシュなわけではないかもしれない。別のフォントのエムダッシュが表示されてるのかもしれない。そうだとすると可能性としては標準のセリフフォントのエムダッシュが呼び出されているのではないか。僕はPlayfair Displayを標準に設定しているはずだ。Playfair Displayならどう表示されるか。

という流れで、この記事の冒頭につながるわけである。

もちろん、Source Han Serifのエムダッシュ問題の解明は、一切進展していない。

| Linux関連 | 12:17 | comments(0) | trackbacks(0) |

2017/03/06の記録:前言を撤回しなければならない事案について

前言を撤回しなければならないことがある。

どんなに誠実に生きたいと希求し、そう努めていたとしても、残念ながらそのような事態を完全に避けるのは難しいのだろう。

僕は、誠実に生きたいと希求してはいるものの、そのための決意も努力も甚だしく不十分であるようで、このブログでも度々、前言を翻してきた。

リナミンシナモンパソコンを購入してからまだ、ひと月が経つか経たずか、というくらいだが、早くもいくつか、ここで書いたことを撤回せねばならない。

まず、システムの標準フォントについて。

最近はいつでもどこでもVL PGothicを偏愛して使っているが、せっかくLinux MintのCinnamonいう新しい環境を使うことになったのだから、そのリナミンシナモンがNoto Sansをデフォルトに指定していることに敬意を表して、Noto Sans CJK JPを標準で使っていこうと思う、と書いた

これを撤回する。

VL PGothicの柔らかいラインにあまりにも慣れ親しんでしまった僕にとっては、Noto Sans CJK JPの硬い、ゴツゴツした字体が心に刺さる。

心が傷だらけにされてしまうようだ。

この前書いた
ホーム/.config/fontconfig/fonts.conf
という書類で、VL PGothicとNoto Sans CJK JPとの順番を入れ替えて、VLPが標準になるように改めた。

ふたつ目。

前回3つめの項目で、Linux MintのテーマはXからYへと移行される過程にあるようだということを書き、そうであるならば移行を先取りして、早いうちからYに慣れ親しんでおくべく試しに使ってみて、悪くなさそうに思ったので早速切り替えてYを使っていくことにした、と書いた。

これを撤回する。

その理由はまず、実は前回使ったこの写真をよく見てもらえばわかるのだが、

Yのアイコンはすべてを網羅しているわけではなく欠けているものがあって、そうしたものについてはXのアイコンが出てきてしまうことに気づいた。(上の写真で言えば左下の、ログアウトや終了のボタンのアイコンなど)

すべてのアイコンを同じテーマのもとに統一することは非常に困難であるというのは、もちろんわかっているが、せっかくテーマを使う以上は可能な限り統一したい。

いろいろな、それぞれに特徴と雰囲気を湛えたアイコンが一度にごちゃごちゃと出てきてしまうことを、僕は好まない。

その点、元のXの方ならばXのテーマのアイコンがまず使われ、それにないものについてはAdwaidaかhicolorか知らないが、老舗のアイコンセットのやつが使われ、それにもないものはアプリケーション独自のアイコンが使われるのだと思う。

Yを使ってしまうとそれにYのものが加わる。

わずか一つとはいえ、かなり特徴的なアイコン群が加わってしまうので、アイコンの統一感は余計に崩れる。

それは避けたいな、という気持ちが湧いてきてしまう。

それだけならばしかし、我慢できなかったわけではない。

その他により重大な問題があることに気づいてしまった。

次の写真はデスクトップで右クリックをした時のもの。

一番上の「新しいフォルダを作成」を選んでいるのだが、わかるだろうか。

よく見れば上下に薄い線が引かれ、色も僅かにグレー掛かってはいるようなのだが、目の悪い僕にはほとんど見えない。

ポインタのあるところの項目が選ばれているんだからいいじゃないか、と言われれば、まあそれはそうなんだけど、ポインタですら僕の目は必ずしも容易に捉えられるわけではないのだ。

その点元のXの方はこんな感じで、選ばれているところとそうでないところの差は一目瞭然である。

こっちのがいい。(推測では、ほんとはYでもこんな感じにするつもりでいるのに、ミスしている、つまりバグなんでないかと思うが、どんなもんだろうか)

Mint-Yテーマには別の選択肢として、Mint-Y-Darkというのと、それよりはダークさがうちわなMint-Y-Darkerというのがある。

そちらでは、右クリックで出てくるメニュー(リナックスでもコンテキストメニューと呼んでいいのかな)は次のようなもの。

これも選ばれているところと選ばれてないところとの違いは小さいが、それでも、マウスを動かしてみれば僕の目でもそれなりに捉えられるので、使えなくはない。

しかし、ダークというテーマの全体を写すと、こんな感じである。

左上のウインドウはLeafpadで、文章の部分までダークだ。(他のアプリケーションでも基本的に似たような感じ)

これほどまでにダークな画面に耐えられるほど、僕の心は強くない。

Darkerの方はこう。

Leafpadの中身はダークでなくなったが、それでもかなりダークである。

すっかりやわになってしまった僕の心には、これでもやはりきつく感じられる(慣れの問題かとも思うが)。

以上のことから、時の流れに身をまかせるのはやめて、普段の僕らしく、保守的に、消えることがわかっているものに哀しくしがみつき続けていくことにした。

つまりテーマはMint-Xに戻した。

これもあっさり撤回する可能性はあるが。

| Linux関連 | 21:45 | comments(0) | trackbacks(0) |

2017/03/04の記録:今日のリナミンシナモンパソコン

小ネタしか無いので昔使った雑な表題を久しぶりに使った。

1. LXQtを試す

LXDEを愛用している僕は、将来的にはLXQtを使う運命にあることが予想される。

Debianではまだ、普通にやっていたらパッケージマネージャでLXQtは出てこないはずだし、Lubuntuの機械は能力が貧弱なので試用には向かない。

その点、このリナミンシナモンパソコンはそこそこの能力があるはずだし、確認してみたらパッケージマネージャでインストールできるので、試してみることにした。

インストール直後のデスクトップはこんなの。

下のパネルを見るとわかるが、なぜかよくわからんが足りないアイコンがいろいろあるようで、空白になってしまってるところがある。これはメニューを出してみればなおさらはっきりする。メニューの大半の項目が、アイコン無しになってしまっていた。

「メニュー>設定>LXQtの設定>外観の設定」のアイコンテーマのところをいじってみたら、ある程度のアイコンは表示されるようになったが、それでも一部は欠けたまま。

この辺、よくわからない。

パネルのアプリケーションランチャのところは最初、上の写真のように「アプリケーションアイコンをここへドロップ」と文字で書いてあるが、ひとつ入れればちゃんと文字は消える。

入れ方は、デスクトップエントリファイルを持って行ったんではダメで、メニューを出してそこのアイコンを掴んで持って行くといけた。メニューに表示されないようにしてるやつを持って行こうと思ったら面倒だ。

「デスクトップを表示」も、最初文字で表示されてて鬱陶しいと思っていたが、何をいじった時だったか覚えてないが、気づいたらアイコン表示になってた。まあそれはそうだろうが、安心した。

全体として動きは快適。

LXDEに慣れてる僕にとっては、特に違和感はない。

ただ、細かい部分の設定はLXDEと比べてもできることが少なそうで、詳しくはいじらなかったのでそれを設定書類をいじったりして思い通りにできるかも、よくわからない。

例えばPCManFM-qtの設定のところは非常に簡素で、LXDEで僕が使っている、隠しファイルには影をつけるとか、大文字小文字を区別する/しない、とかの設定は、できるようになっていなかった。

もうひとつだけ気づいたところを書いておくと、LXQtの外観設定アプリケーションは、この前作ったフォントの個人設定ファイル、ホーム/.config/fontconfig/fonts.confという書類を直にいじる。

いきなり上書きするのではなく、既存のはバックアップをとってくれるようになっているので、特に困りはしなかったのだが、この前した設定はバックアップに回されて全く違う書類を作られてしまったので、当然LXQtでは反映されない。

新しい書類には「これはLXQtの外観設定が作ったファイルで、いじらないで」と書いてあるのだが、ではこの前やったような設定はどこでやればいいのか、というのがわからない。

いじらないで、というのを無視してお尻に付け足しといたらちゃんと効いたので、まあいいといえばいいものの、もう一度外観設定で何かをいじったら付け足した部分は消されちゃうかもしれない。

また、この書類は汎用の書類で別のデスクトップ環境にも効くものである以上、LXQtがこれを直接いじっちゃうといくつかのデスクトップ環境を使い分けたい場合にはちょっと困る。

できればLXQt用の設定は別に分けておいてくれたらなあ、と僕は思うのだけれど、もともとあるもので使えるものは積極的に使っていくというのがLXDEの頃からの基本的スタンスみたいだし、仕方ないのかもしれない。

いろいろいじってみた結果、こんな感じになった。

というわけで、インストールしたらいきなり快適な環境になる、というわけではなくて、じっくり時間をかけ、勉強しながら設定していかないといけない。

特に僕がそれなりに気にするウインドウ右と下のスクロールスライダー及びその両端の矢印なんかは、アプリケーションによってGtk2とか3とかQtとかでてんでんばらばらな見た目になっていて、これを統一しようとしたら大変そうだ。(シナモンでも必ずしも統一できているわけではないが)

LXQtは将来に備えて試してみただけで、この機械では(少なくとも今すぐ)シナモンをやめるつもりでいるわけではない。

LXQt独自の基本アプリケーションや設定アプリケーションがシナモンを使ってる時にも出てきてしまうのは鬱陶しいので、あらましのところがわかったことで良しとして、LXQtと関連パッケージは全部アンインストールした。

2. xedをやめてgeditにする

この前フォント設定書類をいじった時もそうだったし、その前にも何度かそういうことがあったのだが、このLinux Mint 18.1 Cinnamonでのデフォルトテキストエディタであるxedを使っていると、何かの拍子に表示が乱れて一旦閉じなければとても使えない状態になる。

多分しばらく放置しといたあとになるんじゃないかと思うが、詳しい状況は確認できていない。

この機械の能力によるのかもしれないが、いずれにしても使えないので、xedはやめて、LubuntuでもDebian LXDEでも使っているgeditを使うことにした。

ついでに、空白を表示させたいので "gedit-plugins" も、これを入れると下に書くように思いの外たくさん関連パッケージも入れなきゃいけないことがわかって多少躊躇したものの、入れた。

以下のパッケージがインストールされました:
gedit-plugins (3.18.0-1)
gir1.2-git2-glib-1.0 (0.24.0-3)
gir1.2-gucharmap-2.90 (1:3.18.2-1ubuntu1)
gir1.2-zeitgeist-2.0 (0.9.16-0ubuntu4)
libgit2-24 (0.24.1-2)
libgit2-glib-1.0-0 (0.24.0-3)
libhttp-parser2.1 (2.1-2)

以上、完全に自分向けの作業メモ。

念の為書いておくと、LubuntuやDebian LXDEでもgeditを使っていると言うとLeafpadが嫌いなのか、と思われるかもしれないが、そういうわけじゃない。

Leafpadは非常に軽快でたいへん気に入っていて、このリナミンシナモンでもインストールして使っているくらいなのだが、あまりに簡素すぎて背景色を使ったりコードに色を付けたりできない。

そこで、htmlやxml、css、スクリプト類なんかのコード系の書類はgedit、文章やメモなんかの普通のテキストファイルはLeafpad、と、使い分けている。

コードだって簡単なやつならLeafpadで済ます。

3. Mint-Yテーマを試す

テーマにMint-XとMint-Yというのがあることには気づいていた。

デフォルトはXの方。

さっき読んだサイト(「Linux Mint その6 - Linux Mint 18の変更点や新機能の紹介・βリリースのスケジュール」kledgeb さん)によると、Linux Mintの人たちにはXからYへ移行していこうという考えがあり、ただ急に変えたんでは反発もあるかもしれないのでデフォルトはXにしておいたままでYも提供してみて、反応を見よう、ということらしい。

そういうことなら試してみよう、という気になった。

僕自身、いきなり変わってしまうとショックを受けて嫌になってしょげちゃう性質がある。

どうせ変わるのであれば予め自分を慣らしておきたい。さっきのLXQt試用もそういう趣旨。

リナミンシナモンを使い始めたのは最近だが、昔リナミンマテをしばらく仕事で使っていたので、Mint-Xというテーマにはそれなりに慣れがある。

Yにも慣れておかねばならぬ。

で、

がもともとのX。


がY。

ぱっと見あまり変わらないが、よく見ると雰囲気がそれなりに違う。

Xにあった多少の凹凸感(光と影の表現)がなくなり、のっぺりした。

この、三次元表現からのっぺりへ、というのは、Windowsのxp、vista、7から8-10への移行でも見られたし、いろいろなウェブサイトなんかを見ていても、時代がそういうふうに流れているらしいということはわかる。

のっぺりは嫌いなわけではないが、猫も杓子もそうなるというのは、あんまりいい気はしない。

いろいろあれよ、と思う。

さっきも書いたように僕がそれなりに気にするウインドウ右と下のスライダーも、あまり好きではないマック風の濃いグレーの長丸になった。


これ。

Lubuntuもこれだが、これ、猫も杓子も真似するほどかっこいいだろうか。

確かに、クールな雰囲気を出したい時に他のやり方はあんまり思いつかないが、それでも何か他とは違うのを出してくれないかなあと思う。

ただし、Xの

これは、悪くなかったと思うが、目の悪い僕にはちょっと見づらかったので、濃いグレーになったのはその点では良い。
(適当な写真を撮っておかなかったので、あるやつを切り取って回転させた)

他には、アイコンが結構変わって、多少ポップになり、かなり明るいはっきりした色使いになった。

これも時代の流れのように思うが、これは僕の好みに合う。

Xに特に強い思い入れがなかったというのもあるかもしれないが、今度のYは全体として悪くない。

僕はこれでいいと思う。

Xのお硬い真面目な感じも、あれはあれで大切にしてほしく思うが、僕の好みでは必ずしもなかった。

僕の好みではこっち (Y) のほうがいい。

ただ、繰り返しになるがXみたいな生真面目な感じは大切だと思うので、リナミンはやめてしまうにしても、他の誰かが、ああいう感じを守り続けてほしく思う。

というわけで、僕個人は新しいMint-Yのテーマに特に悪い印象を持たなかったので、時の流れに身をまかせて、これを使っていこうと思う。

| Linux関連 | 23:59 | comments(0) | trackbacks(0) |

2017/02/25の記録:Linux Mint 18.1 Cinnamonのフォント設定(その2)

この前の続き。

表題にはLinux Mint 18.1 Cinnamonと書いたが、それに限らずそれなりに多くの環境で使えるはず。ただし、毎度のことながらその有効範囲がどの程度なのかは、僕は知らない。

この前はCinnamonを使う上でのデフォルトフォントをCinnamonが用意してくれているGUIの仕組みであるところの「メニュー>設定>フォント」を使って設定しなおして、さしあたりの問題を解決した。

さしあたりの問題は解決したものの、不満がひとつあって、それはそのやり方だと、下のパネルで使われているフォントを変えることができない点。

せっかくウインドウなどで使われるフォントを設定しても、パネルと一緒にできないと、デスクトップ環境としてはちぐはぐで冴えない。

より根本的な部分でのフォントの優先順位の設定をいじる必要があると思っていた。

が、そのやり方がよくわからず、例えばこれはDebian LXDEについてのものだが2016/03/28の記録で紹介した
/etc/fonts/conf.d/
の中の

  • 40-nonlatin.conf
  • 45-latin.conf
  • 60-latin.conf
  • 65-nonlatin.conf

などをいじる方法を試してみたのだが、これでは特に状況に変化を与えられなかった。

ネットで "linux mint font priority setting" で検索してみたら、次のようなページが見つかった。

これらのページでは、
ホーム/.config/fontconfig/fonts.conf
という書類を(場合によっては自分で作って)いじることを教えてくれている。

実はこの書類は、Debian LXDEやLubuntuではすでに作ってある。先週くらいにそれをそのままLinux Mint Cinnamonの機械にも移植してみたのだが、思うように機能してくれなくて、この環境ではダメなのか、と放棄していた書類だった。

これこれのフォントはセリフですよ、これこれはサンセリフですよ、と書いて、その下でセリフ・サンセリフ・モノスペースのそれぞれについてフォントの順位付けをするような書類。

この書類は、Debian用にいつかどこかで教えてもらって試してみたものなのだが、その時その作業のメモをとっておかなかったので、いつどこで教わったのかも、その結果うまくいったのか否かも、もう忘れてしまっていた。
(さっき手元にあるLubuntuを確認してみたら、Lubuntuでは機能してないことがわかった)

それで、あまり乗り気はしなかったがせっかくだからビバ!Linuxさんの紹介してくださっている内容をそのままコピーして、インストールしていないフォントの部分だけを削除して試してみた。

意外にもうまくいった。

どうやら、環境に合わないのは書類自体ではなくて、記述の仕方だったようだ。

ビバ!Linux さんの書類を見ると僕が前に試した書類とは書いてあることが違う。

上の方に書いてあるのは例えば "serif" という文字列を探して、それがあったら "Takao P明朝" をそこに当てはめる、といった内容だと思われる。同様の内容がunix.stackexchange.comの方にも書いてある。

下の方に書いてあることの意味はよくわからない。

そこで、僕はとりあえずセリフとサンスとモノでフォントの優先順位の指定さえできればいいので、よくわからない下の方の記述は削除して、次のような内容だけを使うことにした。

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

    <match target="pattern">
        <test qual="any" name="family">
            <string>serif</string>
        </test>
        <edit name="family" mode="prepend" binding="strong">
            <string>Playfair Display</string>
            <string>Liberation Serif</string>
            <string>TakaoExMincho</string>
        </edit>
    </match>
 
    <match target="pattern">
        <test qual="any" name="family">
            <string>sans-serif</string>
        </test>
        <edit name="family" mode="prepend" binding="strong">
            <string>Noto Sans CJK JP</string>
            <string>VL PGothic</string>
        </edit>
    </match>

    <match target="pattern">
        <test qual="any" name="family">
            <string>monospace</string>
        </test>
        <edit name="family" mode="prepend" binding="strong">
            <string>Noto Sans Mono CJK JP</string>
            <string>VL Gothic</string>
        </edit>
    </match>

</fontconfig>

それぞれの字体について複数のフォント名を書いておくのは、トップに置いたフォントがカバーしてない文字を二番目以下が補うようにするため。

セリフで言えばPlayfair Displayはラテン文字やキリル文字はおさえていたはずだが、タカオに入ってない文字を十分におさえていたか多少不安だったので、Liberationを補佐に置いておいた。そしてその2つに入っていない日本語をタカオで受ける。

その点、サンスとモノについては、両者にカバー範囲の違いはそんなにありそうでもないが、両方書いておいて、気分によって上下入れ替えれば楽だと思って2つ書いておいた。

フォント名の記述は、スペースが入るか否かなどで悩むことがあって、書き換える都度調べるのは面倒なので。

この書類でこう設定してしまえば、各アプリケーションでのフォントの指定は(もしそれができるのであれば、だが)具体的なフォント名は書かずにserifかsans (-serif) かmono (space) かだけ指定しておけば、この書類に従ってフォントが選ばれる。

この書類を書き換えれば、全部のアプリケーションにその変更が反映される。

つまりフォントがこの書類で一元管理できるわけで、大変便利だ。

というわけで、この前やった「メニュー>設定>フォント」でも、OperaやFirefox等でも、そのように設定しなおした。

なお、この
ホーム/.config/fontconfig/fonts.conf
は個人設定の書類だが、上掲のunix.stackexchange.comのページや
/etc/fonts/fonts.conf
という書類の記述によると、
/etc/fonts/local.conf
という書類を作って同様の内容を書いておけば、システムの設定として使えるらしい。

最後にもう二点ひとつメモ。【

ひとつ目。

うまく機能しているか否かはこのブログのフォントの指定を一時的にserifだけにして、Firefoxでどう表示されるか確認する、というやり方で判断した。

Linux Mint Cinnamonでは、ローマ字はPlayfair Display、日本語はTakaoExMinchoという、期待通りの表示になった。

しかし、Lubuntuで同じことをすると、日本語もローマ字も全てTakaoExMinchoになる。

TakaoExMinchoを試しにVL Gothicに書き換えてみたらちゃんとVL Gothicになったので、書類が効いていないわけではないのだが、Linux Mint Cinnamonと違う結果になるのはなぜだか、よくわからない。

ふたつ目。

Linux MintのFirefoxだと、今書いたように思い通りになるのだが、Operaだとローマ字はPlayfair Displayになるが日本語は、なぜかサンセリフの方のNoto Sansになる。

TakaoExMinchoをトップに持ってくればちゃんとそれになる、つまりこの書類がオペラに効かないわけではないのだが、もちろんローマ字もTakaoになる。

昔のオペラはサイトのcssで指定したフォントの、最初のやつしか使ってくれない、という特徴があったのだが、それは最近のバージョンでは解消されている。

しかし、パソコンの方のフォント設定で同じことが起こるとは。

理由はよくわからない。

== 訂正 ==

ひとつ目のメモとして書いたLubuntuの件は、確認不足に過ぎませんでした。LubuntuのFirefoxの設定で、デフォルトのフォントとしてTakaoExMinchoが選んであり、それを上に書いたようにSerifと直すのを怠ったままテストしたため、Linux Mintと違う結果になっただけでした。

Operaの方は、解決策があるのかどうか、まだわかりません。

== 02/28追記 ==

記事本文では
ホーム/.config/fontconfig/fonts.conf
という書類を使ったフォント設定について扱っているわけですが、この書類は本文中にもあるようにDebian (Jessie) でも使っています。

Debianで僕がもともと使っていたこの書類には例えば次の様な記述がありました。(長くなるのでセリフに関する部分だけを抜き書きします。他の字体についてもフォント名以外同様の記述です)

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <alias>
    <family>Playfair Display</family>
    <default><family>serif</family></default>
  </alias>
  <alias>
    <family>TakaoExMincho</family>
    <default><family>serif</family></default>
  </alias>
  <alias>
    <family>TakaoPMincho</family>
    <default><family>serif</family></default>
  </alias>

  <alias>
    <family>serif</family>
    <prefer>
      <family>Playfair Display</family>
      <family>TakaoExMincho</family>
      <family>TakaoPMincho</family>
    </prefer>
  </alias>
</fontconfig>

この上半分は、それぞれのフォントがどの字体か(ここではセリフ)を記述したもので、本文でも紹介した

  • /etc/fonts/conf.d/40-nonlatin.conf
  • /etc/fonts/conf.d/45-latin.conf

という書類にすでに同様の記述がある場合は必要ないと思われます。

下半分はそれぞれの字体(ここではセリフ)について、優先順位を記述したもので、

  • /etc/fonts/conf.d/60-latin.conf
  • /etc/fonts/conf.d/65-nonlatin.conf

に記述された順番と別の順番にしたい場合や、これらの書類に記述されていないフォントに高い優先順位をつけたい場合に使うものと思われます。

これらの記述は、なぜかはわかりませんが、本文にも書いたようにLinux MintやLubuntuでは機能しないようです。

しかし、Debianでは機能します。

ただし、Debianでも、これもなぜかはわかりませんが、TakaoやIPA、VL Gothic等の日本語フォントであれば、それぞれの字体についてトップに置いたものがちゃんとブラウザ等のアプリケーションで使われるのですが、上に書いたPlayfair Displayや、もっとメジャーなTimes New RomanやGeorgiaなどを記述しておいても、欧文やローマ字用のフォントとして使ってもらえず、その下に書いた日本語フォントが使われてしまいます。

この理由については、僕の環境が日本語環境であることが関係しているかも、ととりあえず推測するくらいで、よくわかりません。

一方本文で書いたような記述の仕方をすれば、Debianでも、欧文フォントも含めた優先順位の指定として有効に機能します。

それでDebianの機械でもそのような記述に改めておいたのですが、上述の挙動の理由がよくわからないので、どうもしっくり来ません。

記述の内容として、本文で書いたような記述はやや強引な感じがするのに対し、Debianの機械でもともとしていた記述はそれに比べると穏やかな印象なので、どちらかといえば後者を使いたい気分なのですが、欧文やローマ字は欧文フォント、かな漢字は日本語フォント、と使い分けたいので、やむを得ません。

なぜ欧文には欧文フォントを使いたいかというと、フランス語等に使われるアクサン付きラテン文字は日本語フォントでカバーしていないことが多く、他は日本語フォントなのにアクサン付き文字だけ別の欧文フォントが使われるくらいなら、いっそラテン文字は全て欧文フォントを使ってくれたほうが美しい、というのがひとつ。それに加えて、こちらがより重要なのですが、キリル文字はカバーされているものの全角になってしまい、ひと単語程度ならともかく文章としてはとても読めたものではない、という点があります。

ただし、この点VL (P)Gothicは優秀で、アクサンも出ますしキリル文字も半角で出ます。これが僕がVLを偏愛する理由で、VL (P)Minchoもできてくれないものか、と、切に願っているのですが、難しいのでしょうか。
(アクサンの方はTakaoも出るので、その点はいいのですが、キリル文字はやっぱり全角です。Macでつかうヒラギノは、日本語は美しいと思いますが、この点を残念に思っています。最近どうなってるかについては、実はよく確認していませんが)

以上、特に役立つ情報でもありませんがメモしておきます。

========
| Linux関連 | 02:56 | comments(0) | trackbacks(0) |

2017/02/24の記録:xmodmapの弱点

メモ。

この前の記事で、今度買ったリナミンシナモンパソコン用に使うことにした初代iMac付属キーボードにはDeleteキーが無いので、xmodmapという仕組みを使って僕はあまり使わないhelpキー(LinuxではInsertキーとして機能)をDeleteとして使う設定をした、と書いた。

その同じ記事の追記では、xkbのoptionという仕組みを使って左コントロールとキャプスロックを入れ替える際に出る不具合を避けるために、もともとある日本語レイアウトを少しいじって新しいレイアウトを作り、fcitx-mozcで日本語を打つ際にはそのレイアウトを使うことにしたことを書いた。

ただし、この追記で書いた作業は、不具合が気に入らないから解決策を探した、というだけで、同じことがxmodmapでもできる。

xmodmapが使えるこのリナミンシナモンパソコンではそのやり方をする必要は必ずしもなかった。

【つまり、InsertをDeleteにする設定はxmodmapを使い、Control_LとCaps_Lockの入れ替えは新しいレイアウトを自作することで対処したわけだが、両方をxmodmapで一遍にすることもできる、ということ。(04/12補)】

で、今日そのリナミンシナモンをいじっていて、xmodmapの動きがおかしいことに気づいた。

効いてる時と効いてない時があるのだ。

効かなくなる条件を突き止めるのに手間取ったが、mozc用に件の自作レイアウトを使う設定をしているとxmodmapで指定した設定が効かなくなることがわかった。

自分で作ったレイアウトに不備があるからか、と、ちょっとしょげかけたのだが、試しに自作のではなく、かといってもともとの日本語レイアウトでもない、イタリア語レイアウトをmozcに使う設定をしてみたらどうか、と思いつき、試してみた(IはJの隣で手近だからというだけで他意はない)。

すると、案の定xmodmapが効かなくなった。

なぜもともとの日本語レイアウトは大丈夫でイタリア語や自作レイアウトはダメなのかはよくわからんが、とにかくxmodmapにはそういう弱点があることがわかった。

それで結局、このリナミンシナモンでは元通り、mozcでは普通の日本語レイアウトを使うことにした上で、InsertをDeleteに変え、左ControlをCaps Lockと入れ替える設定は両方共xmodmapで行うことにした。

ただし、この前も書いたが別のDebian LXDEのパソコンではxmodmapの自動起動がなぜかうまく機能しない。

そっちで初代iMacキーボードを使いたくなることもあるかもしれない。

その際には、ControlとCaps Lockはこの前のやり方でいいとして、InsertをDeleteに置き換えるxkbのoptionを作らなければならない。

【つまり、僕のしたい設定は両方共、新レイアウト及び新オプションの自作で対処する事になる。(04/12補)】

そんなに手間はかからないだろうが。

| Linux関連 | 23:14 | comments(0) | trackbacks(0) |

2017/02/11の記録:Linux Mint 18.1 Cinnamonで初代iMacのキーボード用の設定

必要ないのに思わず買ってしまったリナミンシナモンパソコンの設定ネタをもうひとつ。

ひとつの記事にしても良かったが話が変わるので分けた。

リナミンシナモンのために買った格安パソコンは、格安である以上当然本体だけでモニターもキーボードもマウスもない。

古いのを使うわけだが、幸いモニターは兄の使い古しをもらってあったし、マウス・キーボードも予備はそれなりにある。

キーボードについては、テンキーはあったほうがいいがコンパクトな方がいい、ということで、初代iMacのやつを使うことにした。

このキーボードの欠点はDeleteがないことだが、それについてはxmodmapを使ってあまり使わないhelpキー(LinuxではInsertになる)をDeleteにあてるようにする。
(xmodmapについては古い記事だが2014/03/31の記録を参照のこと)

もう一つの問題は左Controlの位置。

マックのパソコンではcontrolはタブと左シフトの間に来て、caps lockが左下にある。

マックで使う分には別にどうでもいいのだが、リナックスやウインドウズではマックでのコマンドキーの代わりにControlを使うことになるので、その位置は重要になる。

Control_LとCaps_Lockを入れ替えたい。

最初、簡単な方法として、

setxkbmap -option ctrl:swapcaps

をログイン時に自動起動させるように設定していた。

しかし、これだと、日本語を打つためにMozcを使っている状態で左Controlのつもりで左下隅のキーを押すと、Caps Lockの機能が一部残ってしまうらしく、ひらがなではなくローマ字が入力されるようになってしまう。

これは以前、2016/07/12の記録で紹介したqiitaoyasさんという方の記事に書かれている事例と似た事例のようだ。

modifierの付け外しがうまくいってないと思われる。【

で、僕の使っている "ctrl:swapcaps" というxkbのオプションを規定している
/usr/share/X11/xkb/symbols/ctrl
という書類を見てみると、そのswapcapsの内容は次のように至って簡素で、modifierの付け外しについてちゃんとやってくれていないようにやはり見える。

// Swap the functions of the CapsLock key and the left Ctrl key.
partial modifier_keys
xkb_symbols "swapcaps" {
    replace key <CAPS> { [ Control_L ] };
    replace key <LCTL> { [ Caps_Lock ] };
};

そこで、上でもリンクを貼った2014/03/31の記録の際に参考にした

というページで紹介してくださっているやり方、具体的にはxmodmapでコントロールとキャプスロックを入れ替える際の記述内容を、使わせてもらうことにした。

こちらのほうが、記述内容を見る限り、modifierの扱いが手厚い。

remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L

見てわかるように、一旦modifierを外してからキーの入れ替えをし、もう一遍modifierを付け直している。

考えてみれば、上に書いたようにDeleteのためにどうせxmodmapを使っているのだから、最初からこれをxmodmapで呼び出す ".xmodmap" という書類(ホーム直下に置いておく)に付け加えておけばよかった。

このやり方なら、問題なく左ControlとCaps Lockの入れ替えができた。

僕がxmodmapをあまり使わないのは、主に使っている環境であるDebian LXDEではなぜだかわからないがこのxmodmapをログイン時に自動起動させられない(手動でなら機能する)からなのだが、ちゃんと使えるのであればやっぱり便利なものだ、と改めて実感した。

せっかくなので、僕がログイン時に自動起動させることにした ".xmodmap" の記述内容を書いておこう。

keycode 118 = Delete Insert
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L

一行目がhelpキーをDeleteにする設定で、もともとの機能であるInsertはシフトと一緒に押せば使えるように第二レベルに設定しておいた。

その後は上掲のページで教えていただいたものをそっくりそのまま書いただけ。

== 02/21追記 ==

modifierの付け外しの問題というのは僕の勝手な思い込みで、勘違いかもしれません。

まず、問題の起こる状況でxmodmapを使ってmodifierを外してみても、問題は解消されません。

状況をよく確認したところ、問題の起こるのはあくまでmozc (fcitx) を使っている時だけで、それ以外の時は特に問題はなさそうです。

また、mozc用に使うキーボードレイアウト(mozcの設定の方ではなく、fcitxの設定のほうでmozcをダブルクリックすると選択できる)を、「規定の入力メソッド」ではなく「日本語」にしてあるのですが(「規定の入力メソッド」をカナディアンフレンチにしてあるため)、これを「規定の入力メソッド」に戻すと、mozc使用時にも問題が起きません。

以上から、xkbのオプションの設定は規定のレイアウトには効くがfcitx-mozcから呼び出したjpレイアウトには効かない、ということかもしれません。一方xmodmapの方はmozcのjpにまで効力が及ぶ、ということ。

ただ、Caps Lockとして使うことにしたもともとのControlキーの方は、mozc上でもCaps Lockとして機能する点が、この推測とぶつかります。

Controlとして使いたいCaps Lockキーの方も、mozc上でも完全にCaps Lockとしてだけ機能するわけではなく、Controlとしても機能する一方、Caps Lockの機能のうちひらがな入力を英数字入力に切り替える機能は働く一方、小文字を大文字にする機能は働きません。
(そもそも英数字への切り替えがどうして起こるのか、どこでその機能が設定されているのかがわかりません。mozc設定を見てもfcitx設定を見ても、そういう設定はなさそうなのですが)【下のさらなる追記を参照のこと。消線部以下同じ】

ということで、xkb optionがmozcのjpに効力が及ばないとしても、完全に及ばないのではなく一部しか及ばない、ということになるでしょう。元の認識と合わせて、modifierの付け外しがmozc上のjpではうまくいかない、ということかもしれません。

問題が解消しない、尻切れトンボな内容ですみません。いずれにしても、xmodmapが使える環境であれば、そちらを使えば問題ありません。

もうひとつ、本文で触れたoyasさんの記事に書かれている事例と症状は似ているのですが、oyasさんのなさってる方法をまねしてみても、つまり
/usr/share/X11/xkb/symbols/ctrl

partial modifier_keys
xkb_symbols "swapcaps" {
    replace key <CAPS> { [ Control_L, Control_L ] };
    replace key <LCTL> { [ Caps_Lock, Caps_Lock ] };
};

としてみても、うまくいきません。

症状は似ていても、別の問題なのかもしれません。

== さらなる追記 (02/21) ==

先ほど(上の追記)はちょろっと調べてちょろっと書いてしまったので検証不十分な内容になってしまいましたが、その後落ち着いて調べてみました。

わからないことはわからないままではありますが、あらましのことはつかめ、とりあえずの対処法もわかりました。

まず、modifierは関係なさそうです。

問題の肝は、どこで設定されているのかわからない、と上で書いたCaps Lockキーの英数入力への切り替え機能にあり、それは他ならぬjpレイアウトで規定されていたものでした。

/usr/share/X11/xkb/symbols/jp
という書類の、"key <CAPS>" の行(僕の環境では47行目)を見れば、jpレイアウトではキャプスロックキーの第一レベルに "Eisu_toggle" というkeysymが設定されていることがわかります。

Caps_Lock自体は第二レベル。

確かに、マックではないパソコンではキャプスロックをするためにシフトとキャプスロックを一緒に押す必要があるなあ、とは思っていたんですが、僕は漠然とMicrosoftの趣味なんだと思ってました。jp配列 (JIS?) の趣味だったんですね。

この設定が、なぜかxkbのoptionでは取り消せないことが、不具合の原因でした。なぜかはわかりません。

xmodmapではその設定を消せるから、うまくいくのでしょう。

両者に違いが出るのは、xkbのoptionや "symbols" を規定した書類では <CAPS> や <AE07> といった、よくわからないのですがkeyと呼ばれてるんじゃないかと思われるものにkeysym ("Control_L" や "k" や "kana_A" などです)が当てられているのに対して、xmodmapでは、8から255までの数字であるところのkeycodeにkeysymを当てるからではないかと思われます。

xkbの設定書類ではまずkeycodeにkeyを当て、次にkeyにkeysymを当てる仕組みになっています。キーボード(機械)によって同じキーでも送られる信号が必ずしも一致しないためにこういう仕組みが必要なのだと推測しています(昔はともかく最近では大抵同じみたいですが)。どのタイプの機械なのか、によってkeycodeとkeyの対応が決まり、それとは別に、使用するレイアウト(普通は使う言語)ごとにkeyとkeysymの対応が決まるわけです。ですから、keycodeを扱うxmodmapを使う場合は自分のいじりたいキーのkeycodeを、"xev" みたいな仕組みを使って確認する必要があります。keycodeとkeysymをじかに当ててしまうとそういう面倒があるのですが、今回の問題はkeyのレベルで起きるために、かえってそこを飛ばしてしまうxmodmapならばうまくいくのではないか、と、これも僕の推測にすぎませんが、今のところ考えています。

それはともかく、xmodmapを使わない対処法を考えるとなると、xkbのoptionではうまく行かない以上、レイアウト自体をいじっちゃうのが一番手っ取り早そうです。

jpレイアウトから <CAPS> に関する設定を削っちゃうわけです。

基本的にこの前2017/01/26の記録でやったのと似たような作業です。

その記事にも書いたようにデフォルトの記述自体をいじっちゃうのが一番楽なのですが、それはあまりに乱暴なので、面倒ですが付け加える形で行きます。

jpレイアウトの設定書類は上に書いたように
/usr/share/X11/xkb/symbols/jp
です。これに付け加えます。

この書類の内容がどうなってるかというと、まず "106" というヴァリアント名が一応付いているデフォルトの設定(jpとだけ選べばそれになるもの)が書かれていて、その下に様々なヴァリアントが続いています。ローマ字入力ではなくかな入力の場合のヴァリアントとかです。

そのヴァリアントの一つとして、新しくさしあたり "EISU_Nashi" と名付けたのを付け加えるわけです。

そもそもデフォルトの106ヴァリアントはその大部分を "common" というヴァリアントをinclude、つまり読み込んで、足りない部分だけを記述する形になっていますから、僕の作るEISU_Nashiヴァリアントでもcommonをincludeする形にしたいんですが、そのcommonのなかににっくき "key <CAPS>" の行が入っちゃっているものですから、そうもいきません。

この行を、例えば

key <CAPS> { [ Caps_Lock, Caps_Lock ] };

と改めて設定しなおしてもいけそうに思うんですが、試したらそれではダメなんですね。optionがダメなのと同じ理由だと思われます。

アホな話ですが、これをやってsetxkbmap -option ctrl:swapcaps をやると、左コントロールキーもキャプスロックキーも両方キャプスロックになります。

なんでキャプスをコントロールにするのはうまくいかないのにコントロールをキャプスにする方はうまくいくんだよ、と思います。本当にアホだと思います。

で、仕方ないのでincludeは諦めて、全部のキーの記述をコピーしてきた上で、にっくき <CAPS> の行と、ついでなので別に要らないはずだと思うのにわざわざ書いてある <LCTL> の行だけを消しちゃいます。

消しちゃうのは不安かもしれませんが、jpに限らず多分すべてのレイアウトが、一番の基盤であるところの "pc" レイアウト(のデフォルトである "pc105" ヴァリアント)を読み込んだ上で、その上に乗っける形で使うことになるようです。(ターミナルで "setxkbmap -print" をやってみればそれがわかります)

modifier絡みのような大事そうなキーについてはそれで規定してあるので、個々のレイアウトでは別に規定する必要はないんですね。

LCTLは要らないはずだ、と上で書いたのはそういう意味で、CAPSの方はpcと内容が違うので書く必要があるのはわかるんですが、LCTLの方はなんで書いてあるのかわかりません。

僕の作ったjp配列のEISU_Nashiヴァリアントの記述内容を以下に貼り付けておきます。デフォルトの106の固有の記述に、それがincludeしているcommonの記述をくっつけて、そこからCAPSとLCTLの行だけを削ったものです。
(本当は、このEISU_Nashiをcommonがincludeして、僕が削ったCAPSとLCTLだけをcommon固有の設定として書く、というのが書類の書き方としては綺麗なんでしょうが、もともとのものをいじるのはなるたけ避けたいので、無駄に長い書類になっています)

partial alphanumeric_keys
xkb_symbols "EISU_Nashi" {

    name[Group1]= "Japanese";

    key <AE10> { [ 0, asciitilde   ] };
    key <AE13> { [ backslash, bar  ] };

    key <HZTG> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1]= [ Zenkaku_Hankaku, Kanji ]
    };

    key <AE01> { [ 1, exclam       ] };
    key <AE02> { [ 2, quotedbl     ] };
    key <AE03> { [ 3, numbersign   ] };
    key <AE04> { [ 4, dollar       ] };
    key <AE05> { [ 5, percent      ] };
    key <AE06> { [ 6, ampersand    ] };
    key <AE07> { [ 7, apostrophe   ] };
    key <AE08> { [ 8, parenleft    ] };
    key <AE09> { [ 9, parenright   ] };
    key <AE11> { [ minus, equal    ] };
    key <AE12> { [ asciicircum, asciitilde ] };

    key <AD01> { [ q, Q            ] };
    key <AD02> { [ w, W            ] };
    key <AD03> { [ e, E            ] };
    key <AD04> { [ r, R            ] };
    key <AD05> { [ t, T            ] };
    key <AD06> { [ y, Y            ] };
    key <AD07> { [ u, U            ] };
    key <AD08> { [ i, I            ] };
    key <AD09> { [ o, O            ] };
    key <AD10> { [ p, P            ] };
    key <AD11> { [ at, grave       ] };
    key <AD12> { [ bracketleft, braceleft ] };

    key <AC01> { [ a, A            ] };
    key <AC02> { [ s, S            ] };
    key <AC03> { [ d, D            ] };
    key <AC04> { [ f, F            ] };
    key <AC05> { [ g, G            ] };
    key <AC06> { [ h, H            ] };
    key <AC07> { [ j, J            ] };
    key <AC08> { [ k, K            ] };
    key <AC09> { [ l, L            ] };
    key <AC10> { [ semicolon, plus ] };
    key <AC11> { [ colon, asterisk ] };
    key <AC12> { [ bracketright, braceright ] };

    key <AB01> { [ z, Z            ] };
    key <AB02> { [ x, X            ] };
    key <AB03> { [ c, C            ] };
    key <AB04> { [ v, V            ] };
    key <AB05> { [ b, B            ] };
    key <AB06> { [ n, N            ] };
    key <AB07> { [ m, M            ] };
    key <AB08> { [ comma, less     ] };
    key <AB09> { [ period, greater ] };
    key <AB10> { [ slash, question ] };
    key <AB11> { [ backslash, underscore ] };

    key <NFER> { [ Muhenkan        ] };

    key <XFER> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1]= [ Henkan, Mode_switch ]
    };

    key <HKTG> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1]= [ Hiragana_Katakana, Romaji ]
    };

    key <EISU> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1]= [ Eisu_toggle ]
    };

    key <KANA> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1]= [ Hiragana_Katakana ]
    };

    key <PRSC> {
        type[Group1]= "PC_ALT_LEVEL2",
        symbols[Group1]= [ Print, Execute ]
    };
};

/usr/share/X11/xkb/symbols/jp
の最後にこれを書き足し、あとはこの前と同様

  • /usr/share/X11/xkb/rules/evdev.lst
  • /usr/share/X11/xkb/rules/evdev.xml

という書類をいじります。(この前はoptionの追加だったのでもうひとつ拡張子なしの "evdev" という書類もいじったのですが、すでにあるレイアウトのヴァリアントの追加の際は2つだけでいいようです)

この2つの書類に、それぞれ次のような記述を付け加えます。

場所は、jpのdvorakの設定があると思うので、その下でいいと思います。わかりやすくするために、そのdvorakの内容と合わせて書いておきましょう。

  dvorak          jp: Japanese (Dvorak)
  EISU_Nashi      jp: Japanese (Without EISU)
        <variant>
          <configItem>
            <name>dvorak</name>
            <description>Japanese (Dvorak)</description>
          </configItem>
        </variant>
        <variant>
          <configItem>
            <name>EISU_Nashi</name>
            <description>Japanese (Without EISU)</description>
          </configItem>
        </variant>

これで、システムを再起動させればjpレイアウトのEISU_Nashiヴァリアントが、普通のキーボードレイアウトのような顔をして色んな所に出てくるようになると思います。

例えばfcitxでは「入力メソッド」の一つとして選べるようになります。

また、
/etc/default/keyboard
という書類に次のように書けば、システムのレイアウトとして使えるようになります。

XKBMODEL="pc105"
XKBLAYOUT="jp"
XKBVARIANT="EISU_Nashi"
XKBOPTIONS="ctrl:swapcaps"

ターミナルで

setxkbmap -layout jp -variant EISU_Nashi -option ctrl:swapcaps

とやれば、そのセッションの間は使えるようになります。

これをログイン時に自動起動させるようにすれば、個人設定にできます。

(この記事のそもそもの目的であるコントロールとキャプスロックの入れ替えのオプションを書いておきましたが、不要な場合はオプションの記述を削除します。上の方は "" で大丈夫。逆に、すでに書いてあるのに付け加える場合は , で区切ります。カンマの前後スペース無しです)

キーボードレイアウトの設定方法はこの他にもいろいろあり、参考になる記事がたくさん見つかると思います。このブログにもいくつか記事がありますが、この記事でわかるように僕の文章は読みづらいので、他の方のまとめられたものを探されたほうが良いと思います。

========
| Linux関連 | 17:18 | comments(0) | trackbacks(0) |

2017/02/11の記録:Linux Mint 18.1 Cinnamonのフォント設定

思いの外格安で中古のパソコンが手に入ったので、Linux Mint 18.1 Cinnamonを入れてみた。

というより、にちょっと触れたようにLinux Mint 18.1 Cinnamonを使いたい気持ちが募ってしまったのに、それを入れるべき機械が手元にないために、格安のパソコンを探した、という流れ。パソコンが先にあってそのOSを探したのではなく、OSが先にあってそれ用のパソコンを探した。

全く必要性もないのに自分でもアホだとは思うが、今日はちょっと昼飯——夕飯ではない——を奮発してみようか、というくらいの値段でLinux Mint Cinnamonには十分な能力の機械が買えることがわかってしまったので、買ってしまった。

そもそもLM Cinnamonを試したのは、もともとLM MATEの入っていた母のパソコンをバージョンアップさせるに際して、MATEに飽きたらない感じがあったため。古い機械で重さが気になっていた以上MATEが気に入らないならXfceを試すのが筋であるところをそうしなかったのは、その頃はまだXfceの18.1は出ていなかったから。今は出ている。わずか一週間か二週間の差が、無駄な買い物につながってしまった。

母の機械には結局リナミンではなくデビアンを入れたことはもう書いた

それはともかく、これが(この数週間ほど)憧れていた、Linux Mint 18.1 Cinnamon。

なかなか満足。

まだ、壁紙とこれから書くフォントくらいしか見た目に出る部分に関してはいじってない。

憧れのリナミンシナモンを使えるようになって、なかなかに満足したのだが、少し気に入らないことがあった。

ウインドウの大きさが一定せず、何かのはずみにひょこひょこ動くのだ。

しばらく理由に気づけずにいたのだが、ファイルを右クリックして何かしようとした時に、わかった。

ウインドウの下の部分、「ステータスバー」に表示されるべきテキストの違いによって、高さが変わり、ひょこひょこ動くのだった。

具体的には、ローマ字が入る場合と日本語だけの場合とで変わる。


この写真は、同じウインドウをステータスバーの文字の中にローマ字の入る場合と日本語だけの場合とで比べるために作ったもので、左半分がローマ字の場合を反転したもの、右側が日本語の場合。

真ん中を見ると高さがずれているのがわかるだろう。

これはローマ字と日本語とで別のフォントが使われており、それぞれの高さが違うために起きると推測できる。

リナミンシナモンで画面表示のためのデフォルトのフォントはNoto Sans Regularで、Noto Fontsというのはノー豆腐フォント、つまり文字化け(豆腐のような四角が出る)を避けるためのフォントのはずだが、ノーマルのノトサンスには日本語フォントは含まれておらず、別のフォント、おそらくはTakao Gothicが呼びだされているのだろうと思われる。

そこで最初は、日本語と普通のローマ字だけじゃなく、範囲はよくわからないがとりあえずアクサン付きラテン文字やキリル文字は含まれていることから普段愛用しているVL PGothicを使うことにした。

しかし、最近はいつでもどこでもVLPを使っていることから、せっかく新しくシナモンを試してみているのにいつもどおりの感じになっちゃったのが残念に思われたので、VLPは大好きだが、少なくともしばらくの間は、シナモンの元のデザインを大切にするために、これもどれくらいの範囲をカバーできてるのか知らないけど少なくともローマ字と日本語は入っているはずのNoto Sans CJK JPを使うことにした。

これで、ウインドウの大きさがひょこひょこ変わることもなくなって安定した。

日本語フォントの優先順位をいじって、Noto Sans CJKをタカオより上に持ってきたりしてもいいんだろうと思うけど、設定書類がどれだったか探すのが面倒なので、とりあえずこれでいい。

== 02/13追記 ==

Libre Officeでちょっと試してみただけで十分に検証したわけではありませんが、ノーマルのNoto SansとNoto Sans CJKとで、フォントの高さが違うようです。

そうだとすると、Takaoが呼び出されたわけではなくNoto Sans CJKが呼び出されていたとしても高さが違うのでズレが出るのでしょう。

フォントの優先順位をいじっても、ノーマルのNoto Sansがデフォルトフォントとして選択されている限り、ウインドウの不安定な挙動は解消されないと思われます。

ノーマルNoto Sansと高さがまったく同じな日本語フォントがあれば別ですが。

== 02/25追記 ==

02/25の記録でフォント設定について続きを書きました。

本文の最後と上の追記でちょっと触れている、フォントの優先順位の設定についてです。

========
| Linux関連 | 14:54 | comments(0) | trackbacks(0) |
  | 1/11 pages | >>>|
ciguwerao
CALENDAR
S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
LATEST ENTRIES
SELECTED ENTRIES
CATEGORIES
ARCHIVES
SPONSORED LINKS
qrcode