[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xmgl

鈴木(康)です。
<200011091247.MAA09196@atropos.fsn.7n1umj>の記事において
kensyu@y.email.ne.jpさんは書きました。

  | 実装したとして、xclient が 1,8,15,16,32bpp 以外の
  | コトを考えて書かれてるとは思えない、ということもあって放棄しました。

なるほど、そういうことですか。

8bpp StaticColor でわりとうまく表示できているんで、CFB4 でもそうかと
思ってしまいました。

そういえば、X 版 MGL も 8bpp からしか対応していないですね。

  | まず大枠としての話から:
  | 
  | そろそろ MGL2 そのものの発想として
  | 
  |   「MGL2 on X11 の上に実装容易なものは MGL2 on PDA の上で容易に実現可能」
  | 
  | であるようにしたい、という気分があります。
  | MGL2 on X11 の上では簡単なのに MGL2 on PDA では実現困難(かもしれない)、
  | という状態は MGL2 アプリの開発を X の上でやってる現状では健康に
  | よくないです。

それは理解できます。

が、X を port するのが MGL_SK_EXTRANSLATED を充実させるための 
テストケースであるというのは、疑問があります。

というのは X は、Keysym ではなく Keycode を 使うべきアプリケーションだと
思えるのです。

MGL_SK_EXTRANSLATED は 確かに ショボイ実装な実装しかされていなくて、
ちゃんとしたものにすべきではあると思いますが、本来の目的は、
translated なモードを使いながらも メタキー なんかは取得したいという
いわば、普通の(?)アプリケーション向けの機能です。

とはいえ、ちゃんとした MGL_SK_EXTRANSLATED が作れるということは、
OS Native な translate のエミュレーションが使い物になるということ
ではあります。

ううむ。

	o X での RAW モードの互換性をあげる。
	o MGL_SK_EXTRANSLATED を実装するための keymap は、
	  X で使える程度の機能を持たせるけれども 
	  MGL_SK_EXTRANSLATED の API 自体は 拡張しない

というので手を打てませんか？

  | # ついでに言や、MGL_SK_RAW は on X と on PDA でまだ互換性皆無なので
  | # 出来るだけ使いたくない ...。

X の MGL_SK_RAW は、あまりにアバウトかも知れません。
しかし、Xvnc にも 似た機能は入っているので これを参考に
より良くしていくことは可能だと思います。

  |    >これは？
  | 
  | OS の機能かも〜とは思いつつ。
  | 
  |   scancode -> keycode  -> translated code 
  | 
  | という変換がコードの変換だけに終わるならいいんだけど、
  | keycode  -> translated code の途中でキーの組合せによっては
  | システムはいろんな挙動を起こしますよね。
  | VC を切替えたり、LCD を明るくしたり、suspend したり、etc.
  | mgsrvcons の F9, F10 での window 切替えもその一つ。

KeySym を複数出す組み合わせで 挙動をおこすオペレーションは
ないようなので、RAW モードでも対応できるんじゃないでしょうか？
だとすれば、MGL の中で吸収すべきだと思います。

ちなみに、mgsrvcons は、RAW モードでも F9, F10 に対応できています。
( 厳密にいうとまずい点があるかも知れないんですが、まずい点があるとすれば、
仕様というよりバグです。)

  | X の 1 つの窓の中で *使えてしまう* 機能であってかつ原理的に PDA 上でも
  | それほどコード量的＆速度的なオーバーヘッドなく実現できる部分は PDA でも
  | 使えるようにしておきたい、もちろん階
  | 層メニューのサポートまでいったらそれは
  | X そのものなわけで、限度はあります。その限度を Xserver on MGL2 が
  |  OS independent
  | に書けるようになるところに定めてはどうだろう ... ということであって
  | 「X と共用できる translate の仕組み」が出来てくるであろうというのは
  | その結果として。
  | 目的にしてる訳ではないつもり。

これについての私の考えですが、

translate の仕組み 自体は 最大公倍数的なものを持っていて、望むような
コード変換ができないといけないと思います。

だからといって、一般 MGLアプリケーションに 統一した KeySym の定義を
見せるべきでもないと思います。

# mgterm では、BS キーを押したら出るコードを厳密には知らないわけです。
# そして、Linux と NetBSD では コードが違う。
# 知らないほうがいいということもあるんじゃないかと思います。
# F15 なんて termcap は定義できないけれども、それが出来て幸せという
# こともないだろうし、termcap で縛るよりは、自由に使ってもらえるように
# 空けておくのも良いんじゃないでしょうか？

というわけで、「X と共用できる translate の仕組み」は、必要だが、
全ての KeySym や モデファイヤ を 全部定義してみせるのは、
行きすぎではないかと思うのです。

どうでしょうか？

--
					鈴木　康司 ＠ＮＥＣソリューションズ
					suz@hpc.bs1.fc.nec.co.jp
					TEL 042-333-6465