もしかしたら開発室附属雑記帳

計算機の明後日を考える「もしかしたら開発室」の雑文(又は下書き)コーナー

雑多

[ リスト | 詳細 ]

記事検索
検索

全2ページ

[1] [2]

[ 次のページ ]

以前から予告していました通り、Yahoo!ジオシティーズのサービス終了に伴い、メインサイトを移転しました。


本日、旧アドレスから新アドレスへの転送設定を入れましたので以前のアドレスでは直接ページ参照できなくなりました。今後は上記アドレスから閲覧して頂くようお願いいたします。


で、今度はこのブログなんですが…こっちも2019/12/15いっぱいでサービス終了らしいんですよね。

今のところ今後の方針は未定です。メインサイトの更新作業が少しやりやすくなったので、ブログサービスを使わずそっちに記事ページを追加していくスタイルでも良いような気がしてきましたし。一方、また1社に色々集約しておくとサービス終了時に面倒なことになるので、その対策として別のブログサービスに移行することも検討しています。

Scrapstick関連が書きかけで情けない状態になっているのが少々心残りですが…場所がとっちらかっててもしょうがないので、こっちはブツ公開後にリポジトリの方へ文章を集約して書いてく方針にしようと思います。

開く コメント(0)

開く トラックバック(0)

本体サイトの方ですが、ホスティングに使用しているYahoo!ジオシティーズが2019/03/31でサービスを終了するとの報がありましたので、これを機にGitHub Pagesへ移転することにしました。新しいアドレスは下記の通りです。


恐れ入りますが、お暇な時にでもブックマーク・リンクの更新をして頂けると有り難いです。フォルダ構成もそのまま維持していますので、直リンクの場合は頭だけ差し替える形でご対応下さい。サービス終了までの間は両サイトの内容を同期しておきますので、ぼちぼちで結構です。また、このブログや掲示板については移転せず現行のままです。

--

しかし、他のホスティングサービスが終了していくのを横目に見続けてきましたが、とうとう自分にもお鉢が回ってきました…。元々ジオシティーズ自体じわじわ提供機能を減らしていて(直接喰らったものだけでも、独自メールサービス、初期に掲示板として使っていたジオボード、果てはカウンタ、ゲストブック、ジオログ等々)長期に渡る撤退戦のような状況でしたので、一ユーザとしてはやっぱり…というか、寧ろよくここまで持ちこたえたなという印象です。

そういや上記消えた機能を列挙しながら思い出しましたが、ジオのアカウントは当初自分専用のメアドが欲しくて作って、せっかくだから作ったソフト公開するようにしようかみたいな感じでサイトを開設した記憶があります(尤も、メールの方は数年持たずサービス終了してしまいましたが…)。サイト開設は2001年だったと記憶しているので、約17年ですねぇ。当時中学生だった私ももう三十路ですよ…時の流れは恐ろしい…。しかしまぁ、それだけの期間同一アドレスで細々と成果物を公開し続けることができたのを幸運と見るべきなのかもしれません(実は、一度古い番地表記アドレスの旧システムからID表記アドレスの新システムへ移行させられたのですが、現時点でも古いアドレスからの転送が残り続けています)。おかげさまで、あんなニッチな代物しか置いてないサイトなのに、今に至るまでコンスタントに誰かしら見て下さっているようですので。

ただ一方で、今の形式のままやるのもどうなのかなぁという気がしています。というのも、やり方を変えずに版数管理やら整合性やらを含めてちゃんとやろうとすると、間違いなく続けられないと思うので、そこはテクノロジに頼って解決したいという思いはずっとあって、例えば文章をブログに上げたりはその一環だったりした訳です。一方、ソフトの方はこれまでの蓄積(lzh/zip配布で公開した代物)が多い分、前との整合性の兼ね合いもあって、1個だけ試しにGitHubで公開して以降は元のアーカイブ配布に戻していました。いちいちアーカイブ作って周辺ページを手打ちで書き換える現行スタイルよりは、Readmeを説明ページ代わりにした上でgitの日常操作のままアップできるGitHubの方がラクではあるので、折角だからこれを機にスタイルを改めたい感情の方が勝ってきました。

そこで今後、新規で公開するソフト・ハード等はGitHubGitLabにリポジトリを作るようにして、サイトの成果物公開機能については概ねアーカイブにしてしまおうかと考えています(つまり、移行先に持っていきディレクトリ構造も維持するが、これ以上の更新はしない)。まだ更新・修正を続ける意志があるものについても公開リポジトリ作ってそちらへ移管しようかと考えていますが、既存のReadmeはShift-JISのせいでGitHub上から上手く表示できない問題があったり、ローカルリポジトリのファイル配置がリリースと異なるものがあったり、残念なコミットログを晒すのに抵抗があったりと、そのまま公開できる状況ではないものが多いので、暇をみつけてぼちぼちやることになりそうです。これはまだ公開してない代物にも言えることです。まぁReadmeの文字コードはともかく、他は気取って使おうと思わなきゃいいだけの話なんでしょうけど…でも抵抗あるなぁ。

また、文章については当面このブログをメインに考えていますが、Yahoo!ブログはWiki文法使用時のクセが強く、特に(よく使う)箇条書きが隠し機能になってたり、それを無理やり使う場合は工夫しないと書式が崩れたりするので、ちゃんとした文章を書く場合は、何らかの静的サイトジェネレータを使ったシステムに移行するかもしれません。本体サイトの既存の記事については、修正がなければこのままにする予定です(つまり、移行先に持っていきディレクトリ構造も維持するが、更新はしない)。電脳文庫関連はアクティブなので(そうは見えないのが心苦しいですが)、前述の通りに更新を継続する予定です。こちらについては近々近況を追記しようと思います。

さらに、前回の反省もあって、試運転さんのアドバイスも参考に、質問や記載ミス・バグのレポートのための雛型の準備と、連絡手段を追加(各リポジトリのIssuesを使用する運用に)してみました。後者の手段を使うと私宛にメールが飛ぶので、ジャンクメール判定さえされなければ見落とす可能性は低いはずです。雛型はについてはひとまずこのサイトのリポジトリに作成しておきましたが、このままではGitHubアカウントを持っている方しかやりとりできない・雛型を使えない為、掲示板からでも雛型を参照できるように別途リンクを貼っていこうと考えています(リポジトリを新設するものについては、Readmeを仕立て直す際にリンクを張るなど)。お気軽にお使い下さい。

今後のやり方は少々変わりますが、趣味の成果物置き場としての立ち位置は変わらず、ましてや現在あるファイルの配置はそのままで、これからも細く続けていく所存です。移転後も引き続き宜しくお願いいたします。

--

オマケで、ジオからの移転先としてGitHub Pages / GitLab Pagesを検討している方向けのメモなど。

  • GitHub Pagesについて、masterブランチを使わない方法は古い説明なので、無視して良いと思います。
  • GitLab PagesはCI機能の一環として実装されているようです。このため、ただリポジトリ上のファイルを公開するだけでもこれのように、実質何もしないスクリプトをリポジトリに突っ込んでおく必要があるようです。
  • また、GitLab Pagesは./publicフォルダ以下のファイルを公開するので、これのようにリポジトリ内の全ファイルを./publicフォルダへコピーするスクリプトにしておくと、GitHub Pagesと同じファイル配置のリポジトリ(rootにindex.htmlを置く)にすることができるようです。
  • Shift-JIS / EUC-JP等のファイルは文字化けするようです(HTTPヘッダか何かで強制的にUTF-8だと通知している??)。各ファイルをUTF-8に変換してしまえば問題ありません。
  • 通信がHTTPS化される為、カウンタ等、外部サイトのコンテンツがブラウザにブロックされる場合があります。相手がHTTPS対応サービスであれば、リンクのアドレスを変更するなりして表示できるように対応すべきです。
  • どちらも、Pushしてから反映されるまでに少々時間がかかります(特にGitLab)。
  • privateリポジトリにしなければコミットログが公開される為、いちいち更新履歴をページ内に書かず、そちらを直接参照させる運用もできるかもしれません(個人的にやりたい)。
  • 見慣れた自サイトに広告が出ないのはチョット嬉しい。
  • 開く コメント(0)

    開く トラックバック(0)

    表題の件です。

    具体的に言うと、Win10 1709以降で、前回セッションを再起動・シャットダウンで終わらせる際、起動したままになっていたアプリの内一部が、次回ログインする際勝手に立ち上がる…というものです。全てのアプリが自動起動の対象となるわけではないようなのですが、少なくともVisualStudioとタスクマネージャは該当しました。

    これに関する日本語の情報としては、この辺を辿った先などで色々な手を使った回避策が紹介されていますが、どうもその後、この機能を正規に無効化する手段が用意されたようです(下記最初のページのコメントによると、1709では2018/02/01のKB4058258以降。1803では最初から)。
    参考までに、日本語環境でのスクショを上げておきます。以下の設定をOFFにすることで、スタートメニュー経由などから普通にシャットダウン操作を行っても、前述のアプリが自動起動することはなくなりました。

    イメージ 1


    尚、Explorerで開いていたフォルダウィンドウをログイン時に復元する機能については、Win95の頃から元々ある別の機能なので、上記オプションの埒外です。こちらは今までどおり、独立してフォルダオプションから設定できますので、必要に応じて設定すると良いと思います(すべてのコントロール パネル項目 > エクスプローラーのオプション > 表示 > 詳細設定: > ログオン時に以前のフォルダー ウィンドウを表示する)。

    本当はこんなところに書かないで上記スレッドに追記してあげれば良いのでしょうけど、該当するスレッドが軒並み2018/02にロックされていた為、できませんでした。スレッドによっては、対策がリリースされて暫く経過してからロックされていたものもありましたので、せめて最新の情報に更新してからロックしてほしかったなぁという気がします。

    開く コメント(0)

    開く トラックバック(0)

    まさかまさか、あのJapanistがUWPアプリ対応になって帰って来ました。

    なぜかJapanist 2003が同封されている…という点が諸々不安を感じさせるところですが、早速入手し(V10.0 L10 rel.001)人柱になってみましたのでWindows 10(1703 x86版)上で使って気づいた点などをまとめてみようと思います。尚、キーボードドライバは親指の友 Mk-2ドライバ V2.0L23、Japanist上のキーボード指定は「OASYSキーボード(実行付き)」にしてあります。

    OAK使いのための初期設定

    Japanist 10では、2003にあった「環境スタイル」機能が無く、また、各種設定の初期値が「MS-IME風」っぽい動作になっているようです。
    このため、OAK風の挙動を再現する為には逐一手動で設定してやる必要があります。

    これはMS-IME + 親指シフトエミュレータ使いな人の移行を狙ってるのだろうか?
    私はOAK風の操作がそのまま使えることに期待してJapanist買ってる人なので、MS-IME風を初期値にする感覚はよくわからないです。

    Japanist 2003を使っているのであれば、そっちの動作環境と見比べながら設定していけば良いのですが、将来Japanist 10へ完全移行することになった場合など、手元に参考資料がない場面も想定できるので、設定値のメモを載せておきます。宜しければお使いください。

    尚、ここで言うOAKはFM TOWNS版(またはFMRのMS-DOS版)を指します。Japanist 2003の標準スタイルでいうOAKはWindows 3.1版っぽいので、ここでは「OASYS V」スタイルの設定値を表示します。

    イメージ 1

    イメージ 2

    イメージ 3

    イメージ 4

    イメージ 5

    イメージ 6


    そういや、設定値の初期化・エクスポート・インポートもできなくなったのな…。

    よくなったところ

    気を取り直して、個人的に感じた改善点を列挙してみたいと思います。

    UWPアプリ対応

    OS標準アプリのUWPアプリ化もじわじわ進んでいるご時世ですので、この対応は有り難いです。EdgeだろうがSticky NotesだろうがOneNoteだろうが、問題なく入力することが可能です。

    しかしながら、Windows Store経由で入手するアプリすべてがUWPアプリ対応のIMEを要求するのかというと、どうもそうではないようでして、例えば秀丸のストアアプリ版のように、Desktop Bridgeで移植されたものについては旧仕様のIMEでも使えるようです(秀丸にてJapanist 2003が使えるっぽいことを確認しました)。なので、もし2003をお持ちの方が導入を検討しているのであれば、使用したいソフトが本当に新仕様のIMEを使う必要があるのかどうか、手元で確認してみると良いと思います。

    タスクバー形式の入力モード通知が見やすくなった

    ようやく白文字デザインになったので、通知が使い物になるようになりました。

    そもそも、タスクバーの色が淡色→透過処理→濃色と変化してアイコンデザインと合わなくなったのが問題なので、2003でもアイコンを白縁取り化するアップデートとかしてくれりゃ良かったのでは? という気がしなくもないですが…。

    コマンドプロンプト上でもとりあえず動く

    Readmeには「対応していない。使うな」とありますが、一応動きはするようです。
    尚、2003だとコンソール上では一切入力を受け付けませんでした(あれ、そうだっけ? いつのまにかこっちも旧式IMEはダメになったのか??)。

    2003のReadmeにも、Vista以降については同様の記述があるので、もしかするとコンソールがTSFを要求していたのかも?
    ただ、使うなとある以上、常用しようと企む方は自己責任で。

    Unicodeの基本多言語面以外に対応

    個人的にはJIS2004対応よりもこっちのほうが嬉しいかもしれません(開発環境等のUTF-8化が進んでいるので)。つまり、絵文字とかヒエログリフとか楔形文字とかを、マルチボードで入力したり単語登録したりできるようになります。
    これを組み合わせて何ができるかというと、例えばこんな使い方ですね。

    イメージ 7


    コメント・コミットログ、はたまたブランチ名など、これでいくらでも気軽に汚染させることができます ;-)
    (失礼しました…。)

    一部のテキストボックスでの動作改善

    具体的には、VisualStudio2017のXAMLデザイナのプロパティページのテキストボックスで文字入力ができるようになりました。2003では直接入力すら反応しませんでしたので、もしかするとここだけTSF使ったIMEを要求する代物だったのかもしれません。

    尚、、親指の友 Mk-2ドライバを使った場合は、カナのバンク切り換えが正しく行えず、まともに使えません(つまり、IEで正しく入力できない症状と同じ)。これはIME側の問題ではないので、快速親指シフトを使う場合は正しく動く可能性が高いです(確認してません)。純正ドライバだとどうなんでしょうねぇ…。

    引き続き使えるマイナー機能

    「単語登録」「漢字辞書」などの富士通拡張な仮想キーコード

    正直、FMR版 Windows NTのキーボードレイアウトの残骸位でしか見かけないOEMコードなのですが、なぜか対応しています(そして、その残骸は、なぜか今でも最新のWindows SDKに残っているという…)。
    親指の友Mk-2ドライバでは配列置換などを使ってこの仮想キーコードを投げることができるので、興味がある人は試してみて下さい。

    消えた?機能

    公式に触れられている削除機能(OASYS固有の特殊入力…半角ひらがな・4倍角など…、JEF入力など)以外に、ざっと動作環境画面を見た限りでも、

  • 変換状態の色設定がない(TSFでは描画をIME側ではなくアプリケーション側で行うからだと思います)
  • 変換方式の設定がない(単文節変換固定にできない)

  • 等々、随分削ぎ落とされた印象です。その他細かいものの重要な機能について以下にまとめておきます。

    「自動的に起動する」

    Japanist 2003まではこの機能を入れることで、IMEを自動的に立ち上げることができていました。例えば、テキストボックスにフォーカスを移して無変換を押すだけでかな入力を始めることができていたのですが、この機能が無いせいで、各々初回のみいちいちAlt + 半角/全角を押す必要があります。はっきり言ってめんどい。

    この辺については、MS-IMEでもWin10搭載版から初期入力モード設定が無くなっているようなので、もしかすると、MSのガイドラインか何かのせいで組み込めなかったのではないかという気がしなくもないです。

    もしそうならこの機能が復活する可能性は期待薄ですけど、であれば、IME OFF状態をal/ALモード相当と考えて、無変換/変換キーでIME ON + かなモードへ(対称性が問題になるなら、オプションとして英字キーでIME OFFへ)遷移できるようにアップデートとかで変更対応して頂けると大変有り難いですねぇ…。

    「確定時の機能キーを有効とする」

    この機能を使うと、例えば変換候補を出した状態でEnterキーを押すことで、結果の確定と改行入力を同時に行うことができていました。これが無いとワンテンポ操作が増えてめんどいです。
    こっちはなんだろう…実装上なんか問題があるのかなぁ。それとも単に「正直誰も使ってなくね?」みたいなノリで消されたのか?? 俺愛用してるよ!! 復活してほしいなぁ…。

    バグ?

    Win16アプリで使用できない

    半分冗談で試してみましたが、IME ONにもできなければ(利かない)、他IMEから切り換えて無理やり立ち上げることもできません(NTVDMの応答がなくなる)。

    さすがに、こんなん現役で使っている人はごくわずかだと思いますが、もし本当に必要としている人がいるなら、おとなしく同封の2003を使うのが良いと思います。こっちならちゃんと動作します。

    そもそも25年近く前のアプリがフツーに動くWindowsの互換性よ…。
    尚、MS-IMEの方は入力・変換こそできるものの、変換候補リストの文字が消えたり、アプリ終了時にNTVDMが固まったりと、色々挙動不審です。多分MSもテストしてないんでしょうねぇ。
    なので、JapanistにWin16対応を求めるのは酷。

    Windows 10側の謎挙動

    直接Japanist 10に関係する話ではないのですが、恐らくこれを検討している方の多くはJapanist 2003をお持ちで、購入後も当面は共存して使うのではないかと思います。ただその際、そういった環境に起因すると思われるWin10側の不具合っぽい挙動がありますので、その解決策を書いておきます。

    IMEの既定値が変わらない

    具体的には、「既定の入力方式の上書き」で指定したものにならない場合があります。

    2018/05/21追記

    April 2018 Update(1804)では、いずれのIMEであっても「既定の入力方式の上書き」が利くよう修正されている模様です(既にJapanist10/2003が入っている環境をアップデートしたもので確認)。
    このバージョンからはコントロールパネルの「言語」が消えた為、ここに記載の回避方法は実施できなくなっていたのですが、そもそも根本の問題から治療されていましたので大変良かったと思います。

    これどうも、旧方式のIME(IMM32を使うもの)とUWPアプリ対応のIME(というより、恐らくTSFを使うもの)とが共存しているときにのみ起こる問題のようで、「言語リスト」の一番上にあるものがUWPアプリ対応のIMEであれば、UWPアプリ対応IME同士による上書きのみが可能で、旧方式のIMEを指定しても無視されます。例えば、言語リストの一番上がJapanist 2003であれば、MS-IMEやJapanist 10を指定しても設定が効かず、強制的にJapanist 2003が既定値として使われてしまいます。一方、MS-IMEになっていればJapnist 10で上書きすることが可能です。

    では、どうすれば設定不可能なIMEを既定値にできるかというと…、そもそもこの言語リストの並びを変えてしまえばいい訳ですね。

    言語リストの実体は「コントロール パネル\すべてのコントロール パネル項目\言語\言語のオプション」にある「日本語」→「オプション」内の「入力方式」です。このリストの一番上にあるものが、「既定の入力方式の上書き」を指定しない場合に使われるIMEの既定値です(言語設定で日本語しか入っていない場合)。

    イメージ 8


    残念ながらリストの順序を変えるためのコマンドがありません。しかし、ここでの「削除」はアンインストールではなく、切り替え対象から一時的に外すことを意味しているので、気軽に削除・再追加が可能です。よって、これを利用してリストの順序を変えてしまえば、「既定の入力方式の上書き」に頼らずともデフォルトのIMEを変更することができます。
    具体的には、
    1. リストの先頭に持ってきたいIMEをアクティブにする(そのIMEへ切り換える)
    2. それ以外のIMEを全て削除し、「保存」
    3. 「入力方式の追加」で、必要なIMEを好きな順番で追加し、「保存」
    こうすることで、Japanist 2003だろうが10だろうが、お好きなIMEを既定値として使うことが可能です。他のIMEについても同様と思いますので、お困りの方は参考にどうぞ。

    終わりに

    Windows側のI/F変化にJapanistがちゃんとついてきてくれたのは大変良かったと思います。モダンなアプリケーションでも引き続き手慣れた操作を使い続けられるというのは大きな安心であるとともに、既に出来上がった手癖を直さなくて良いことがわかった分、より一層他のことに注力できるというものです。さらにいえば、公式の完全な親指シフト環境が整ったことで、機械周りに疎い親指シフターにとっても参入敷居が大きく下がったのではないでしょうか。これで親指の友 Mk-2ドライバについても、安心して元のキワモノポジションに戻ることができます(笑)。

    また、思いの外ちゃんと動いたので安心しました。Readmeで特記がある内容以外の不審な動きは、今のところ特に見当たりません(さすがにWin16の件はノーカンです)。Japanist 2003を付けてきたのは完成度が酷いからではなく、「10で削った機能を当面補うため」という位置づけなのかもしれません。

    一方で、OASYS→OAK→Japanistと受け継がれている操作体系の一部が再現できなくなった点・再現させるまでの設定が面倒になった点については残念に思います。実はこういう操作感とか、感覚的に訴えてくる部分みたいなところが一番替えが利かない点(つまり、人を製品に繋ぎ止めるための最強の力)だと思うので、技術的な制約はあるでしょうが上手く回避しつつ復活させて欲しいなと思います。

    幸いリリース前より「再変換機能はアップデートで対応」との記載があるので、これで完成!…という訳ではなく当分機能追加が続くのでしょう。あわよくば、前述の消えた機能の復活を願いつつ、気長に次のアップデートを待ちたいと思います。

    開く コメント(6)

    また、ブログの方は暫く間が空いてしまいました(メインサイトの方は若干更新しましたが)。

    ここのところ、掲示板の方によく「親指の友 Mk-2」ドライバ絡みの質問などを頂くことが増えてきました。増えてきた…ということは、何らかの理由で以前よりも人目に触れる機会が増えたのではないかと思ったのですが、調べてみると、どうやらいつのまにか、親指シフトの総本山たるNICOLAのサイトからリンクが張られていたようです。

    勿論、自分が作ったものを多くの方に使っていただけるようになったというのは作り手冥利に尽きる事ではあるのですが、このドライバに限っては、以前よりも遥かに見つかりやすくなってしまったことで少々困惑している節があります。

    というのも、親指シフターというのは、どちらかというとあまりPCに詳しくない方が一定数含まれるらしい集団である…というのが昔からの印象でして、この中にはメーカのサポートセンターだったりの常連さんも居るのでは? という偏見があるからです。つまり、「フリーソフト作者に対しても同じ感覚で来る方が現れたらどうしよう…」ということです。

    ---(2017/6/21追記)---

    特に本ドライバのx64版は、導入時にオレオレ証明書を作ったりcatファイルに署名したりと、大凡ドライバ開発者が仕事でやるような作業を各自行わなければいけません(DSEO等で代用する場合を除く)。ここまで厄介な導入手順を踏む代物でなければわざわざ前述のような懸念をする必要などなかったのですが、M$の署名ポリシーを安全側に汲むと、これ以上簡単にすることは断念せざるを得ませんでした(現状でさえ、それなりにリスクを伴う方法ですが…)。

    幸い、私以外にも導入方法について解説する記事を書いて下さった方がいらっしゃるので、(私が書いたReadmeしか資料がない状態よりは)遥かに敷居が下がっているとは思いますが、それでも、インストーラー付きアプリの導入なんかに比べればとても複雑な作業です。

    元々このドライバは、「親指シフトをコードの読み書きをする人にも使ってほしい」という意図がありまして、そういう人達が使ったり、或いは気に入らないところを改造したりすることで、ドライバや実装方式、親指シフトの仕組みそのものの改良・発展が進んでいけば良いのではないかと考えていました(そうなってくれば、親指シフト界隈も多少盛り上がるのではないかという期待を含めて)。そういったこともあって、(どうせ利用者がソース弄るんだろうから)x64版の署名はWDKのツールを使うなりして各自でなんとかすれば良いんじゃないかと考えていた節もあります。

    なので、本来利用者として想定していない方々(例えば、先の導入方法の記事を読んでも、いまいちピンとこないような方)が流入してしまったとしたら、もしかするとお互いにとって不幸なことなのかもしれません…。

    ---

    ということで、自己防衛の為にも、改めて一言書いておこうと思います(DLページのところにも少し追記しておきました)。このサイトで公開しているソフトウェアはいずれもフリーソフトであって、使用許諾の条件として、使用者の方には「自己責任の下に使用すること」を要求しています(readme.txtを参照下さい)。つまり、市販されているような製品(Japanist等)と異なり、私が使用者の方をサポートする義務はありません(法的にも倫理的にも)。

    このサイトで公開しているソフトは全て趣味の成果物です。とりあえず作ってみたけど、もしかしたら他にも使ってくれる人がいるかもしれない…と思って公開している代物です。私は「アイディアを思いついて形にしてみる」ところまでが好きなのであって、事細かに説明書を書いたり、サポートセンターみたいなことをしたりするのは趣味ではありません(勿論、仕事として受けている範疇であればやりますけど、でもこのドライバは仕事で作ったものではないので)。

    このため、本ドライバをお使いになる場合は、基本的に「何があっても(例え上手く動かなくても)ご自分で対処する(場合によってはあきらめる)」前提でご利用下さい。勿論、バグレポートや技術的な質問等についてはこれまで通り歓迎しますので、こういった話があれば掲示板にご連絡頂けると助かります。


    ちなみに、以前の記事にも書きましたが、私としては今後、キーボード関係(親指シフト関係を含む)で新しく何かを作る予定はありません。
    また、私は親指シフトを使いたい以前に、Windows環境下で「富士通製の板バネメカニカルキーボード」を使いたい人なのであって、これらを満たすことがないような話に対して自発的に動くことはありません(仕事であれば別ですが)。

    勿論、またWindowsのバージョンアップに伴ってドライバが使い物にならなくなった…といった事態になったら何か対策することを考えますけど、年々野良ドライバに対するハードルが上がっているので、恐らく次に手を入れる時は「ドライバ」という形態を捨てることになるのでは…という気がしています。

    現時点でわかっていることとして、

  • キーボードレイアウトファイルについては、x64 + 非テストモード環境に於いても未署名バイナリのままロード出来ることを確認済(初期のWin10にて)
    ・ そもそもユーザモードDLLなので、セキュアブートとかの対象にもならないはずですし
    ・ 基本的に定数テーブルを参照させる為だけの存在なので、ドライバ本体と違って悪さできる可能性がない点も重要です
    ・ よって、このファイルは、今後も個人製作のものが使える可能性が高い
  • 親指の友 Mk-2ドライバの本体側で行っている親指シフトの制御ロジックは、キーボード側で行ってもシステムとして成立する仕組みになっている
    ・ 同時打鍵操作を逐次シフトのパターンに変換しているだけなので
    ・ 常に同時打鍵監視のロジックを動かすことができるので、モードずれの心配も無ければ、モード同期の為の制御をPC本体側から行う必要もない
    ・ さらに、零遅延モードがあるので、英字入力時にもたつく心配もない

  • ということで、最終的には

  • OyayusbyにMk-2ドライバ相当の同時打鍵監視ロジックを入れる
  • Mk-2ドライバのレイアウトファイルのみを、上記Oyayusby向けに改造

  • といった2本立てみたいな形で落ち着くんじゃないかと考えています。

    勿論、上記のどちらもソースを公開していますので、喫緊に必要としている方がいらっしゃれば、私に代わって実装して頂いても良いですし、むしろその方が有り難いです。寧ろそうなることを期待しています。

    開く コメント(0)

    全2ページ

    [1] [2]

    [ 次のページ ]


    .


    プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

    Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

    みんなの更新記事