nanogui: X11 compatibility and pseudo-keyboards.
Subject:
RE: X11 compatibility and pseudo-keyboards.
From:
Greg Haerr ####@####.####
Date:
6 Dec 1999 21:53:50 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB0770C9@NBA-SLAM.CenSoft.COM>
: My two main concerns regarding nano-X at the moment are :
: 1) differences from X11, I would like Xcopilot to run on it.
Cool. Now you know there's also a Win32 api version of
Copilot, you might want to look at that also, since we support
the Win32 graphics api.
: 2) having keyboard replacements (if possible in a modular way).
I assume from your comments below that you're talking
about graphical keyboard replacements for systems without
a keyboard. Even the physical keyboard support is rudimentary
at the moment for Microwindows, in that only copied
sequences from /dev/tty are copied thru. I plan on adding
internal values for function keys, etc soon, but we've been
concentrating on the graphical aspects so far.
: 1) About X11. I have started with writing a small C program that
: converts basic Xlib calls to nano-X calls. The calls I have chosen are
: those used in Xcopilot 0.6.2 (0.6.7-tr uses X toolkit which makes
: implementation even tougher...).
: I was disappointed to see that event codes and event masks were
: incompatible with their X counterparts (e.g.FOCUS_IN and FOCUS_OUT
: instead of Focus Change).
: But nano-X is cleaner since events and event masks can be deduced from
: each other simply whereas this is more difficult in X (the order changes
: !).
Yes, it would be nice to have a macro library that used #define to do the
work, rather than a preprocessing translator. With the FOCUS_IN/OUT
issue, it'd be an easy change to add a FOCUS_CHANGE that works
the way that Xlib does. Because of namespace issue with Microwindows
now running on top of X, I like the #define method of running Xlib programs.
: Also, I am a bit worried about image functions implementation, I hope
: nano-X will soon have XCreateImage and XPutImage like functions.
XCreateImage and XPutImage were created for client side speed
issues. I have created a similar function in the graphics engine,
implemented under win32 only as of yet, GdDrawImage that will
take a 256 color (or truecolor) image and draw it on the screen,
handling changing colors in the system palette during the process.
Are you looking to just draw full images quickly, or do you want
instead to draw on client-side bitmaps, and then fast copy it over?
(The real question here is do you need client side bitmaps,
do you want offscreen drawing, and/or do you need fast blitting?)
I'm trying to keep the Nano-X stuff more X-like, rather than adding
in win32 style enhancements, and the same thing for the Microwindows
win32 api.
:
: 2) I have looked up for keyboard replacements :
: - jstroke, kanjipad are 'C' programs recognizing japanese characters
: that you draw. The second is a gnome version of the first where the
: recognition engine is encapsulated. Both have their roots in the
: Goldberg unistroke paper. But I have trouble figuring how to set the
: character-set back to roman characters.
: - ustroke.tgz and tcube.tgz that I found on some freebsd japanese
: site but I cannot find the URL again. There are readme files that I
: cannot read (my japanese is poor). They are integrated with X and use
: XInput. But to give scancodes to the Xserver they write it to the
: console directly (using an ioctl code not available in Linux).
:
It would be great to get some handwriting recognition going, but
we'd definitely want to start with something already working well.
: My opinion about this input situation is that :
: - these programs can be used to replace grafitti. But we need to be
: careful to select one that we can extend.
: - we could do with something more abstract that writing directly to the
: console.
What do you mean, writing to the console. You mean writing to the
console keyboard? Or reading from it? Or are you talking about
writing character codes to the console display?
I would like it if a dedicated keyboard daemon wrote to the
: console and accepted keystrokes from a socket. It would make it easy to
: write pseudo-keyboards (e.g. a program on my PC could get what I type
: and copy it to the Palm-PC's keyboard daemon over PPP).
I'm not following this remark in the context of Microwindows graphics
engine. Please explain.
Regards,
Greg
