質問

[KazumaProject]

何でもどうぞ

[hanubeki]

#89 が実装されないままクローズされているようですが、この場合Close as not plannedとした方が良いのではないでしょうか。

[KazumaProject]

ご指摘ありがとうございます！
ご提案のとおり、"Close as not planned" として対応いたしました。

[hanubeki]

スミレ入力βにて、以前は（十字方向の）フリック入力もあった気がするのですが、廃止されたのでしょうか。
従来あったフリック入力と被っていたので納得はできますが。

[KazumaProject]

ご質問ありがとうございます。
アプリ内からアプリのバージョンを5回タップしていただきますと入力方式を変更する設定を表示することができます。
ぜひお試しください。

[hanubeki]

試してみました。
しかし、キーボードが開いてから、もしくはスミレ入力βに切り替えてから最初の1文字目がフリックではなくスミレ入力になってしまうようです。

[KazumaProject]

ご報告ありがとうございます。
先ほど、修正を加えたリリースファイルを Play Store にアップロードいたしました。
お手数をおかけいたしますが、アプリをアップデートのうえ、ご確認いただけますと幸いです。

#161

[hanubeki]

返信が遅くなってすみません。
最初の1文字目の問題の修正を確認しました。

[tetta-pdnt]

「日本語 - かな」キーボードと「日本語 - スミレ入力β」キーボードの差分について

• 現状の差分は以下であると認識しています
  • かな
    • IME切り替えボタンの表示/非表示が設定可能
    • 英字入力がQWERTYレイアウトに変更可能
  • スミレ入力β
    • キーの配置を変更可能
    • 入力スタイルを変更可能
• 個人的には英字入力がQWERTYレイアウト かつ ３段フリック入力を行いたいので，どちらかのキーボードにもう片方の機能を追加実装したいと考えています
  • 例えば [FEATURE] スミレ入力キーボードの英字入力時にQWERTY配列を設定できるような機能 #507 にて要望したような，スミレ入力βにてQWERTYレイアウトに変更可能な設定を追加するなど
• これらを検討するにあたって，それぞれのキーボードの今後の方向性や，あえて区別している理由があれば確認しておきたいです

[KazumaProject]

@tetta-pdnt

ご質問ありがとうございます。また、現状の差分まで整理していただき助かります。

キーボードの方向性としては、「かな」「スミレ入力β」を厳密に分けて育てていくというよりも、最終的にはどちらも同等の機能を持てるようにしていきたいと考えています。そのため、「かな」にはあるけれど「スミレ入力β」にはまだない機能があるのは、意図的な切り分けではなく、単純に実装や検証がまだ追いついていないだけというのが正直なところです。個人的にも、「英字入力は QWERTY レイアウト」という組み合わせはニーズがあると感じているので、「スミレ入力β側にも QWERTY レイアウトを設定できるようにする」機能の実装を検討しています。

もしよろしければ、#507 でご提案いただいた内容をベースに、「スミレ入力β に QWERTY レイアウトを追加する」案について議論を進められれば嬉しいですし、ご興味とお時間があれば PR を作成していただく形も大歓迎です。

[tetta-pdnt]

@KazumaProject
ご回答頂きありがとうございます！

現状の差分は意図的な切り分けではない旨，理解しました
一旦は「スミレ入力β」側をベースに，「かな」から欲しい機能を追加実装する方針でPRを作成してみようと思います

#507 についてもPRを作ってみようと思いますので，また実装がまとまりましたらご確認いただけると幸いです

改めてにはなりますが，Sumireを開発してくださり，さらに継続的にアップデートしていただきありがとうございます
微力ながら，これからもコントリビュートできればと思いますので，その際はぜひよろしくお願いします

[KazumaProject]

@tetta-pdnt

ご丁寧にありがとうございます。

いただく PR やご提案は非常に助かっており、Sumire の改善にも大きく貢献していただいています。

引き続き、無理のない範囲でコントリビュートいただければ嬉しいです。
こちらこそ、今後ともどうぞよろしくお願いいたします。

[scopedptr]

こんにちは。よそでコメントをいただいたことがある者です。
お世話になっております。

まったく急ぎではありません。
PR の要否確認の質問です。

先日偶然、SuccinctBitVector のエッジケースを見つけました。
下記のコードを実行すると、select1(1) が IndexOutOfBoundsException を投げます。

val bitSet = BitSet()
bitSet.set(120)
val sbv = SuccinctBitVector(bitSet)
assertEquals(120, sbv.select1(1))

手元では修正済みで、PR の準備もしてあります。
もし PR が必要でしたら、おっしゃってください。
不要でしたらスルーで大丈夫です。

[KazumaProject]

@scopedptr

ご丁寧なご連絡ありがとうございます。
エッジケースのご報告と修正のご準備いただき感謝いたします。
現時点では急ぎではありませんが、PR 自体は歓迎いたしますので、もしお手隙の際に出していただけましたら確認いたします。
どうぞよろしくお願いいたします。

[scopedptr]

ご回答ありがとうございます。
PR を出しました。ご査収ください。

[scopedptr]

たびたび失礼いたします。
もし差し支えなければですが、下記のソースコードについてお伺いしたいことがあります。

JapaneseKeyboard/app/src/main/java/com/kazumaproject/markdownhelperkeyboard/converter/louds/with_term_id/LOUDSWithTermId.kt

Lines 438 to 441 in ef6e7cc

	if (currentChar == currentLabel) {
	if (wordOffset + 1 == charCount) {
	return if (isLeaf[currentIndex]) currentIndex else currentIndex
	}

440 行目
return if (isLeaf[currentIndex]) currentIndex else currentIndex
の、else の部分が気になっています。

例えば、辞書データに「あいうえお」は存在するが「あいうえ」は存在しないとして、
この辞書データで「あいうえ」を検索すると、上記 else を通ることになると思います。
（「あいうえお」の先頭4文字に部分マッチ）

私の理解が正しければ、部分マッチ時の戻り値は currentIndex ではない方が良いように感じています。

しかしその場合、代わりに

• 即座に -1 を返してしまってよいのか
• 末尾再帰をやめてバックトラックする必要があるのか

の見極めがついていません。

差し支えなければですが、なにかコメントをいただけると大変ありがたいです。

[KazumaProject]

@scopedptr

ありがとうございます。

拝見する限り、ここは分岐が必要ないように見えますね。
kana-kanji-converter 側に初期に書いたコードが残っており、そちらでも分岐しているにもかかわらず同じ値を返していました。
そのため、初期から残っているコードの記述の問題だと考えています。

https://github.com/KazumaProject/kotlin-kana-kanji-converter/blob/c94a89696c85f4bc43d8f52686ebbc5612827c85/src/main/kotlin/louds/with_term_id/LOUDSWithTermId.kt#L148

[scopedptr]

@KazumaProject

ご返答ありがとうございます。

私はここの分岐自体は必要だと考えていたのですが、そうとも限らないということですね。
コードのいきさつも教えていただき、とても参考になりました。ありがとうございます。

お手数をおかけいたしました。