Aha. OK, that makes more sense. I'll look into it.
On May 5, 2011, at 6:26 AM, Rafael Guimaraes wrote:
> In fact, I have tested just with the Java viewer. But now I have
> tested it with both the Linux and Windows viewers and it behaved
> nicely... The problem seems to be only in the Java versio
In fact, I have tested just with the Java viewer. But now I have
tested it with both the Linux and Windows viewers and it behaved
nicely... The problem seems to be only in the Java version.
2011/5/4 DRC :
> No clue. The best I could do would be to try to reproduce it with a
> test application. T
No clue. The best I could do would be to try to reproduce it with a
test application. The fact that it exists in TigerVNC as well suggests
that it's intentional behavior, because Tiger and Turbo do not share any
code. Without knowing why the behavior exists in the first place, I'd
be hesitant to
I've go the same problem with TigerVNC. Any clue?
2011/5/4 Rafael Guimaraes :
> It doesn't respond to the events... This tool is useless when using
> TurboVNC+VirtualGL. I'll try with TigerVNC...
>
> 2011/5/4 DRC :
>> How is this interfering with the app? Does the app respond to the
>> keypress e
It doesn't respond to the events... This tool is useless when using
TurboVNC+VirtualGL. I'll try with TigerVNC...
2011/5/4 DRC :
> How is this interfering with the app? Does the app respond to the
> keypress events?
>
> Try it with TigerVNC:
> http://www.virtualgl.org/DeveloperInfo/TigerVNCPreRel
How is this interfering with the app? Does the app respond to the
keypress events?
Try it with TigerVNC:
http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases
That would tell me whether it's something specific to our implementation
or something which is endemic to VNC in general.
On 5/4/1
