なぜInboxよりもGmailが使いやすいか

ここ半年ほどInboxを使ってきましたが、Gmailの方が使いやすいな、と感じる部分がいくつか。ちょっとまとめてみる。

Inboxでの利点

Inboxのナビゲーション自体は良く出来ていて、全体的には使いやすいと感じる。添付ファイルなどが入っているとそれが大きく表示されるし、また全体的に使っていてより楽しいのがInbox。

処理的にもかなり意欲的な出来であり、メールの扱いのやり方を変えよう、という発想があるのは面白い。

短所と感じる部分

でも使っていて、使いにくいと感じる部分も多い。ほとんどがGmailで出来て、Inboxで出来ないことなので、かなり惜しく感じてしまう。

アドレスごとの署名管理がない

InboxではGmailと同じように複数のメールアドレスを管理できるのだが、Inboxには他のアドレスを使用した場合に、署名を切り替えることができなくなっている。コンベンション用など使い分けているのでこれができないのは非常に致命的。

HTML形式がデフォルトで変更できない

Inboxは送信メールはHTML形式がデフォルトであり、切り替えることができない。Gmailにはテキストメールへの切り替えができるようになっている。妙なメタデータが紛れ込んだりするので、できるだけHTMLは送信しないようにしているのでこれはかなり不便だったりする。

ソース表示ができない

これは多分99%の人には関係ないのだろうけど……。Gmailのメールはソースを見ることができないので、ヘッダの確認などをすることができない。微妙なメールが届いた時にざっと確認する場合もあるので、是非欲しいところなんだが。

変更ができない言語に依存した返信ヘッダ

これも煩わしい問題。Gmailで返信をすると次のようなヘッダが追加される。

2016-02-17 13:26 GMT-08:00 John Doe <johndoe@example.com>:

これをInboxですると次のような感じになる。

2016年2月17日(水) 13:26 John Doe <johndoe@example.com>:

なぜGmailの方が優れているかというと、受取人の言語に依存しないから。受け取る人が日本人であろうと、あメリカ人であろうと全く問題がない、言語非依存の形式お使用しているのがGmail。Inboxの場合、日本人しか読めない。せめて形式を指定できればいいのだが。

まとめ

上記を書いた後に考えると、恐らくInboxが想定しているのは読むのが主で、カジュアルなユーザーなのかな、と。Gmailにある機能がInboxに入るかその逆があればすごいいいと思うのだが……。

Google Chrome、Linux下での速度問題のまとめと回避方法

(2016年2月22日更新)この問題を修正する変更が開発者により行われ、すでにソースコードに取り込まれています。この変更が実際のリリースに適応されるのにはしばらく時間がかかりますが、近いうちに修正が入るものと思われます。

最近のGoogle Chromeに、すでに何件か報告されている問題で最近原因が解明されたものがあり、その問題と取り敢えずの対処法に関してまとめます。

どういう問題なのか

Google Chromeのアドレスバー(Omnibox)の入力レスポンスがものすごく遅くなります。スペックにもよりますが、具体的には一文字入れるとそれが出てくるまでに数秒を要する、といった具合です。極端な場合には多大な遅延のせいで、入力される文字の順番が入れ替わってしまう場合もあります。(例えば、google.comと入力したつもりがgogole.cmoとなるなど)

また、インターフェース自体の再描画も全体的にもっさりとするため、メニューを開くのに遅延が出るなどの問題が発生し、全体的にGoogle Chromeメインプロセスが消費するCPUが高くなる傾向にあります。

原因は?

バグが報告されていたものの最近までその原因は特定はされていませんでした。1月6日にChromiumプロジェクトのKochi氏がこの問題がフォントのキャッシュがフォントのフォントファミリー名による参照によりキャッシュされていないとみなされ、再キャッシュプロセスが発生してしまうのが原因で発生しているということが報告されました。

つまり、まとめると以下のようになります。(Kochi氏が指摘する源ノ角ゴシック JPを使用した場合)

  • Google Chromeが源ノ角ゴシック JPを使用してフォントをレンダリングしようとする
  • Google Chromeが源ノ角ゴシック JPを使用しようと、そのフォントファミリー名のSource Han Sans JPで参照しようとするが、キャッシュされていないと見做し、キャッシュ動作(非常に重い)が発生する

というようなプロセスが発生し、これが一文字入力されるごとに発生していた、という問題のようです。

尚、上記に併せ、同氏によりコードの修正レビューが提出されていますが、すでにこの修正を含む、書き換え自体が予定されていることもあるようで、パッチとしての適応はされないようです。そのため、根本的な解決にはしばらく時間を要すると予想されます。

回避策

根本的な解決はコードに対処が入るまで行わられないものの、取り敢えず回避することは可能です。基本的にフォントのファミリー名が問題にならないフォントを使用すればいいわけです。尚、こちらで実験したところ、IPAフォントとその亜種ではこの問題が発生してしまうようです。(日本語環境ではこれらが指定されていることも多いでしょうから、この問題にあたってしまう人も多いかもしれません。)

回避方法

前述のように、この問題の影響の受けないフォントに置きかえてやるのが回避する方法になります。Gnomeを使用している場合、gnome-tweak-toolを使用し、UIが使用するフォントを問題のないものに置きかえる必要があります。gnome-tweak-toolは標準ではインストールされていないので別途インストールが必要です。

KDEの場合kde-config-gtk-styleをインストールした上で、外観設定の中のGTK設定のフォントを変えることで対応できます。

KDE GTK Config

フォント設定を例えば、Noto Sans CJK JPなどに置き換えることで対応可能です。

フォント設定

この変更を行い、右下の適応ボタンを押すことで変更が保存されます。尚、Google Chromeに対し、この変更を有効にするためには変更した後に、Google Chromeを再起動する必要があります。

あけましておめでとうございます

あけましておめでとうございます。こちらではまだあけていませんが。

今回も紅白の同時放送を見ていました。去年はGoogle+のコミュニティを使用して独り言などを流していましたが、今年はHidekiBinを使用しました。
当該ペーストは一年で消えますので、PDF版も保全。
第64回紅白歌合戦視聴ログで見られます。(ChromeのPDF保存機能が便利。)

自営WordPressでのアクティビティ

最近、自営Wordpressのアクティビティを上げているのは各種ソーシャルサイトのポリシーに対するヘッジもあるのだがJetpackなどの機能が充実してきているのと、APIを使用するモバイルクライアントの出来がなかなかいいのが大きな理由でもある。