タグ
未設定

よく使われているワード(クリックで追加)

javaandroidc++objective-ccocoa誰得c#linuxgamebathyscaphephp翻訳qtpythonrubycwindowsomegattwitterguiframeworkbtronarduinovb.netdirectxtestゲームエンジンdom計画中(planning stage)previewer

最近の作業部屋活動履歴

2018-12-09
2018-12-08

最近のWikiの更新 (Recent Changes)

2018-12-09
2018-12-08
2018-12-06

Wikiガイド(Guide)

サイドバー (Side Bar)

2018年12月07日(金)

AD-401 補助メニュー試作01

ad401_aux_top_p01.PNG ad401_aux_top_p02.PNG

補助メニューのルート画面ホットモックのみ。 機材が生きているうちにマウス操作拡張、グラフィック版に作り直す。 APの補助メニューなら試作があるけど、機種が違うし ADの説明書もかなりいい加減なところがあるので、実機は必携。

その各種の機能および LX風の補助メニューは、今後ワープロ機能の開発が進んだら作ることにします。サブメニューへの遷移はステート変数かインスタンス変数と eval 関数で動作を切り替えれば良い。

設計背景を理解する

30 系の補助メニューはメニューアイテムが複数のベージに分解されている。アイテムの項目移動は上下矢印、決定は実行、ページ切り替えには前項、次項を使う必要がある。ただ、これって分かりやすく、当時のハードウェアでも実用速度で動き、実装しやすいが、アイテムが増えてしまうとベージが増えてしまい、いちいちカーソルから手を離す煩わしさから、かえって使いづらくなる。

OASYS Pocket 3 あたり(FROMシリーズからでは?)の先頭と最後の項目で次ページのアイテムへスクロールするようになったが、今度は実装やデバッグがしづらくなったような印象を受ける(さらに下矢印キーで最後のページへ移動するのに18回打鍵する必要がある問題が出てくる上に、ページ移動は現在のアイテム選択位置から計算となるため、ページ始点、終点位置が可変となってしまい、以前と同じ位置にアイテムがない問題が発生する。これに空行がからむとなると面倒くさい)。

力技や技工的手法で問題を解決したはずが、別の問題を生んでしまったり、単純にすると操作コストがかかってしまうわけか。んー。

その後、 LX-1000あたりでゆびタッチ(ひろし...)、単一画面の階層型メニューが導入されたことで、問題は解決したものと思われる。

そういう経緯や設計思想を想像すれば、うちんところで今やっていることはサッサと諦めて LX-S5000 あたりの補助メニュー、Androidの設計メニューの発展版を導入したほうがいいとの感じになるかな。

ただ、それでも実機使っている人からすれば絶対拒絶反応はあるし、そういうつまらないことでネットトロール化して寿命を浪費してしまうヤツもいる。全部同じにすることはコストがかかるし、質の悪い人を呼び寄せてしまう危険な行為のかも知れないな。

簡単そうに見えるものほど難しい

基本部分は試作できているのに、Pocket3 の細部動作である空行読み飛ばしスクロールは未だという。んー。普通に組んでいるはずなんだが、データの採り直しか、パラメータなど前提が間違っているな。

ワープロ専用機の復刻が難しいのは、権利問題や採算性だけでなく、今ではあまり使用されていない実装手法が使われていることがあるのも考えられるなあ。それを組んだかたは、存命かどうかわからないし。

クローン開発に限らず、物事を勧めていくと、できる・できない。そういうのが出てきます。

いまは一人でしていること。実力と開発資源不足なので仕方ないか。


筆者は富士通とは一切関係ない個人です。お年を召した方は、思い込み、早合点、勝手な判断をされるたが多いので、勘違い無きようお願いします。