Moves a few files to more sensible locations given the directory layout which TightVNC recently moved to
Replaces the old makefiles with a new one which supports the directory layout which TightVNC recently moved to
New makefile doesn't require an explicit list of source files in the makefile
Corrects package names in several files
Fixes several minor upstream bugs
Always show graphical error messages (not just in Applet mode)
Adds support for mouse wheel (when run in JRE 1.4 or later)
Automatically synchronizes local and remote clipboards
The following four scaling patches are separated only for readability - they are not intended to be applied independently.
Allows scaling the window to an arbitrary width/height (uses a float multiplier instead of an int, and uses separate multipliers for width and height)
Improves scaling size calculations to properly account for window decorations
Shows scroll bars in applet mode if applet is smaller than the frame buffer
Supports scaling in applet mode
Adds a 'fixed ratio' scaling option to preserve the frame buffer's aspect ratio when scaling
Improves scroll pane / window size calculations
Renames updateFramebufferSize() to setFramebufferSize() (to be more consistent with other function names)
Removes unnecessary dependency on updateFramebufferSize() from setPixelFormat()
Cleans up some indenting and comments that were left out of the other patches for readability
Eliminates the unused maxWidth/maxHeight parameters to the VncCanvas constructor
Adds support for audio when connecting to a QEMU VNC server
- Audio settings are currently hard-coded in VncViewer.java - I still need to add options to disable audio and adjust audio settings
- Currently breaks compatibility with JVMs older than 1.3 - I still need to add code to gracefully drop audio support when running in an older JVM
- Audio processing has been specifically written to avoid blocking video frame buffer processing, but the original video processing code will block audio processing.
This means that audio works fairly well if there are few video updates (for example, if just playing music), but frequently under-runs it's buffer when the client is processing lots of video updates (for example, when playing a video). It is workable, even for playing videos, if you have plenty of bandwidth and use the Raw video encoding (to minimize video processing delays), but this should really be fixed by decoupling the protocol processing code from the video decoding code (as I did for audio processing). I plan to add another patch to accomplish this.
- QEMU's audio protocol VNC extension is non-standard and does not support negotiation of audio support or audio formats. If possible, I'd like to add a TightVNC protocol extension that provides better audio support, and incorporate audio support into the TightVNC servers.
- QEMU currently supports only raw PCM audio. This patch supports compressed audio formats (OGG, MP3), so compression support should be added on the server-side to allow use over a low-bandwidth link.