> The shells would also want to be able to change
> screen colors, move the cursor about (and how is that done, BTW? Currently
> the cursor just sits 3/4 down the screen on the native console and doesn't
> show up at all in the Java consoles.),
You got me there -- I completely forgot about character
attributes. (get/setAttr shouldn't be too hard to manage
though.) w.r.t. to the cursor, I'd add get/setCursor() right away, if I
knew how...
> I'm not so hot on this approach. I'd prefer somehow that the shells are
> told what console they get and when the keyboard is theirs. In the same
> vein, I think there needs to be a Screen object which keeps control of the
> mapped byte array. In short, anytime there is a scarce native resource,
> there needs to be an object keeping track of it to make sure that we don't,
> for instance, have multiple consoles ever trying to write to the screen at
> the same time.
The mapped byte array per console approach is Grand Hack, and yes,
hardware resources need to be better tracked. Unfortunately, I don't
really have any ideas as to what the Right Way to do that is.
> A lot of this I foresee being configurable off of the registry. It is
> almost like there needs to be a single meta shell to intercept the Fx keys
> and control the switching between shells. Hmmm.....
Well, that's what consoled does. (Rather, the consoled running in
the `root' process, the one started by init. Other consoled's could be
running in other processes, but they only get the keystrokes that the
'root' consoled doesn't eat. And yes, the registry would be a good place
to keep system(user?)-wide keyboard shortcuts like this. (E.g. for that
multiple-console xterm, its consoled would have to look at ctrl-Fx,
instead of alt-Fx, for when to switch, because alt-Fx is handled by the
'root' consoled.)
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
