[maemo-developers] hildon im to X key proxy

[From: Austin Che]

"Martin Grimme" <martin.grimme at gmail.com>:

> IIRC the GtkInvisible widget serves exactly this purpose.

    I tried using it and it doesn't work. The keyboard won't come up
    with this.
    
Santtu Lakkala <inz at inz.fi>:

>>     - I cannot make a completely hidden window. The best I can do is a
>>     1x1 pixel window that shows up as a white dot in the top left
>>     corner. Making it zero size, moving it off screen, or trying to
>>     make it transparent don't seem to work.
>
> Zero size probably doesn't work, but the two other options should. You
> might need to do them in the "map", "realize" or "expose-event" signal
> handlers (instead of upon creation).

    Thanks! This does work although it seems a bit like voodoo to
    me. If I do the window move in the "map" event, it appears to use
    a reference of the lower right corner. If I do it in realize or
    expose-event, it uses the top left (which the docs say should be
    the default). And setting the gravity before the move appears to
    do nothing. In any case, moving the window -1, -1 in the realize
    event worked great.
    
Eero Tamminen <eero.tamminen at nokia.com>:

> You could use something like matchbox-nest:
> 	http://packages.debian.org/etch/matchbox-keyboard

    Thanks for the link. That does do almost exactly what I want,
    but I like the maemo keyboard better than that one.  I did find
    that it uses libfakekey which fakes X keys from unicode characters
    in pretty much the exact same way that I was doing it so that's
    good as I can just use the library.

    But it also doesn't solve the main issues that I'm having. I want
    the window underneath to be resized and not be covered up by the
    keyboard. I also need to be able to receive the key focus but
    force it to lose the focus before sending the fake
    key. gtk_window_iconify may work but it appears to hide the vkb so
    it flashes annoyingly.

> Unicode covers a much larger range than X keysyms.

    I'm pretty sure this is not true. In include/X11/keysymdef.h, it
    says unicode chars are mapped to keysyms by adding 0x01000000 and
    that's how both gdk and libfakekey appear to do it.
    
> The application tells the window manager for which window the keyboard
> is opened with an X property I think.

    Using xprop, the property WM_TRANSIENT_FOR(WINDOW) on the vkb is
    usually set to the client window. However, if I follow this
    property value when I run my program, it doesn't change but rather
    stays set on my window. Yet the target window definitely does
    change away from my window. I don't know if there's another
    property you're thinking about, but it seems that even though this
    property is set, it doesn't necessarily map to the actual client
    window for the keyboard.