nanogui: Thread: X11 compatibility and pseudo-keyboards.

Hello,

My two main concerns regarding nano-X at the moment are :
1) differences from X11, I would like Xcopilot to run on it.
2) having keyboard replacements (if possible in a modular way).

I have done some investigations about both.

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
!).
Also, I am a bit worried about image functions implementation, I hope
nano-X will soon have XCreateImage and XPutImage like functions.

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).

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. 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 would be interested to know what you think about these issues.


	P.O. Gaillard

: 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

with the whole Xlib ontop of nanox. i have been playing with
preprcessor macros for the lib. this means that instaed on symbol
conflicts - the actually functions are substiuted when compiled.

i qwill allow ppl to look at this soon - i have also 
created a small toolkit called ptk - it's currently
very like gtk. i have windows, menus and buttons working.


chris

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Mon, 6 Dec 1999 14:55:11 -0700  you wrote: 
>: 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.  
 
We'll start working on an on screen keyboard soon... I'm not exactly 
sure when it will be done, but sometime after the initial version of 
the widget set is ready (we have three developers working on it now, 
and the plan is to be done before christmas). We currently have sliders, 
text entry, labels, buttons, toggle buttons, radio buttons and soon an 
image widget.  
 
Vidar Hokstad 
Screen Media AS 
 

: We'll start working on an on screen keyboard soon...

Wow.  That'll be great!  I assume it will be a widget?

Do you plan on anything fancy for function keys, or will it just be
a-z0-9 type thing?  In other words, should I come up with the internal
representation for function keys etc?


 I'm not exactly 
: sure when it will be done, but sometime after the initial version of 
: the widget set is ready (we have three developers working on it now, 
: and the plan is to be done before christmas). We currently have sliders, 
: text entry, labels, buttons, toggle buttons, radio buttons and soon an 
: image widget.  

Glad to hear of progress.  Also, I'd like to know how well
the speed improvement of 0.87 fares, if you find time to use
that version.

Will the image widget need to allocate colors in palette space?
If it calls GdDrawImage, it'll all be automatic.

Greg

On Tuesday, December 07, 1999 6:14 AM, Chris Ross  wrote:
: with the whole Xlib ontop of nanox. i have been playing with
: preprcessor macros for the lib. this means that instaed on symbol
: conflicts - the actually functions are substiuted when compiled.


Cool.  When you get it completed, I'll add the header file to the
distribution

> 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?
> 
  They open the tty used by the X server and write scancodes to it so
that 
 the X server uses them as if they had been typed on keyboard. At least
that is what I understood from the program.
> 
> I'm not following this remark in the context of Microwindows graphics
> engine.  Please explain.
 What I meant was that I found the above described solution crude and I
would have liked something like an abstract pseudo-keyboard feeding the
Nano-X server
and accepting scancodes from miscellaneous programs (being able to
change dynamically). 
Thus the flow of scancodes would be as follow :
keyboard emulation program 1      keyboard emulation program 2
         |                       /
         | scancodes           / scancodes
         |                   /
       pseudo-keyboard server
         |
         | scancodes 
         |
  Nano-X server 
         
So you could easily switch from one keyboard emulation program to
another,
use another keyboard over PPP and so on.

But maybe this is overcomplicated.

Also, I had overlooked the concern about namespace conflicts for X11.
This is not surprising since I only intend to use client-server Nano-X
(yes I am biased) and the problem does not occur in such a case (server
bound with real Xlib, client bound with fake Xlib).
I would really like to see what mister Ross has done about Xlib and what
Screenmedia is planning for keyboard emulation (graffitti-like or
something else ?). I'd love to help.
	
		P.O. Gaillard

On Tue, 7 Dec 1999 11:28:24 -0500 you wrote: 
>: We'll start working on an on screen keyboard soon...  
>  
>Wow.  That'll be great!  I assume it will be a widget?  
 
It will be a stand alone application. I'm not sure if all of it will be 
released, but I'll see what I can do to get the important parts released ;) 
 
>Do you plan on anything fancy for function keys, or will it just be  
>a-z0-9 type thing?  In other words, should I come up with the internal  
>representation for function keys etc?  
 
It will be as configurable as possible... We need to support some function 
keys, especially cursor keys, and it has to be configurable enough for us to 
be able to handle most national keyboard variants. 
 
Btw... Maybe we should start thinking about Unicode support right away, before 
to much about the font and keyboard handling is added... 
  
>Glad to hear of progress.  Also, I'd like to know how well  
>the speed improvement of 0.87 fares, if you find time to use  
>that version.  
 
I'm testing with 0.87 now, and it works well. However the test 
application doesn't exactly test performance much, and I run it 
on a fairly fast machine, so I won't get a chance to evaluate 
performance until I get to test the Opera build for 0.87. 
  
>Will the image widget need to allocate colors in palette space?  
>If it calls GdDrawImage, it'll all be automatic.  
 
So far we've used RGB values. For images we will use GrArea() for now, 
but may add a variation of the image widget that uses GdDrawImage later. 
 
Regards, 
Vidar Hokstad 
Screen Media 
 

: It will be a stand alone application. I'm not sure if all of it will be 
: released, but I'll see what I can do to get the important parts released
;) 

That would be nice, especially the graphical part.

If the keyboard is going to be a separate process, then we need
a mechanism that will allow a process to submit keystrokes to 
the Nano-X server's hardware keyboard input queue.

:: Btw... Maybe we should start thinking about Unicode support right away,
before 
: to much about the font and keyboard handling is added... 

I think the keyboard input should be stored and handled internally
as Unicode.  Function keys can be stuck in as 16 bit values somewhere
in that space.

For graphics text output, it's a little more complicated, in that supporting
Unicode fonts for everybody will make programs and font files bigger.
Perhaps we should have both 8bit and 16bit textout routines, along 
with Unicode and non-Unicode fonts?  Or perhaps a Unicode
mapping table in every font, which could default to NULL for the ascii
fonts in the 0-127 range.

Greg