so slow that it
would be CPU-bound, even on very slow broadband or satellite
connections, so what's the point?
Feedback is, as always, welcome.
DRC
--
Open source business process management suite built on Java
On 6/23/14 5:39 AM, Pierre Ossman wrote:
I'd like to keep the ball rolling here, so unless anyone objects I
intend to start officially setting things up this week.
One thing I wanted to ask-- you had mentioned that you were migrating
only the recent commits. Why not migrate the whole SVN
A more comprehensive version that also supports UltraVNC Repeater Mode I
has been checked into the TurboVNC subversion trunk. I implemented it
by extending the existing Via parameter (comments welcome.) Feel free
to borrow it if you find it useful.
NOTE: Mode I is using the repeater as a
Ossman wrote:
On Wed, 22 Jan 2014 17:30:25 -0600,
DRC wrote:
My proposal is for TigerVNC to adopt four compression modes: CL 0, CL
1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to
5, and the GUI could be restructured so that it sets the compression
level to low, high
On 1/25/14 3:04 PM, DRC wrote:
-- If someone decides that they want to jack it up to CL 9, this will
never have a negative effect on compression ratio relative to CL 6, but
whether it has a significant benefit will depend on the workload. On
average, 2D datasets will compress 10% better
:30:25 -0600,
DRC wrote:
My proposal is for TigerVNC to adopt four compression modes: CL 0, CL
1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to
5, and the GUI could be restructured so that it sets the compression
level to low, high, and very high, with a warning that very
Last year, I got involved in a project to port the TurboVNC encoder into
libvncserver, and in the process of doing this, I had to prove that the
Turbo encoder was capable of producing at least roughly equivalent
compression to the tightest modes in the TightVNC encoder. There are
lengthy
On 1/17/14 4:18 AM, Pierre Ossman wrote:
Another FYI. As part of the cleanup, I am seriously considering
removing colour map (i.e. palette) support. Reasons for doing so:
- It's a lot of added complexity for something that is rarely, if at
all, used today.
- Our current viewer
On 1/17/14 5:17 AM, Pierre Ossman wrote:
As far as the code is concerned, both. The protocol still mandates
support, hence the simple colour cube to support such clients (of
which I expect few).
Let me rephrase. Currently, when does that aspect of the protocol get
invoked? My understanding
On 1/17/14 11:11 AM, Alan Coopersmith wrote:
I think that's more a factor of using a video card driver that doesn't
simulate PsuedoColor visuals on modern 32-bit graphics cards - I don't
think we've removed PseudoColor support in Xorg completely, just not
done much with it in years.
Yeah,
Regarding H.264, I have some interest in that as well, but I wasn't able to
find a full specification for an H.264 RFB encoding, even though the encoding
number is allocated.
On Dec 18, 2013, at 3:27 AM, Pierre Ossman oss...@cendio.se wrote:
Just wanted to give everyone a heads up on what
/Users/drc/src/vnc/java/com/turbovnc/rfb/RREDecoder.java
2013-09-16 17:28:20.0 -0500
***
*** 39,43
int w = is.readU16();
int h = is.readU16();
! handler.fillRect(new Rect(x, y, w, h), pix);
}
}
--- 39,44
int w = is.readU16
The goal of a cross-compatible build isn't necessarily to eliminate all
dependencies but to eliminate dependencies that aren't forward ABI compatible
with the platform on which you build or which might not be readily available. I
would say that the goal should be to produce similar dependencies
An additional note: dpkg-deb doesn't require a Debian-based machine in
order to run, so it's pretty straightforward to generate DEBs on a Red
Hat machine as part of an automated build procedure. I do this for
VirtualGL and the other projects I maintain.
On 6/17/13 1:37 PM, Robert Goley
I've mentioned the performance issue before. Not sure what exactly is going on,
but the TigerVNC native viewer on Mac is on the order of 10x slower than it
should be. It has to be an FLTK issue.
On Jun 10, 2013, at 8:08 AM, Robert Goley rago...@rdasys.com wrote:
I haven't test 10.8 yet but it
Pursuant to our discussion on tigervnc-users regarding whether the
project RPMs could be used on SuSE, I noticed that the RHEL 5 RPMs and
the cross-compatible build have external dependencies on GnuTLS and
libstdc++. That prevents them from truly being cross-compatible. It
should be possible
On 5/17/13 2:01 PM, Brian Hinz wrote:
I think I'm actually using a patch that you posted to the list sometime
in Februaury(?). I wasn't able to build GnuTLS correctly on MinGW so
I'm linking against the pre-compiled version listed in BUILDING.txt
Ah. OK, that's what I'm doing as well. Just
Tags are supposed to be snapshots of a specific release. I think this
should have been copied into the 1.3 branch rather than the 1.3 beta1 tag.
On 5/7/13 5:50 PM, bph...@users.sourceforge.net wrote:
Revision: 5092
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5092view=rev
Unfortunately, SourceForge hasn't finished fixing all of the issues in the code
viewer. They're choosing instead to force feed us this upgrade before it's
fully cooked, and I am attempting to bring the issue to light as best I can,
but there may not be much for it at the moment. Once the
, Linux, and Windows. I am not
volunteering or accepting any responsibility for fixing the issues, nor
do I have time to debate them.
DRC
From 7a15d1c9a908afe429c1aba1c27516d18bdea299 Mon Sep 17 00:00:00 2001
From: DRC informat...@virtualgl.org
Date: Tue, 26 Feb 2013 03:37:12 -0600
Subject: [PATCH
On 2/15/13 3:38 AM, Pierre Ossman wrote:
But GPLv2 is broken, that's the point. Instead of me trying to
reiterate things, I'll just point to FSF's page on the matter:
http://www.gnu.org/licenses/quick-guide-gplv3.html
We've been through this before. FSF thinks GPL v2 is broken, and Linus
This is a roll-up of the relevant Allura code viewer features/fixes that
I believe are necessary for SF to address in order to provide an
environment as usable as ViewVC. If you have a SF account, please
consider voting these up so we can get SourceForge's attention.
Whenever a user clicks on
Why not break the shell script out into a separate file?
On 1/22/13 2:11 AM, astr...@users.sourceforge.net wrote:
Revision: 5031
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5031view=rev
Author: astrand
Date: 2013-01-22 08:11:05 + (Tue, 22 Jan 2013)
Log Message:
the
TCP port is handled correctly), but isn't really portable to Windows since
there isn't a standard ssh command line tool.
integrate SSH as a library (such as with the OpenSSH library). I
actually did this to the old viewer, but DRC was uncomfortable adding another
library dependency
On 1/16/13 3:12 AM, Peter Åstrand wrote:
Sure, but we don't have the details. It's not very useful to submit a
bug report that says it fails on some machines but not mine :-)
Didn't I just supply the details? And a fix?
No, because this is a bug introduced by the patches that Cendio made to
On 1/16/13 6:08 AM, Peter Åstrand wrote:
On Wed, 16 Jan 2013, DRC wrote:
On 1/16/13 3:12 AM, Peter Åstrand wrote:
Sure, but we don't have the details. It's not very useful to submit a
bug report that says it fails on some machines but not mine :-)
Didn't I just supply the details
On 1/16/13 6:56 AM, Peter Åstrand wrote:
The two major sponsors of the TigerVNC project are Cendio and Red Hat,
and we both are focusing on Linux, so it's quite natural that we favour
build systems that works good on Linux.
Few if any people have the resources to test things on more than a
On 1/7/13 4:25 AM, Peter Åstrand wrote:
(3) CMakeLists.txt in the FLTK build system needs to be patched as
follows:
Otherwise, it will try to add -lpng to all of the subsequent function
checks, which causes them to fail on some machines (including mine.)
Have you reported this to the FLTK
I should add that, with this patch, the build system can still be used
to regenerate the in-tree copies of the icons, if for any reason they
need updating. Simply
cd media
make clean
make icons
On 1/7/13 4:24 PM, dcomman...@users.sourceforge.net wrote:
Revision: 5024
.
Rgds,
Peter
On Mon, 26 Nov 2012, DRC wrote:
I added a brief list of critical features that I think are missing from
the new SVN viewer on this bug report:
https://sourceforge.net/p/forge/site-support/480/
Since posting this, they have fixed (2) [apparently a bug] and addressed
(4
, thanks for pointing this out. Can you describe more in detail what
features are missing? Have you reported this to
https://sourceforge.net/p/forge/site-support/ ?
Rgds,
Peter
On Wed, 21 Nov 2012, DRC wrote:
My main issue with the new platform at the moment is that they've
replaced
My main issue with the new platform at the moment is that they've replaced the
repository browser. Instead of ViewVC, it's now their own version that,
frankly, sucks. There are a lot of beta users, including me, complaining about
this. I am hoping they address that issue or provide a ViewVC
to a TurboVNC server.
DRC
Index: common/rfb/tightDecode.h
===
--- common/rfb/tightDecode.h(revision 4999)
+++ common/rfb/tightDecode.h(working copy)
@@ -1,6 +1,6 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights
On 10/2/12 5:21 AM, Pierre Ossman wrote:
The attached adds support for the unofficial rfbTightNoZlib extension
used by the TurboVNC Server to transmit Raw, indexed color, and mono
subrectangles without Zlib compression. This prevents the TigerVNC
Viewer from crashing if the user attempts to
to a TurboVNC server.
DRC
Index: common/rfb/tightDecode.h
===
--- common/rfb/tightDecode.h(revision 4999)
+++ common/rfb/tightDecode.h(working copy)
@@ -1,6 +1,6 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights
On 9/6/12 9:11 AM, Adam Tkac wrote:
In my opinion the best will be to automatically add VeNCrypt only when user
explicitly selects some VeNCrypt subtype (TLS*/X509*). If no VeNCrypt subtype
is
selected, then default should be VncAuth, not VeNCrypt,VncAuth, which is
default
now.
I concur.
On 7/13/12 3:09 AM, Pierre Ossman wrote:
I dived into vncHooks and xserver sources and attached patch should fix both
screen artefacts and XDrawArc crashes. It reverts r4220 and fixes
vncHooksFillSpans hook which used wrong clip pointer.
-Inf
Hooking pixmaps is just asking for problems.
On 7/3/12 3:42 PM, Brian Hinz wrote:
I'm not sure if this means anything to you, but I found that if I set
'AlwaysSetDeferUpdateTimer=1' then outline boxes are partially drawn and
damaged regions are sometimes partially redrawn. The location and
extent to which the lines are drawn is
On 6/5/12 1:51 AM, Peter Åstrand wrote:
vncviewer already has many command line parameters. We shouldn't add
another one unless it's absolutely necessary. It's better if things like
these can be handled automatically.
What you decide to do about it (if anything) is up to you. I'm just
On 6/4/12 6:30 AM, Pierre Ossman wrote:
However, I haven't examined the code
closely to see why that timer is there. What seems to happen is that,
whenever a rectangle is damaged, it triggers a timeout, and if the
rectangle isn't drawn within 1/2 second, it gets drawn anyway, so if the
frame
On 6/2/12 7:20 AM, Brian Hinz wrote:
I have observed the black notch issue with the java viewer previously as
well. If the call to paintImmediately in DesktopWindow.updateWindow
is replaced with repaint these notches are observed. Using repaint
rather than paintImmediately allows swing to
From my point of view (which is relevant because the new TurboVNC Java
Viewer and the TigerVNC 1.2 Java Viewer are about to share a very
similar code base), the ability to do -via and basic SSH tunneling
within the Java viewer will be very useful, but the ability to forward
arbitrary ports
On 3/21/12 8:05 AM, Arthur Huillet wrote:
For what it's worth, I think the issue is
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Yes, someone already posted that link.
I'm afraid I don't know how to do that. CMake is something I know enough to
know that I don't want to know any
On 3/13/12 5:45 AM, Adam Tkac wrote:
May I ask you if you have any scripts which you used for building
release/pre-release versions of TigerVNC? I would be glad if you share them.
I cleaned them up and checked them into
https://tigervnc.svn.sourceforge.net/svnroot/tigervnc/buildscripts/xc
Just FYI-- I looked at this briefly, and from what I can tell, what you
really want to be doing is linking against Xft, not against fontconfig.
Also, I think you only want to link against it when building the Unix
viewer, not the other versions (pretty sure the patch below would cause
a Windows
Are we ready to release?
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
https://sourceforge.net/projects/tigervnc/files/tigervnc/1.2.0/
Enjoy!
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on
-architecting it. Doing
that would require either an in-project or an out-of-project fork, and
at this point, the prevailing desire within the VirtualGL community is
just to go forward with TurboVNC instead.
I wish you all the best of luck.
DRC
On 3/2/12 3:32 AM, Arthur Huillet wrote:
--- a/common/rfb/tightEncode.h
+++ b/common/rfb/tightEncode.h
@@ -248,23 +248,28 @@ void TIGHT_ENCODE (const Rect r, rdr::OutStream *os,
bool forceSolid)
#if (BPP != 8)
if (jpegQuality != -1) {
encodeJpegRect(r, os);
+
Since I developed the original ALR mechanism for TurboVNC, I have a
couple of comments/critiques of this, based on the real-world usage of
the feature in TurboVNC. The first is that people use TurboVNC's ALR
feature in the medical viz industry, where mathematical losslessness is
important, so
from Pierre and DRC, this patch is an improved version.
- fix codingstyle issues
- shorten automatic lossless refresh - automatic refresh
- refresh delay parameter is also used as a enabled boolean
- ALR quality selection, including truly lossless (no JPEG) mode
I missed that part of the discussion on the tracker. What is the purpose of
having this in the viewer?
On Feb 16, 2012, at 6:44 AM, bph...@users.sourceforge.net wrote:
Revision: 4857
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4857view=rev
Author: bphinz
Date:
On 2/10/12 11:15 AM, Pierre Ossman wrote:
You mean this code?
if (ig-willTransform()) {
ig-translatePixels(pixels, solidColor, 1);
pixels = (PIXEL_T *)solidColor;
}
I don't follow. As you can see, it changes the value of the pixels
pointer so that it points at the
On 2/3/12 12:12 AM, Brian Hinz wrote:
Sorry, my bad, I thought you had actually branched 1.2 already. I don't
think this is release ready code, would it make more sense to branch at
4840 or 4841, or for me to back out 4842 temporarily and re-apply after
you branch?
The 1.2 branch has now
-- particularly why encodeJpegRect16() and encodeJpegRect32() were
replaced with encodeJpegRect(). Yes, I see that you're now re-calling
ig-getRawPixelsR() in the body of encodeJpeg(), but why?
On 2/3/12 9:00 AM, Pierre Ossman wrote:
On Tue, 31 Jan 2012 05:03:06 -0600
DRC dcomman
On 2/9/12 6:34 AM, Pierre Ossman wrote:
On Sun, 05 Feb 2012 15:32:52 -0600
DRC dcomman...@users.sourceforge.net wrote:
Perhaps I'm still missing something, because after examining the patch
again, I don't see where the original buffer corruption was occurring or
how your patch fixes
I hadn't actually branched 1.2 yet, so trunk is still supposed to be
stable. I was waiting for a more reasonable explanation of 4841 from
Pierre before branching, as that patch appears destabilizing as well.
On 2/2/12 11:38 PM, bph...@users.sourceforge.net wrote:
Revision: 4842
, my bad, I thought you had actually branched 1.2 already. I don't
think this is release ready code, would it make more sense to branch at
4840 or 4841, or for me to back out 4842 temporarily and re-apply after
you branch?
Thanks,
-brian
On Fri, Feb 3, 2012 at 12:51 AM, DRC dcomman
On 1/31/12 2:57 AM, Pierre Ossman wrote:
On Mon, 30 Jan 2012 15:55:11 -0600
DRC dcomman...@users.sourceforge.net wrote:
How does it not work so well? You can't just commit potentially
disruptive patches after the code has been stabilized without first
opening them up for discussion.
I
How does it not work so well? You can't just commit potentially
disruptive patches after the code has been stabilized without first
opening them up for discussion.
I expect a more detailed answer than your commit log below.
On 1/30/12 7:58 AM, ossm...@users.sourceforge.net wrote:
Revision:
On Dec 28, 2011, at 9:25 AM, Peter Åstrand astr...@cendio.se wrote:
On 12/22/11 2:41 AM, Peter Åstrand wrote:
I'll let Pierre give you the details of the -DeferUpdate values, but if
it turns out that it's not possible to find a default that fits
everyone, then I'm suggesting that we create a
On Dec 28, 2011, at 10:22 AM, Peter Åstrand astr...@cendio.se wrote:
On Wed, 28 Dec 2011, DRC wrote:
I'm pretty sure the message from Pierre was that it's not important enough to
block a new release; not that we have a solution that fits both use cases
optimally.
We might solve
https://sourceforge.net/projects/tigervnc/files/tigervnc/1.1.90%20%281.2beta1%29/
Enjoy!
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to
On 12/21/11 4:30 AM, Pierre Ossman wrote:
There was a request to let the community know a bit more about what
Cendio is up to with regard to releases. So I'd like to take this
opportunity to mention that we are releasing a beta for our next
release, meaning we are going into pure bug squashing
On 12/9/11 3:35 AM, Pierre Ossman wrote:
If I instead run with the regular 100 Mbps transfer rate but still
artificially add latency via qdisc, then I can see a clear benefit, both
qualitatively and quantitatively-- as long as I jack up the TCP max
buffer sizes to 8 MB in /etc/sysctl.conf:
:47:14 -0600
DRC dcomman...@users.sourceforge.net wrote:
Yes, I'm getting the enabling continuous updates message. How I'm
testing is to look at responsiveness when running 'vglrun glxspheres -i
-fs' with quality=1 and compress level=1. I move the mouse across the
screen and gauge
, Pierre Ossman wrote:
Any luck getting this working?
On Thu, 1 Dec 2011 11:31:25 +0100
Pierre Ossman oss...@cendio.se wrote:
On Wed, 30 Nov 2011 15:47:14 -0600
DRC dcomman...@users.sourceforge.net wrote:
Yes, I'm getting the enabling continuous updates message. How I'm
testing is to look
On 12/7/11 2:44 AM, Pierre Ossman wrote:
Annoying. I did some work at making the thing more asynchronous, but
more might be needed. If the problem is getting the data on the wire
rather than the actual encoding, then a quick fix is increasing the
outgoing buffer size. As long as your entire
represent a
performance regression, since LAN performance has now decreased by 40%
with default settings.
DRC
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers
On 11/29/11 4:14 AM, Pierre Ossman wrote:
It would really be nice to quantify it somehow, because it doesn't seem
to be any better in terms of responsiveness, either. I'm testing up in
the range of 100-200 ms ping time, or rather, 50-100 ms added on both ends.
That's odd. Maybe it's not
to the poster, even though the information is relevant to the
entire list. Thus, we are in some cases losing records of solutions to
problems or vital diagnostic information that could be useful to someone
searching for a solution to the same issue.
Can we please re-visit this?
DRC
On 11/29/11 3:34 AM, Pierre Ossman wrote:
In the
next-gen version of TurboVNC, manually enabling the Continuous Updates
extension (which causes the TurboVNC server to send updates immediately
to the client) produces significantly better throughput on this type of
connection, but none of the
On 11/22/11 3:07 PM, Martin Koegler wrote:
On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote:
I'm still in the process of developing an integrated remote desktop system
for a specialist user base, and am using TigerVNC to great effect so far.
I would like to enable client connections
Not sure if I understand why it couldn't be overridden by passing
compareFB=1 on the command prompt to always enable it.
On 11/17/11 7:23 AM, Pierre Ossman wrote:
Suggested patch. It does the following:
- CUT block size changed to 64 pixels. This size in most cases has a
CPU usage similar
On 11/17/11 12:43 PM, Pierre Ossman wrote:
Because it's a boolean. It has just the states true or false. There is
no mechanism to see if the user didn't bother specifying anything (and
I'm not sure that's desirable anyway). So we cannot map our three
states to it (always on, always off, auto).
On 11/16/11 5:25 AM, Pierre Ossman wrote:
JPEG quality level 1 is not what I'm considering a reasonable WAN
setting, so I'm not sure how realistic these numbers are. Still, I
think my conclusions are roughly the same.
Well, then, what are you considering to be appropriate WAN settings?
When my
The attached spreadsheet shows the low-level performance effects of
enabling and disabling the CUT, as well as the effect of changing its
block size to 256 x 256 instead of the default of 16 x 16. Tests were
performed both with typical LAN settings (compress level=1/quality
level=8) and WAN
as tuned for LANs at the expense of
everything else is not our goal. The defaults should reflect the needs
of the majority of users. We're trying to create a well-rounded VNC
implementation that can be used for a broad range of applications, not
just
Understood, which is why I proposed to
further when I'm back in the office.
On Nov 11, 2011, at 8:54 AM, Brian Hinz bph...@users.sourceforge.net wrote:
Initially I would have agreed completely with DRC since 95% of my users are
on GbE fiber, but if those numbers accurately reflect typical usage (and it
would seem they do) then I
rate.
On Nov 10, 2011, at 8:08 AM, Pierre Ossman oss...@cendio.se wrote:
On Thu, 10 Nov 2011 07:33:58 -0600
DRC dcomman...@users.sourceforge.net wrote:
Strongly object. The performance hit by turning it on is severe and not
something that can just be optimized away. My testing shows
windows around, etc.) If you have a reliable way of
testing the Copy filter, then you should be able to invoke the code
below by running vncviewer on an X server with a depth of 16.
On 11/9/11 3:23 AM, matthieu.lochegn...@altissemiconductor.com wrote:
DRC dcomman...@users.sourceforge.net wrote
Can you explain what all of the fence stuff is doing? Also, why is
there both a CU message (which uses the registered number of 150) and a
CU pseudo-encoding?
On 11/9/11 3:41 AM, Pierre Ossman wrote:
Here is the promised patch to fix the latency issue in VNC. The basic
idea is to let the
On 11/9/11 1:15 PM, matthieu.lochegn...@altissemiconductor.com wrote:
I ran into it when using Xvnc from the RHEL6 package:
tigervnc-server-1.0.90-0.10.20100115svn3945.el6.x86_64.
I just did what you told: I started a Xvnc with depth 16, displayed on it
a terminal (with a window manager), and
http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases
-- Contains my client-side performance optimizations
-- Contains numerous Java viewer fixes
-- Windows code is now built with MinGW
-- NLS theoretically works with the 32-bit Windows vncviewer, (if you
were to install the .mo files under
I have re-spun the build to add Pierre's Tight decoder bug fix and other
enhancements from today
On 11/8/11 4:17 AM, DRC wrote:
http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases
-- Contains my client-side performance optimizations
-- Contains numerous Java viewer fixes
-- Windows
On 11/7/11 2:44 AM, Peter Åstrand wrote:
Wrt DRI: I must admit that I don't fully understand how it works, but at
least for Xorg server 1.5, DRI1 is not necessary for GLX, but DRI2 is,
it seems. We are building with these flags:
That was the clue I needed. Apparently it wasn't properly
of
the X server this affects.
Any ideas on how to resurrect our official project builds?
DRC
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
checked in earlier.
Looking into it.
DRC
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Tigervnc-devel mailing list
Tigervnc
I personally have no problem with this change, but I just wanted to note
that the names are listed as TurboVNC blah blah blah in the official
upstream RFB spec, so this change causes our spec to differ from the
upstream one. Don't know if that's a problem or not.
On 10/27/11 7:12 AM,
Let me explain something about quality control. When someone has spent
many dozens of hours debugging both the performance and stability of a
piece of code at the low level, then whenever you make sweeping changes
to it like this, it is incumbent upon you to either work with the person
who tested
On 10/7/11 2:35 AM, Peter Åstrand wrote:
For the record, I did try this 2 years ago, with the patch you and
Pierre submitted upstream to MinGW. It compiled but did not link.
So why didn't you report this? I cannot found anything about this,
neither in the tracker nor on the mailinglist. The
On 10/6/11 2:50 AM, Peter Åstrand wrote:
Remind me, which functionality is missing if you build without Visual
Studio?
WinVNC. It's always been WinVNC.
It seems to me that instead of wasting time on maintaining multiple tool
chain, you could invest that time in streamlining the GCC based
On 10/6/11 4:48 AM, Peter Åstrand wrote:
Yes, but what is the problem with WinVNC? Nevermind, I looked back at
the discussions myself. It's the problem with IActiveDesktop missing
from the MinGW distro.
IMHO, this is not unsolvable. If MinGW still refuses to add support for
this, we should
, I think that splitting
WinVNC into its own sub-build has other advantages as well, irrespective
of the choice of compiler, and I like the idea of having separate
installers for server and viewer.
On 10/6/11 9:31 AM, Peter Åstrand wrote:
On Thu, 6 Oct 2011, DRC wrote:
IMHO
On 10/4/11 4:34 AM, Peter Åstrand wrote:
Frankly, the fact that the main project developers insist on the use of
esoteric build environments is a problem.
MinGW had 1,059,337 downloads the last 7 days. The method of cross
compiling Windows binaries on Linux, using MinGW, is used by popular
Personally, I'd be in favor of removing the old viewers from trunk
immediately. It doesn't make sense to me to keep code in trunk that
isn't going to be part of a future release. trunk is not meant to be a
stable code base. It's meant to be a next-generation code base on which
new releases will
On 9/23/11 6:17 AM, Pierre Ossman wrote:
In order to make it easier to update information about TigerVNC, I
suggest we move our web page over to the wiki. I've done an initial
attempt at converting our existing page over. So if people could have a
look, and if it looks okay then one of the
+S-2+C0+I0+E0+Q2641
On 9/18/11 4:16 PM, DRC wrote:
Please post information regarding issues fixed by this patch.
On 9/16/11 6:51 AM, hea...@users.sourceforge.net wrote:
Revision: 4675
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4675view=rev
Author: hean01
Date: 2011
On 9/14/11 9:45 AM, Adam Tkac wrote:
Hello all,
I tried to compile new viewer (from trunk) and use bundled fltk but I
got following error:
/usr/bin/ld: ../common/fltk/src/libfltk_static.a(Fl_Preferences.cxx.o):
undefined reference to symbol 'dlopen@@GLIBC_2.2.5'
/usr/bin/ld: note:
On 9/9/11 3:28 AM, Pierre Ossman wrote:
Chill. Saying that people cannot do any changes without first getting
your seal of approval and/or spending hours of testing even for small
changes is not a constructive way to encourage development on this
project.
With respect to the Tight encoder, I
1 - 100 of 359 matches
Mail list logo
