[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 3298] Re: キーバインド.

  こんばんは、川合です。


I.Tak. さんは 2002/02/24 11:48:32 の「[OSASK 3293] Re: キーバイ
ンド.」で書きました：

>>  ええと、まず、[OSASK 1661]（の後半部分）をご覧ください。そこに
>>書いてあることですが、そもそもlib_definesignal1p0()という関数の
>>存在が「えせ」なのです。
>　しかし今はえせを使ってアプリを作っているわけでして、えせでの
>使い勝手なんです。えせでも破綻しにくい方法が欲しい……とは高望み
>でしょうか。

  そんなことはありません。よい方法はなんでも導入したいです。

>　文字入力としては機種の壁を越えています。しかし、スイッチの行列
>としては越えていません、というより、その視点がありません。

  なるほど。

>　スキャン値でもなんでもいいんですが、キー（ボタンと言う方がいい
>かも）とシグナルを一対一にしてもらえるような、そんな要求がしにくい
>んです。ASCIIコードはボタンの倍も文字があって冗長です。ボタン入力
>を要求する手段としてスマートだとは思えません。
>　そしてMOSALIkeyboardのようなことをしようとするとき、文字指定を
>使う今の仕様はエミュができない限り非常に混乱しますが、文字指定で
>なければ、えせ仕様でももう少しなんとかなる気がします。

  なるほど、なるほど。

>　代替というわけではなく、両立です。文字入力としては今のままで十分
>ですから。

  両立というのは、いいアイデアです。それは考えていませんでした。

>　ボードの隣り合うボタンが隣り合う番号を与えられるような体系なら、
>えせでも多少救われると思います。ボタン数が違うなどやはり機種依存を
>免れませんが、それでもえせなりに使えるはずです。これがキーをスイッチ
>として見る視点です。

  これは、対応する番号のキーが無い場合、とりあえずそのシグナルは
発生しないということでいいんでしょうか？

>とりあえずの図:OADG篇
>10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e
>20  21 22 23 24 25 26 27 28 29 2a 2b 2c   2d
>30   31 32 33 34 35 36 37 38 39 3a 3b 3c
>40    41 42 43 44 45 46 47 48 49 4a 4b    4c
>50  51  52  53    54   55  56  57 58  59  5a
>左を基準に振ったが、右を基準にする要求もできると便利だろう。

  なかなか面白い案です。

  アイデアは理解しました。原理的にはサポートの問題もありません。

  あとは需要と設計の美しさです。・・・こういうことができたら便利
だという需要はどのくらいあるのでしょうか。MOSALIkeyboard以外では
たとえばどんなのがあるでしょうか？（需要を知れば、設定方法もより
精練されます）。あとは、この値の決めかたをもっと精練させたいです
。

  キーの中にはシステムが使っているもの（現在の例ではファンクショ
ンキーやShift, Ctrl, Alt, Deleteなど）がありますが、これと競合し
た場合どうするかという問題もあります（この問題は、今の設定方法で
も問題になっています）。

>　私だって、エミュレーションをしても破綻するとは思いません。でも、
>エミュレーションできるようになっても↑の設定ができると便利です。

  ええと、こういうのは「エミュレーション」とはいいません。単なる
仮想化です。設定がオーバーライドできるというだけですから。まあ、
仮想化も広義のエミュレーションだという解釈はできますが。

  それで、仮にオーバーライドするにしても上記の設定方法があると楽
だというのは、同感です。

>　そういえば、これって「ネットワーク透過性」ですね。

  そういうのは多いです。仮想化を究めたら、そういう性質が勝手につ
いてしまいました。今後、他にもそういう例が出てくるでしょう。

>　やっぱりそういうことだったんですか。将来はコマンドを待つまでも
>なくシグナル定義ができてしまうわけですね。
>　でもよく考えると、その場合は定義コマンドが受信レディコマンドに
>変わるのが自然じゃありませんか？　「シェルはこのコマンドでアプリが
>そのシグナルを処理可能であると認識します」みたいな説明だったと
>思います。

  まあ、今のところはそういう説明になっています。しかし、その命令
をコールしたあとで有効だというわけではなく、時間的にさかのぼって
有効になるのです（笑）。enableではなく、defineなのです。

  ・・・というのは、もしenableだという仕様にすると、disableのた
めのコマンドが必要になります。それにdisableにされたら、シグナル
ボックスを調べて該当するシグナルを抹消しなければいけないのでしょ
うか？・・・これはつらいです。したがって、disableにされてもシグ
ナルが来ることはありえます（タイマーなどでは確かにそうなっていま
す）。そうだとすれば、disableにする意味があまり無いような気がし
ます。それで、enable/disableモデルではなく、defineモデルを採用し
ているわけです。

  それに結局は、予期しないシグナルが来たら、読み捨てればいいだけ
です。アプリの負担も高が知れているのではないか、と思っているので
すが・・・。

  何かご意見があれば、教えてください。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/