いくやの斬鉄日記

オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。

ibus-kkcでもステータスアイコンを表示する

2017年06月25日 00時17分05秒 | 言語入力機構
ibus-skkでステータスアイコンを表示する方法(と余談)
続・ibus-skkでステータスアイコンを表示する方法
の一環で、ibus-kkcも同じ変更を加えました。

パッチ
パッケージ
パッケージは16.04向けにビルドしていますが、17.04にインストールしてテストしています。

もしかしてこれってFedora Spinsを使っている人しか嬉しくないのかな、と思いましたが、よく考えたら私はFedora Spinsをインストールしたことがないのでibus-kkcを採用しているのかどうなのか知りませんでした。
Fedora 26がリリースされたCinnamon Spinをインストールしてみましょうか。
コメント (2)
この記事をはてなブックマークに追加

ibus-skkでステータスアイコンを表示する方法(と余談)

2017年05月02日 22時00分11秒 | 言語入力機構

ちとわかりにくいと思うので、まずはこれをご覧ください。右上にibus-skkのアイコンが表示されています。文字の入力中ですが、それとわかる表示はありません。


ちょいと改造すると、入力中なので「あ」というアイコンが右上に表示されるようになります。

方法はこんな感じです。以下の一行を追加してIBusを再起動するだけです。

--- /usr/share/ibus/component/skk.xml.orig	2017-05-01 22:25:40.475933434 +0900
+++ /usr/share/ibus/component/skk.xml	2017-05-01 22:25:44.939933434 +0900
@@ -20,6 +20,7 @@
 			<layout>jp</layout>
 			<longname>SKK</longname>
 			<description>SKK Input Method</description>
+			<icon_prop_key>InputMode</icon_prop_key>
 			<rank>70</rank>
 			<symbol>あ</symbol>
 		</engine>


差分ファイルも置いときます。

本当はちゃんとPull Request投げることができるといいのですけど、すぐには無理そうなのでこんなのでお茶を濁しておきます。
確認していませんが、ibus-kkcでも同様の方法で行けると思います。

以下余談ですが、またIM暗黒時代に突入してしまいました。
インプットメソッド(IM)のフレームワークの方(IBusとかFcitx)はわりと活発に開発されていますが、IMエンジンや変換エンジンは、ibus-anthyは活発に開発されているもののリファレンス的な意味合いが強く、Anthyは放置状態ですし、Mozcは今年に入ってからcommitがありません。libskkとibus-skkはメンテナ募集中、libkkcやibus-kkcは最近のリリースはなしということで、現在活発に開発されているものが何もないというのが現状です。当面はMozcをなんとか使っていくことになるのでしょうが、新しい変換エンジンの登場が待たれますね。
コメント
この記事をはてなブックマークに追加

IBusの近況

2016年01月12日 22時18分46秒 | 言語入力機構
最新のIBus (1.5.11)でサポートしたいくつかの機能を紹介します。

1. Appindicator/StatusNotifierのサポート
厳密にいえば、サポートされたのはIBus 1.5.10からですが。

右下を見ると、KDE PlasmaでAnthyのアイコンが表示されています。
Kubuntu 15.10のPlasmaはバージョン5.4.2 (今日現在)で、このバージョンではxembed(レガシーアイコン)サポートがないので、Appindicatorで表示していることがわかります。
とはいえ、Plasma 5.5ではxembedサポートが復活しているのですが。
ちなみに16.04 LTS開発版のIBusは1.5.11になっているのですが、Appindicatorサポートは有効になっていません。バグ報告するつもりですが、代わりにやってくださってもいいのよ。
15.10ではgconfにつまらんバグがあって、IBusのビルドができません。なのでこの環境作るだけで大変でしたよ。

2. アイコンでステータス表示のサポート

今まではopenSUSEのパッチを当てないとできませんでしたが、IBus 1.5.11でMozc 2.17.2313.102をビルドすると、この機能をサポートするようになります。私が知っている限り、現在これができるIMエンジンはMozcだけです。他でもできるようになるといいんですけど。

Xubuntuでももちろん行けるのですが、超見にくいです。どうすればいいんでしょうねこれ。

3. プロパティパネルの表示位置の変更

プロパティパネルを[常に表示する]にした場合、[自動的に隠す]と同じくカーソル(キャレット)の下に表示されていましたが、1.5.11からは右上に表示されるようになりました。ただしKDEとLXDEではスクリーンショットのとおり右下に表示されます(何故?)。
IBus 1.4.xにあった状態パネルが復活した、といえなくもなくもなくもない感じです。どっちやねん。
プロパティパネルの表示位置はソースコード決め打ちで、動かしても保存してくれるわけじゃないですし、復活したとはいえませんね。でも、IBusを使ってもいいかなと思わせる程度には便利だと思います。
あと、左側のハンドルに濃い灰色が付くようにもなりました。これでどこを掴めばいいかがわかりやすくなりました。

追記:
というわけで(?)、ibus-anthyもicon_prop_keyに対応していました。完全にチェックが漏れてました。
コメント (2)
この記事をはてなブックマークに追加

fcitx-mozcの全角アドオン無効pull requestがマージされた

2015年07月27日 22時02分13秒 | 言語入力機構
Fullwidth addon is unnecessary on Mozc.

fcitx-mozcの三日月アイコン(全角アドオン)にハマって半角文字が入力できなくなって困ったことがある人は少なからずいると思います。そんなわけでwikiにも書いたんですが、まぁみんながみんな読んでいるとは限らないですし。

これを無効にする方法がわからなくて、どっかの設定で何とかできるのかなぁと思っていたのですが、どこをどう見てもそんな設定はなかったのでさじを投げてしまっていました。

fcitx-anthyのソースコードを読んでいると、なんと無効にしているところがあるじゃないですか。なるほど、ということでMozcでも同じ修正を加えてテストしてみたらうまく行ったのでpull requestを投げて忘れていました。

そうしたら今日無事にマージされたという連絡が来たので、次のバージョンからは無効になります。安心しました
とはいえ、Mozcも開発スピードが落ちているのか、最近commitされていないようですが……。半年に一度くらい辞書をアップデートしていただけると嬉しいのですがね……。
まーWindows 10もありますし、大丈夫でしょうきっと。
Mozcの新しいバージョンがでないと、fcitx-mozcの新しいバージョンもでませんからね。

現在UbuntuのリポジトリにあるMozcはちょっと古いので、新し目のバージョンをビルドする方法を『うぶんちゅ! まがじん ざっぱ~ん♪ vol.3』で紹介しています。ビルドの基本的な知識は必要ですが、わりと簡単にできるように解説しているので、お買い上げいただけると幸いです。
ぶっちゃけ売れ行きがあんまり(ry
コメント
この記事をはてなブックマークに追加

fcitx-anthyのバグを直した話

2015年05月13日 22時08分37秒 | 言語入力機構
「どんな簡単なことでも、完璧にできるとうれしいもんでしょう」
田中あすか(『響け! ユーフォニアム』5話より)

fcitx-anthyのキーバインド設定が飛ぶというバグは、柴田さんが直してくれました。
このバグはどう頑張っても私には直せないものでした。ありがとうございます。

実はこのバグの検証中に、別なバグを見つけました。
[記号のスタイル]を変更しても、UI上は変更できたように見えても実際には反映されないというバグです。
得てしてこの手のバグは単純なものなので、自分で直すと決意しました。

ソースコードを読み込んで、src/imengine.cppの749行目以降がおかしいので間違いないという確信までは持てました。
void AnthyInstance::set_symbol_style(SymbolStyle symbol)
{
    m_config.m_symbol_style = symbol;
    FcitxUISetStatusString(m_owner,
                            "anthy-symbol-style",
                            _(symbol_style_status[symbol].label),
                            _(symbol_style_status[symbol].description));
    switch (m_config.m_symbol_style)
    {   
        case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH:
            m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
            m_preedit.set_slash_style   (FCITX_ANTHY_SLASH_WIDE);
        case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH:
            m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
            m_preedit.set_slash_style   (FCITX_ANTHY_SLASH_WIDE);
        case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_MIDDLEDOT:
            m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
            m_preedit.set_slash_style   (FCITX_ANTHY_SLASH_JAPANESE);
        case FCITX_ANTHY_SYMBOL_STYLE_JAPANESE:
        default:
            m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
            m_preedit.set_slash_style   (FCITX_ANTHY_SLASH_JAPANESE);
            break;
    }
}

一瞬で気づかないとダメなレベルですよね。

そもそもこれはどういう機能かというと、鉤括弧と中黒キーを変更する機能です。
こういう機能があることは昔取った杵柄で知っていますけど、自分で使ったことはありません。
fcitx-anthyの場合は、
「」・
「」/
[]・
[]/
の4種類から選択できます。まず、この4つの定義はsrc/fcitx-anthy.descにあります。

[General/SymbolStyle]
Type=Enum
Description=Symbol style
DefaultValue=Japanese
EnumCount=4
Enum0=Japanese
Enum1=Wide bracket and wide slash
Enum2=Corner bracket and wide slash
Enum3=Wide bracket and Middle Dot

だめでしょこれ。
「」がwide bracket、[]がcorner braketだとすると、

[General/SymbolStyle]
Type=Enum
Description=Symbol style
DefaultValue=Japanese
EnumCount=4
Enum0=Japanese
Enum1=Wide bracket and wide slash
Enum2=Corner bracket and Middle Dot
Enum3=Corner bracket and wide slash

でないといけません。
(というか書いてて間違いに気づいたことは秘密な!)
ここを変更したら、src/factory.hも変更する必要があります。

typedef enum {
FCITX_ANTHY_SYMBOL_STYLE_JAPANESE,
FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH,
FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_MIDDLEDOT,
FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH,
FCITX_ANTHY_SYMBOL_STYLE_LAST
} SymbolStyle;

これは、

typedef enum {
FCITX_ANTHY_SYMBOL_STYLE_JAPANESE,
FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH,
FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_MIDDLEDOT,
FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH,
FCITX_ANTHY_SYMBOL_STYLE_LAST
} SymbolStyle;

でないといけません。

{
case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_MIDDLEDOT:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
case FCITX_ANTHY_SYMBOL_STYLE_JAPANESE:
default:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
break;
}

これもよく見たら間違っていて、

{
case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_MIDDLEDOT:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
case FCITX_ANTHY_SYMBOL_STYLE_JAPANESE:
default:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
break;
}

が正しいです。ほとんど間違い探しですな。diffがないとわかりにくくてしょうがないです。
で、ここまできて、あれ、これってbreakがないだけじゃね、ということに気がついて、

{
case FCITX_ANTHY_SYMBOL_STYLE_WIDEBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
break;
case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_WIDESLASH:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_WIDE);
break;
case FCITX_ANTHY_SYMBOL_STYLE_CORNERBRACKET_MIDDLEDOT:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_WIDE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
break;
case FCITX_ANTHY_SYMBOL_STYLE_JAPANESE:
default:
m_preedit.set_bracket_style (FCITX_ANTHY_BRACKET_JAPANESE);
m_preedit.set_slash_style (FCITX_ANTHY_SLASH_JAPANESE);
break;
}

としたら意図した通りに動いてくれました。めでたしめでたし。
pull requestはこれです。
C言語の文法はわかりませんけど、switch文はシェルスクリプトと同じなので、breakが必須であることは知ってました。自分ではswitch文はあまり書かないですけど。
breakがないからdefaultまでいっちゃうので、UI上では変更したのにもかかわらずそれが反映されない、というバグの挙動とも一致します。

今回わかったことは、本来どう動くべきなのかがわかっているといろいろと話が早いということと、今回はシェルスクリプトの知識で乗り越えられたものの、やっぱりC言語の文法知らなきゃダメだよね、ということです。
ちょっとC言語の勉強してきます……。
コメント (3)
この記事をはてなブックマークに追加

libkkcのATOKキーバインドがマージされた

2015年05月12日 21時51分05秒 | 言語入力機構
コミットログはこれこれ
commitする前にpushするという間抜けなことをやらかしてしまい、2つに分かれてしまいました。
しかもしばらく何が起こったのかわからなかったんですよね。ダメダメですね。
以後気をつけます。

pull request自体はこれで、まぁ見ていただければ、どうやればキーバインドを追加できるのかおおむね解ると思います。
Microsoft IMEのキーバインドを追加するとか、実は有効になってないだけでたくさんのキーバインドがあるので、これをテストしてみて特に問題がなければ有効にするようなPRを投げてみるとか、興味ある人は挑戦してみるといいんじゃないかなぁと思います。

Anthyと違ってlibkkcを使用しているIMエンジン(ここではibus-kkcとかfcitx-kkcのこと)に手を加えなくてもキーバインドを有効にすることができるので、その点もいいなぁと思います。
コメント
この記事をはてなブックマークに追加

libkkcにATOKキーバインドを付けてみた

2015年05月04日 19時34分51秒 | 言語入力機構


libkkcにATOKキーバインドがないと悲しいので、ちょっと作ってみました。
まずはここからダウンロードして、
$ tar xf libkkc-atok-style.tar.gz -C ~/
とかやってFcitx/IBusを再起動して、ATOKキーバインドに変更してください。
IBusの場合は「タイピング方式」で、Fcitxの場合は↑のスクリーンショットのとおり、ショートカットでATOKを選択して保存してください。

設定ルールはこちらにありますので、問題があった場合はこれを念頭に入れつつご指摘頂けると幸いです。
特に問題なさそうな場合はpull requestを送ろうかなぁと思いますが、あまりニーズはないような気もします。

追記:
GitHubにpushしました。
コメント
この記事をはてなブックマークに追加

Mozcのコードツリーからibus-mozcのソースが削除される予定に関して

2015年04月14日 21時58分55秒 | 言語入力機構
Mozcのバグ報告はひととおり目を通しているのですが、Deprecation of the iBus client code.という報告を見て、ついにその日が来たかと思いました。
遅くても今年の8月中には、ibus-mozcのソースコードが削除される予定、とのことです。

本文中にもあるとおり既定路線で、前後関係や事実関係が正しい自信はないものの、ざっくり経緯を解説すると、Chrome OS/Chromium OSにインプットメソッドがなかったので、IBusを採用することになった、それに伴ってオリジナルの開発者さんがRed HatからGoogleに転職してChrome OSでIBusが動作するようになったものの、Chrome OS/Chromium OSはChrome/Chromiumしか動いてないので、別にそこだけで動作する(NaCLで動作する)だけでいいんじゃね? ということになり、実際にそうなりました
となるとibus-mozcをGoogleでメンテナンスする積極的な理由がなくなり、2013年7月からメンテナンスモードになりました
確かにプライオリティは下がったものの、引き取り手を探しながら2年以上メンテナンスを続けるのは立派だと思うのです。責められるようなことには思えません。

もしこのままibus-mozcのソースコードが削除された場合でも、(非常にざっくりですが)unix/ibus以下をパッチとして保持しておき、ビルドできるようにすれば、ibus-mozcの動作自体は可能です。
Debian/UbuntuのMozcにはfcitx-mozcもuim-mozcもありますが、この方式を取っています。
もちろん、Mozcの開発が進んでibus-mozcと整合性が取れなくなったら動作しなくなりますが。

どなたか引き取り手があればいいのですけど、引き取り手がなければscim-mozcのように消滅するのかもしれません。

ちなみに私はfcitx-mozcで幸せに暮らしております。最近辞書がアップデートされたので、自前でビルドしました。
Mozc-2.17.2076.102←バージョンの変換結果

追記(8/29)
削除の時期が年末に延長しました。
コメント (1)
この記事をはてなブックマークに追加

Mozcで絵文字入力

2015年01月23日 01時04分43秒 | 言語入力機構
急にMozcで絵文字入力がやりたくなったので、やってしまいました。
絵文字ってこんなのです。→🍆(ナス)
表示できてますか?

入力するだけならMozc設定ツール(Mozcプロパティ)の辞書タブにある[Unicode 6 絵文字変換]にチェックを入れればいいのですが、入力時に(より厳密には候補ウィンドウで)トーフになってしまいます。これは単純にフォントがないせいですね。

そーいや絵文字フォントがあったなぁ、どこで見たんだったかな……としばらく頑張ってたら思い出しました。
New input-pad 1.0.99.20140916 is released
です。
ここにあるとおりttf-ancient-fontsパッケージをインストールし、IM(Fcitx/IBus/uim)を再起動すれば、入力時に表示されるようになります。
ただ、確定後もちゃんと表示されるかはまた別の話です。LibO Writerでは表示できませんでした。
↓極めてうまく行った例

コメント
この記事をはてなブックマークに追加

Fcitxの翻訳に関して

2014年11月11日 22時43分45秒 | 言語入力機構
Fcitxの翻訳はTransifexで行われていますが、日本語のコーディネーターは私です。
コーディネーターは翻訳できる他、メンバー申請に対して承認と拒否ができます。

どういう基準で承認または拒否するかは結構揺れていたのですが、現在は
・私の友人知人または一方的に存じ上げている方は、ほぼ無条件に承認。みんな私よりすごい人たちばかりなので
・私が存じあげない方は、これまでの実績を見て決定
という感じになっています。
じゃあ未経験者はダメなのかというと、例えば明らかに学生さんである場合とかは承認します。多少おかしな翻訳があった場合は修正しますし、それは私の義務だと考えています。
しかし、若い方はIMではなくもっと面白い別なものに目を向けて欲しいとも思います。

というわけで、場合によっては拒否することもあります。
私はコーディネーターとしてFcitxの翻訳をいい感じに保つ必要があるので、ひどい翻訳が入ったら修正しなければいけないわけですが、なかなかそんな時間取れませんし、そもそも酷い翻訳(あるいは日本語になっていない何か)にするくらいなら英語のままの方がずっとよく、100%の翻訳率を目指しているわけではない、というのもあります。
それにそもそもとして、そういうのの修正ってモチベーションがわかないんですよ。そらそうでしょう。誰が好き好んで人の尻拭いなんてやりたがるんですか。

承認や拒否、あるいはFcitxの翻訳に関して気づいたことがあったら私に直接問い合わせていただきたい(あるいは実績のある方はメンバー申請して欲しい)です。
拒否されたこととか公開の場で質問されてもいいですけど、その理由を公開の場で言われるのって辛くないです? 参考までに私の回答。typoは見なかったことに。提示したURLに他意はありません。そこにも書いたとおりただコメントを求めただけですからね?

拒否なんてしたら波風立つに決まってるんだからおとなしく承認すればいいじゃんという考え方もあるのは重々承知していますが、私はそういうことはできません。
それなりのこだわりがなかったら10年も継続できるわけないでしょう。

追記(2014/11/12):
返信がきました。
……。
私は翻訳がイマイチだと言ったのですから、自分はうまくやれる、ということを客観的に示せばいいと思うんですよ。Fcitxのja.poに直接翻訳するとか、方法はあると思います。
それがこれですからね。私からはこれ以上特に何か言うことはないです。
コミュニティに長くいるだけのボンクラめ、というニュアンスだとは思うのですが、それは私自身もそう思っているので別にいいのですけど、得てして説得する相手というのはそういう人じゃないですか。それなりの社会人経験がある方はわかると思うんですけど。
コメント (5)
この記事をはてなブックマークに追加