Re: [gtk-vnc-devel] gtk-vnc trouble
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Gerd Hoffmann <kraxel redhat com>
- Cc: gtk-vnc-devel <gtk-vnc-devel lists sourceforge net>
- Subject: Re: [gtk-vnc-devel] gtk-vnc trouble
- Date: Wed, 22 Aug 2007 16:20:58 +0100
On Wed, Aug 22, 2007 at 04:57:54PM +0200, Gerd Hoffmann wrote:
> Hi folks,
> I've recently tried to switch over my vnc client from libvncserver over
> to gtk-vnc. Meanwhile it works almost as good as it used to before,
> with a few remaining issues.
> Number one and most annonying is the i18n keyboard problem. My app used
> to simply send us keysyms unconditionally. Hackish, agreed. Worked
> reasonable well though, with the exception of keys not presend on us
> keyboards. Doesn't work any more as the keyboard handling is now in the
> widget source ...
Not sure what you mean by 'send keysyms unconditionally' ? Do you need an
API for injecting fake keysyms to the widget ?
> I remember there was some discussion on creating a vnc extention to
> allow sending keycodes instead of keysyms, which would fundamentally
> solve the keyboard mapping problems. What is the state here? Does it
> exist? qemu support? gtk-vnc support?
There's nothing in gtk-vnc or QEMU that I know of yet.
> Next problem is that the vnc_display_set_*_grab() functions seem to have
> no effect. Any hints on that one?
They ought to be working - the gvncviewer demo program uses them to control
whether pointer grab occurs or not. The default is not to grab pointer or
keyboard. Setting grab pointer, implies grab keyboard. It'll grab upon first
pointer press. If merely doing keyboard grab it grab keyboard on mouse enter
and ungrab on mouse leave of the widget.
> Also vnc_display_open(), vnc_display_close(), then again
> vnc_display_open() with the same widget instance doesn't work.
Do you call the vnc_display_close & vnc_display_open immediately following
each other, or does the mainloop run ? The close function does an asynchronous
shutdown so the GTK mainloop needs to run before it'll actually die off.
Looking at the code there may also be a bug, that the async shutdown doesn't
actually run until some IO event occurs. Will have to investigate that.
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
] [Thread Prev