日本語入力メソッド総合スレッド [無断転載禁止]©2ch.net

>>476
なんかあれですよね。
mozc-utが色々揉めたので色んなところが影響を受けたんじゃないかと。
>>478
mozc-utの頃は良かったんですよね。
昔のUbuntuのBBS等の書き込み見てるとmozc-ut入れて変換できるようになったよとか書いているので。
今でも、Ubuntu使ってる人はmozc-utビルドして使ってるみたいですね。
Fedoraとか聞かないんですが、日本語入力とかしてないのかな？

今回作った辞書はやったことも含めて、もし必要であればアップロードも可能です。
アップロード先は教えてください。
登録字数：45936
元データ：https://github.com/KEINOS/google-ime-user-dictionary-ja-en?tab=readme-ov-file

昔、中村主水が一発で変換出来た事に感激した思い出
SKK だけど。

中村主水

libkkc + ibus でも一発でしたw

開発者がいい仕事してますね

MacのTahoeの上のVMwareFusionProの上のUbuntu 25.10で
キーボード、IM設定グシャグシャになって、chatgptに
相談してUTM上でUbuntu 24.10でJapanese(OADG109A)キー配列で
Macの日本語JIS配列キーボードで記号が漏れなく打てるから
とそれにして、システム全体の日本語化はまたIMが崩れるから
ダメ！！と言われてそうしてる。
半角英数<=>日本語ローマ字入力の切り替えは、option+spaceで。

https://xxup.org/I9sff.png

https://xxup.org/Qkuoa.png

AI は知恵遅れ

お猿さーんだよー

libkkc を最近始めた人はディストリビューションによってskkdic が分かれているから他に辞書が無いかも見ときなよ。
skkdicで SKK-JISYO.L しか入らないのが Debian で skkdic-extra が別にある。
Fedora は skkdic で SKK-JISYO.L 以外も入る。

>>486
ありがとう、それ気づいてるよ。
この辞書の文字コードとか色々あるんだよね。libkkcの辞書って文字コードは何で保存するのが正しいのかな？

/usr/share/skk/SKK-JISYO.JIS2: ISO-8859 text, with very long lines (515)
/usr/share/skk/SKK-JISYO.JIS2004: ISO-8859 text
/usr/share/skk/SKK-JISYO.JIS3_4: Non-ISO extended-ASCII text, with very long lines (418)
/usr/share/skk/SKK-JISYO.L: ISO-8859 text
/usr/share/skk/SKK-JISYO.L.unannotated: ISO-8859 text
/usr/share/skk/SKK-JISYO.M: ISO-8859 text, with very long lines (337)
/usr/share/skk/SKK-JISYO.ML: ISO-8859 text
/usr/share/skk/SKK-JISYO.S: ISO-8859 text
/usr/share/skk/SKK-JISYO.assoc: ISO-8859 text
/usr/share/skk/SKK-JISYO.china_taiwan: ISO-8859 text
/usr/share/skk/SKK-JISYO.china_taiwan.header: ISO-8859 text
/usr/share/skk/SKK-JISYO.edict: ISO-8859 text, with very long lines (372)
/usr/share/skk/SKK-JISYO.edict2: Unicode text, UTF-8 text
/usr/share/skk/SKK-JISYO.emoji: Unicode text, UTF-8 text, with very long lines (1618)

--いっぱいあるので省略--

あと知りたいのはLibkkcの辞書はどこにconfigあるんだろう。
guiだとlibkkcはこうなってます。guiしか設定できないのかな？
"あいおいちょう /相生町/愛生町/相生丁/"とか変換できるので、SKK-JISYO.geoが有効になってるのはわかるんですが。
https://i.imgur.com/AoILyX9.png

sskはこうなってるんです。うちの環境だと。
でもshift押しながらうまく変換できないので確かめられない。
これ本当に難しい。
https://i.imgur.com/Yd8cyAA.png

Jack has A bat and two balls

この説明だったり
https://chienomi.org/archives/livewithlinux/885
この辺り
/usr/share/fcitx5/kkc/dictionary_list

>>490
ありがとう。
きびしいね。やっぱりmozc-utを自前で何とかするしかないんだろうなぁ。

SKK の方はこんな問題だろう。情報が古いから今とは違うだろうけど
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0175

DDSKK は気に入ってるのに fcitx5-skk の挙動がポンコツ過ぎて嫌だわあ
アルファベット入力中に ctrl キーを押した途端に backspace をはじめキー入力を受け付けなくなってしまう
これがなければ常用するんだがな

>>493
似てたりしますか？
https://github.com/fcitx/fcitx5-skk/issues/27

fcitx と mozc は要らない子

>>493
> アルファベット入力中に ctrl キーを押した途端に backspace をはじめキー入力を受け付けなくなってしまう

「アルファベット入力中」って、例えば「/alpha」と入力するとこの↓状態?

$ ▽alpha

であれば [ctrl] キーも [BS] キーも、うちでは利く。

$ dpkg -l fcitx5-skk | tail -n 1
ii fcitx5-skk:amd64 5.1.1-1build3 amd64 Japanese SKK input engine for Fcitx5

hazkey 0.2.1が出てるよー

>>497
ありがとー

>>497
うーん、こんな感じで動かないかとか色々やっては見たけどもダメだな〜
debianパッケージをrpm系で…

spotify-launcher
https://github.com/kpcyrd/spotify-launcher

ばーじょん
Mozc-3.33.6089.102+24.11.oss

>>500
どう変わりましたか？
教えてください、お願いします。

https://github.com/google/mozc/commit/8f92cd985cba2fd009545963698f4df7424bec56

こっちも期待

karukan-im ローカルLLMを使った日本語入力システム
https://github.com/togatoga/karukan

>>503
教えてくれてありがとうございます！
Hazkey使えなかったけど、これでLive変換戻ってきました
Mozcより変換効率いいよね〜

rust で書かれているのか

karukanで"Hugging Face"を知ったけど、このプロジェクトもすごいな。
将来のタチコマの元になるデーターがいっぱいある。

xubuntu daily入れ直したら
fcitx-mozcとibus-mozcとmozcがない
とにかくmozc関連すべてないsynapticで
とりあえずfcitx5-anthy入れといた

karukan-imは今二つ謎？

・全角記号ってどう出すんだろう？ ／、⋯ とか
・"Right Super 英数字/カタカナ → ひらがなモードに復帰" このRightSuperがないなぁ‥

>>508
まだ機能もソースもよくわかってないのですが
全角記号は辞書ファイルに載せてあげる必要がありそうな気が...

目標が私用ですけど、JISかな入力できるようにkarukan-imに修正を入れてみて
かな漢字変換自体は、なんとかできるようになりました

有望なIMEがFcitx5向けばっかで悲しぃ😢

Waylandのせい
もうWayland強制が近づいてきてる

>>509
なんかもう少し情欲しいですね
ソース見る方が早いのかな？
ビーム幅とか

>>508
>>509だけどユーザ辞書経由で／…を出せるようになったよ

- mozcで使っていたユーザ辞書をmozcの辞書ツールからエクスポート
- cargo run --release --bin karukan-dict -- build mozc_export.txt -o dict.bin
- 出来上がったdict.bin を ~/.local/share/karukan-im/user_dicts にコピー

>>513
そうなんですね
自分は学習辞書(learning.tsv)をなんとかするのかなと思って調べてました
githubのissuesにも下記がありますので、楽しみに待ってみようかと

"記号や全角・半角の変換候補パターンを増やす"

メモリ消費800MB以下。脱GUIで省メモリな日本語環境の可能性を探る
Ubuntu Japanese Team/日本仮想化技術株式会社 水野源
2026年3月7日
https://pc.watch.impress.co.jp/docs/column/ubuntu/2091326.html

>>515
パーツ高騰で新調できない！←わかる
古いマシンを復活させるぞ！←わかる
GUIは重すぎる！←いつの時代のPCだよ…

>>515
面白い記事で新しい情報に自分的に得るものがあったけど、
自分の鯖運用にCLIでWebを見たり
動画再生をする必要性を感じるかと言うと…

普通にCLIで鯖運用するならSSH接続で管理して
その接続するクライアントPCでブラウザ開いて動画見るわね…
セキュリティ的な視点からも

>>510
何で？中国父さん様々だが

>>518
Fcitxが嫌いって訳じゃないんだけど、Gnomeだといまいちしっくりこないというか…
まぁ、GnomeがIbus決め打ちじゃなくKDEみたいに柔軟に対応してくれたらいいんだけどね

3.33.6133
https://github.com/google/mozc/commit/c9163b6bb1010671781b8acd358b025c519fc1e0

Arch系でfcitx5-cskkを導入できたかた、お力を貸してください

$ fcitx5-diagnose
**アドオン `Cskk` の `fcitx5-cskk` に必要な次のライブラリが見つかりません。**

libcskk.so.3

で詰まっています。

やったこと：
yay -S cskk
yay -S fcitx5-cskk

環境：
CachyOS Linux
KDE Plasma バージョン: 6.6.3
カーネルバージョン: 6.19.10-1-cachyos (64 ビット)
グラフィックプラットフォーム: Wayland
プロセッサ: 4 × Intel® Core™ i5-4300U CPU @ 1.90GHz
メモリ: 4 GiB の RAM (3.7 GiB 使用可能)
グラフィックプロセッサ: Intel® HD Graphics 4400

>>521
少し調べてみた
($ yay -S fcitx5-cskk-git)

mkdir cskk
cd cskk
git clone https://github.com/fcitx/fcitx5-cskk.git

README.md にある手順でビルド
cd fcitx5-cskk
mkdir build
cd build
cmake ..
make
sudo make install

cd /usr/cskk
ls -l
sudo cp -r libcskk.so* ../

sudo ldconfig
reboot

libcskk.so.3の問題はクリアされて、ローマ字入力はできるようになったが
辞書ファイルがみつからないせいなのか漢字変換はできなかった

×　cd /usr/cskk
❍　cd /usr/lib/cskk

>>522
ありがとうございます！cskkで入力できるようになりました

>>514
karukan-imのフォーク版が公開されていた
https://github.com/riq0h/karukan

記号辞書などの辞書や、本体の更新で入力しやすくなったよ

いいね

>>525
お知らせ有難うございます。
早速、使ってみます。

gitで開発者に要望出すのってどのくらいのレベルだと嫌がられますかね⋯
ソフトウェア開発になんにも貢献できてない一般ユーザーからなんですけど

未変換文字列に対してdeleteするとき、かな漢字テーブルが
"s h o" = "しょ"
だと「しょ」が消えて
"s h o" = "し" "ょ"
だと「ょ」だけが消える
みたいな挙動だとうれしい。uimがそうだったので

でもこれって他の人への影響が甚大だから無理そう

違いが分かりません

わからないけど、uimとfcitx5では挙動が違うとかでは?
どの入力メソッドなのか不明だけど……

Ibusの導入方法が少し変わったみたい
自動起動に使うコマンドはibus-daemonからibus startに変更
Text Input v2をサポートしてるWaylandコンポジターはオプションに --type=wayland 使用可
Waylandは基本的に環境変数の設定は必要ないけど、上手く機能しない場合は$HOME/.bashrcに↓を追加
export GTK_IM_MODULE=wayland
export XMODIFIERS=@im=ibus
export QT_IM_MODULES=wayland;ibus
export QT_IM_MODULE=ibus

SwayでIbusが不安定だから調べてみたらSway公式の推奨アプリのリストにIbus入ってなかったわ…
そんな訳でFcitx5に乗り換えたというかFcitx5-AnthyってQtなしで動くのな
すごく安定してる

Fcitx5入れたついでにKarukan試してみた
ヌルヌル変換できるし辞書編集も楽で使いやすいな

ibus-skkではウィンドウごとにカナ/英数モードを覚えてくれないのが不満だったが
fcitx-skkでは覚えてくれていい感じ

fcitx5-skk

>>534
IBusもウィンドウごとに入力ソースを別ける設定があったと思う

fcitx5-skk (5.1.6-1) で「寝落ち」を登録しようとして「NeoTi」と入力したら
「▼ねお*ち【】」と辞書登録モードになり「▼ねお*ち【寝落ち】」と入力し確定
user.dict には「ねお*ち /寝落ち/」と登録されているものの
「NeoTi」と入力したら、また辞書登録モードになってしまいました
また user.dict に登録された「寝落ち」を削除しようとして「NeoTiX」と入力したら
「▼ねお*ち【▽x】」となりうまく削除できませんでした
何が悪いんだろう？

なおSKK-JISYO.Lには * のついた送り仮名って登録されてないみたい

日本語入力めっちゃ退化してるよな
30年前のATOK変換が文法、統語的に綺麗でよかった

anthy がクセがあって嫌って話？

そもそも日本語入力がコンピュータとの相性最悪なんだよな
どんなに優れた入力機構であろうと変換が期待通りにできたか確認する必要がある
変換のいらない英語とかならタイピングが完璧なら確認なく期待通りに入力できる

日本語でも漢字直接入力のT-Codeなどがあるという人もいるかもしれないが
学習コストが高すぎて標準になる可能性はゼロだ

脳で考えていることをそのまま入力できるようになればまた話はかわるが
いつになったら実現できることやら

じっくりと学習させた辞書を使い、ある時点で学習機能を切るのもひとつの手なのかもしれない
例えば「こうしょう」を変換するとき、最初は「交渉」次は「高尚」だと人間が学習する作戦だ
なんでも「こうしょう」には50種類ほどの同音異義語があるらしいが、よく使う変換を
覚えてしまえば、覚えた変換を使っている限り変換結果を確認する必要がなくなる

>>537
user.dict には「ねおt /寝落/」と登録されるべきとちゃう?

>>542
その通りです
ただし今回の場合は自分が間違えて送り仮名も含めて登録しているので送り仮名があるのは正常です
>「▼ねお*ち【】」と辞書登録モードになり「▼ねお*ち【寝落ち】」と入力し確定

また「ねおt」でなく「ねお*ち」になっている理由はわかりませんが
ibus-skkでも、自分で追加登録した送り仮名つきの単語は「ねお*ち/寝落/」のようになってました
なおSKK-JISYO.Lのようなシステム辞書にある送り仮名つき単語は「わりこm /割り込/」のようになっています

>>543
うちの fcitx5-skk 5.1.10 版では、
AkioTi という読みで「秋落」を入力すると user.dict は「あきおt /秋落/」
KomaoTi という読みで「駒落ち」を入力すると user.dict は「こまおt /駒落ち/」
となり、読みにアスタリスクは入らなかった。

>>544
最新版での確認ありがとうございます
もしかするとuser.dictを管理しているのはfcitx5-skkではなくlibskk0っぽいので
自分が使っていたlibskk0(1.0.5+git20240901-2)がアスタリスクがつく原因なのかもしれません

>>541
なるほど 変換候補の順番がが固定化されるのか 良いかもしれない

>>544
やはりlibskkが原因で1.0.5の次のリリースの1.1.0で修正されたようです

Unexpected dictionary registration behavior with okuri-ari entry #77
https://github.com/ueno/libskk/issues/77

Forkされた rust版のKarukanがアップデートされて更に使いやすくなっていたので

https://github.com/riq0h/karukan

Karukanって本家もrustじゃないの？

ibus版も出してほしいな🥺

>>549
だね

元もRustだったね
オリジナルの人も、Fork版出した人もサクッと日本語変換、作っちゃうってすごい才能

おれはibus-anthy一択。理由は教えない。

karukanは、なんだろう。普通に＂VIVANT＂とか変換できるのですごいと思う。

確かにカルカンはすごいね。
ただまだ自書機能と細かい設定機能とかはまだない感じかな？

>>554
辞書ファイルはmozcの形式に準拠だったかな
付属のツールでバイナリ変換したのを ~/.local/share/karukan-im/ に放り込めば読み込める
ちょっとしたものであれば平文でもおk
少し試しただけでうろ覚えだから自分で確認してみて

Hazkey使ってたけどKarukanの方がユーザー辞書が使えるので乗り換えたわ

あぁただファンクションキーでの変換が効かないのが微妙

fcitx5の開発はチャイニーズらしいが
問題はないのか
日本向けは怪しいコードが混入しているとかはないのかw

心配ならソースを読めよ

mozcや新しい日本語入力はfcitx5向けに開発されてますし
後方互換無視のibusはgtk3ベースのアプリですら挙動が怪しいですし
セキュリティが心配ならパーミッションの管理が楽なflatpak版fcitx使えばいい

読むのは勿論ビルドがめんどくさい
go rust python haskel あとなんかわすれたけど次から次にビルド環境が増えてく

入力情報の外部送信とかw

>>562
flatpak版いれてネットワーク禁止にすりゃいいじゃん

>>563
分かりました
ありがとうございます

>>564
そんなので大丈夫だと思うの？
素人をだますのは良くない

中共憎しでまともに物事を判断できないやつはwindows使ったほうが安全だと思う
linux消して壺でも磨いてろバカウヨ

遠からずlinuxを支那国内では使えなくなっちゃうかもよ

GithUbのSourceでも何でも、くまのプーさん（出来れば実写）を入れとけばいいかと
何かの拍子に突然表示されちゃうとか

ネットワーク禁止まで考えるのなら、ポメラで入力すればいいかと思うけど
さすがにポメラはスレ違いだね

いいよねポメラ
しかしあの程度のガジェットもっと安くできんのかな
2万円くらいが適正価格だと思うが

>>569
俺はほとんどのアプリで不要なネット接続や関係のないディレクトリへのアクセスを制限してるぞ
flatpakじゃないのはapparmor使って
神経質かもしれないがwindowsやセandroidほどセキュリティソフトが充実してないlinuxじゃ有用な防衛手段だろ

>>571
そういう意味なら、それはわかるけど
ネットワーク禁止なところが思い浮かんだのでポメラとかかなと

意識高そうなセキュアなつもりは事故の元

>>573
パーミッション管理ごときで事故起こすよなやつにはlinuxは早い
残クレiphoneでもいじってろよバカウヨ

>>560
されてない
mozcはunixドメインソケットを介した接続をする仕様でfcitx向けってことは断じて無い

>>575
付属のツールがqtベースなのとibusだと用例表示ができなかったり、不安定だったりでfcitx向けだと勘違いしてたわ
よくよく思い出してみると相性の悪さってwayland移行後のibusが原因か？

ibusが原因だろうね、開発力が足りてない

ibusもgnomeもredhatが開発主体だから、gnome環境のことしか考えてないし
mozcが出てきた当時はibusとuimくらいしか日本語に対応したimfがなかったから
googleがibus用のブリッジを書いたけど
https://github.com/google/mozc/tree/master/src/unix/ibus
redhatはanthy-utf8を標準に採用してるくらいだから、mozcにそこまで執着してないんじゃないだろうか

諸悪の根源はwayland にチャイナ出自

Fcitxがチャイニーズインプットトイの略と知った時は驚いたものだ
便利に使わせてもらってはいるけども

いずれそのうちDEが・・・とか思ってるけども
KDEとか・・・
GnomeはIbusまるっと取り込んだよね

gtkにibusやgnomeの絵文字ビューア対応コードがハードコーディングされてるの頭おかしい

waylandでmozc使うだけならibusもfcitxも必要なくて
mozcだけ使えるibus的なものをgtkもqtも使わないように書いたんだけど
ソースがc++で50KBくらい、実行ファイルがprotobufを静的リンクして2MBくらい

>>582
是非公開して、どうぞ

あのさ、なんでATOKの話しないの？
撤退した理由とか復活願う嘆願書とか

>>584
誰もATOKを必要としていないから

>>585
変換効率は最高なのに？
実質Google版はたまにポカな変換やるで

windowsからLinuxへと巷で謳ってるくせに日本語変換はほとんどが設定されてない
これにはコマンド操作が必要なのに初心者にとっては高すぎる障壁でしょう
だから特に日本でLinuxが普及するとは到底思えませんね
ということで、誰か賢い日本人が日本語変換の取り込み用のパッケージを提供してくれれば一発で出来るようになるのにといつも思ってます
ここでくだまいてるエセ評論家のみなさんの中からひとりでも作っていただければと思いますがそういう勇気はなさそうなので失望してます

>>587
コマンド操作も何も
apt install fcitx5-mozc
dnf install fcitx5-mozc
yay -S fcitx5-mozc-ut
って数文字打ち込むだけなのに何の障壁があると言うのか
ディストリのISOをUSBに焼く方が遥かに難しい

GnomeやKDEならGUIのパッケージマネージャーでFlatpak版のFcitx5-Mozcインストールできますし

Aiに聞いてコピペするだけだからそんなに面倒でもないけど
OSインスコ直後に日本語入力出来ないとテンパるのはわかる
俺も最初テンパった

>>588
それが障壁だって何で気がつかないのか摩訶不思議な日本！
googlebookも日本じゃ発売されないし。。。

ATOKはサブスク化したり「不快語」とか勝手に設定して変換できなくなったりして終わった。

20年前ならいざ知らず、最近のメッジャーなディストリならインストール時の言語選択で日本語を選ぶだけでインストール直後から日本語入力が可能になっているだろ。

もっとも、デフォルトの日本語入力システムから変更しようとすると(例えば ibus→fcitx5 とか anthy→mozc とか)多少の知識が必要になってくるのは確かだが、それとてもGUIなパッケージマネージャーから必要なもの入れれば大抵なんとかなるだろ。

hazkey+zenzaiやkarukanといったAIを使った文脈を考慮した変換は面白いし、未来を感じるよね。
うちのivy bridgeの低スペマシンでは快適には程遠いけど。

ATOKはサブスクじゃなきゃ買ってもいいんだがな
そういう冷やかし相手には商売しないということか…

>>594
昔は、豊富な辞書機能が売りだった日本語入力も、今やもう辞書登録せずにどこまで使えるかって感じだよね
後はこの内部で動くAIがどんどん使い勝手いいものになれば最強かなと
最後はもう文章の添削や提案までしてくれるようになると思う

>>593
コマンド操作が１つでもあるとwindowsから移行したいと思ってる人(日本人)は絶対に敬遠する！
とにかくパッケージ作ってよ
それが出来ないなら！エセを語る資格無し！
googlebookからも見放された我が日本人は未だにガラパゴスから逃げ出せないんですね！

hazkeyはサイズがでかいだけあってAI使わなくてもmozcより効率が良く感じる

ATOKは官公庁や大企業御用達になって
生き延びることにしたんだからLinuxとは相性が悪い

かるかんをGPU使うようにBuildしてるんだけどCUDAが見つからなくて難儀しとる

>>600
言ってくれてありがとう
自分も今、それだったのでnvccというかcuda-toolkitをインストールしてから再ビルドしてみます

>>591
推進してるって？誰も推進してない気がするけど
そもそもLinuxは営利ではないのでもし政府が推進、もしくは地方団体が推進、企業が推進なら多分その団体がしっかりとした
日本語パッケージのインストールCDでも作るだろうけど費用かかるしメンテも必要になってくるのでまずWindowsみたいに有料になるよ
ライセンス制になって1ライセンス1万円位は最低（数売れないから本当は5万くらいにしたいだろうけどw）取るんじゃないかな
そうじゃないと成り立たない

なんかあれかな
Win11の切替で知り合いにLinuxを勧めてみたけど日本語変換できないとかで文句言われたん？
それともセットアップ終わって、日本語入力の設定せずに渡してそれで色々言われたとか？
めっちゃ、文句言ってるよなぁ Zorinとか Ubuntu Desktop(Japanese Team版)とかあるやん

日本語設定くらいできない奴はどっちにしても大した事はできんよな

難易度で言ったら一太郎買ってATOKのサブスク申し込むほうが難しいしな(ソースはうちの親)

ちなLinux Nihonngokaでも普通に検索に当たるしな

>>591がLinuxユーザーになったところで既存Linuxユーザーの誰も得しないもの
Windowsは掲示板やSNS上に宣伝要員みたいなのが居て売れたら喜ぶ人がいるのだろうがLinuxはボランティア宣伝員で利益がない
Linuxデスクトップアプリやドライバはすでに充実してるから今以上にシェアが増えるメリットはない
対応PCが安く入手できてるのにしてもWindowsPCが安価にバラ撒かれてることが前提に合ってOSなしPCがPCのデフォになったら逆に値段上がりそう

>>584
ソースを全て公開してくれたら、ATOK の話になると思うけど。

それはそうと、karukan の config.toml ってみんなどうしてる？
なにもいじってない？ 最適化の提案あればよろしくお願いします。

WindowsのATOKがwineで動くの知らないのか？

>>610
WindowsのATOKをwine経由で使うwimeというのが >>177 ありますが

wimeではなく、wineそのもので動くのですか?

"不快語"なんてお金のために言葉狩りに手を貸したATOKなんかダメだろ。
小説も書けないし、5chに書き込むのも支障があるぞｗ

特許は20年だから、日本語変換関連特許で2006年までのは全部切れてる
それらを全部探しだして実装した日本語IM作ればかなり良いものが出来るはず
でも特許を精査するのは時間も労力も掛かるから誰もやらないんだよな

今のLinuxはHazkey＋ZenzaiがあるからATOKの必要性自体がないが

>>611
ゴミみたいな揚げ足取りだなとは思うがWineそのもので動くかというと動く。
その場合Wine上で動いているアプリにのみ入力ができる。

Windows使ってやれよw

flatpakのfcitxもfltpakアプリへの入力だけよね？

>>617
flatpak以外にも入力できるよ

ATOK使っているやつは本当におもしろいな
そういう特性のやつしか使っていない

>>618
そうなんだ。うまくいかなかったのは俺環のせいか またやってみる

>>620
通常のfcitxと同じようにwikiを見ながらやれば大丈夫だと思うよ
とりあえず心当たりがあるものとしては
・waylandでは原則、環境変数の設定は必要なし
・gtk3ベースのアプリで入力できない場合は ~/.config/gtk-3.0/settings.ini に gtk-im-module=fcitx を追記
・xwaylandで入力できない場合は環境変数に XMODIFIERS=@im=fcitx を設定
・gnomeで使用する場合、シェル拡張のinput method panelが必要