Changes outside the framebuffer can sometimes be reported so we need to
make sure that we can deal with them gracefully.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/branches/1_0@3833 3789f03b-4d11-0410-bbf8-ca57d06f2519
The code to utilize our libjpeg's ability to input/output out native formats
failed to consider everything but the ideal cases. Clean up the code and make
sure it handles everything.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3795 3789f03b-4d11-0410-bbf8-ca57d06f2519
Make sure we send any modifications to the desktop layout in a message that
does not modify the framebuffer data. This is required to make sure we have
a valid state on the client as it drops the framebuffer when it recieves a
framebuffer dimension change.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3787 3789f03b-4d11-0410-bbf8-ca57d06f2519
UltraVNC sends a new non-incr. FUR when it gets a DesktopSize rect, and
TightVNC drops the framebuffer, so we can't realistically send it every
non-incr FUR. Besides, the client needs to keep track of framebuffer
dimensions anyway.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3786 3789f03b-4d11-0410-bbf8-ca57d06f2519
Change font path logic such that XFS is used if it is available and running, otherwise Xvnc is started with no -fp argument. If this fails, then Xvnc is restarted using the automatically-generated font path.
Added a copy of the license with DOS line breaks, so that we can ship
a license which is readable on Windows. I hate to make a copy, but our
current build system makes it difficult to auto-add DOS line
breaks. We can fix this when we have migrated to a
Makefile/Autotools/MSYS build system.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3778 3789f03b-4d11-0410-bbf8-ca57d06f2519
The index.vnc in the javabin directory was removed in r3667. We could
resurrect it, but the location is not very good. One alternative would
be to use java/src/com/tigervnc/vncviewer/index.vnc, but this file is,
despite it's location, specific to Xvnc. Long term, we should probably
merge the two different .vnc files into one. It might also make sense
to ship the WinVNC .vnc on disk rather than inside the EXE. But for
now, use the .vnc just as before. I have resurrected it in the winvnc
directory, though.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3776 3789f03b-4d11-0410-bbf8-ca57d06f2519
Fetch VncViewer.jar directly from the Java build directory, instead of
trying to use the path that we earlier used for the checked in binary
JAR.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3775 3789f03b-4d11-0410-bbf8-ca57d06f2519
Yet another version number fix. We had forgotten to update VERSIONINFO
in vncviewer.rc, plus we should use 0.0.90 rather than 0.9.0.
I'm dreaming of a future where the version number is SPOT.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3774 3789f03b-4d11-0410-bbf8-ca57d06f2519
Move autoreconf of the X server until after modules are built, because the X server build needs xtrans.m4 (which isn't always available on the system.)
Such high IDs are apparently unsafe to use in the system menu on some
machines. The messages get lost somewhere, probably intercepted by another
system-wide plugin.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3763 3789f03b-4d11-0410-bbf8-ca57d06f2519
Peter Åstrand
Adam Tkac
Pierre Ossman
DRC