Re: [Tigervnc-devel] Build process for the X-Server loadable module libvnc.so
On Fri, 28 Jun 2013, Christian Steinle wrote: Dear TigerVNC developers, when I had to update the X-Server in combination with the loadable TigerVNC module in our OS, I was surprised that I had to have still two separate build procedures due to the requirements in the configure options. Maybe I missed some issues requiring that procedure. Nevertheless I spent for that reason some time to completely integrate the TigerVNC 1.2.90 build process of the VNC module into the build process of the X-Server 1.10.1. So the attached patches xserver.patch and build.patch might be interesting for the community, because they simply add the configure option --enable-xvnc to the X-Server, which enables the generation of VNC without the need for other configure options likes --disable-dri, etc. Consequentially I can fetch the sources of the X-Server, the sources of TigerVNC into xserver/hw/vnc and directly compile the X-Server as well as the loadable VNC module. Maybe there could be also the possibility that the X-Server community accepts the modifications in their maintained files, because nothing is broken, if the directory xserver/hw/vnc does not exist, and XVNC is analog to XNEST, XVFB and so on. I understand your use case, but I believe it is somewhat unusual that you want to build the Xserver as well as Xvnc from the same source. Linux distributions, for example, have separate packages for the normal Xserver and Xvnc/vnc.so. For a casual Xvnc builder, it will just make things more complicated when you have to specify --enable-xvnc. If upstream Xorg would accept a generic VNC patch that could be interesting, but in that case we probably need to remove references to tigervnc. Having to apply a patch to the Xserver before building Xvnc/vnc.so is not necessarily a bad thing. From time to time, the patch might be small, but it gives us an oppurtunity to change certain aspects, when necessary. For example, if you take a look at xserver114.patch you will see that we are also modifying WaitForSomething. But of course, if we can minimize the number of things we need to change, compared to upstream, that is good. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] SourceForge project upgrades start April 22 (fwd)
FYI. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Forwarded message -- Date: Fri, 5 Apr 2013 18:35:23 + From: SourceForge.net Team nore...@sourceforge.net To: astr...@lysator.liu.se Subject: SourceForge project upgrades start April 22 Dear SourceForge project member, As you're no doubt already aware, we're in the process of upgrading projects to our new developer platform. The new platform is named Allura, and is in incubation at the Apache Software Foundation (http://incubator.apache.org/allura/). In recent weeks, we've been upgrading projects that have been inactive for a while. Now, it's time to start upgrading everyone else. As you can no doubt understand, we're anxious to complete this process so we can spend less time maintaining the old platform, and more time improving the new one. However, we also want to be sure that you have plenty of time to check out the new platform and have your concerns, if any, addressed. We're going to start upgrading active projects starting on Monday, April 22, starting with the longest-inactive and moving forward. Since each upgrade takes a different amount of time, depending on the size of the repositories, mailing list archives, and so on, we can't tell for sure when we'll get to your project. If you're ready to go ahead and upgrade your project now, you can do that at http://sf.net/p/upgrade/ If you have a specific concern about the upgrade, or need to delay the upgrade of your project, due to a release or other project activity, please get in touch NOW, at communityt...@sourceforge.net so that we can work something out. -- SourceForge Community Team communityt...@sourceforge.net http://sourceforge.net/ -- SourceForge.net has made this mailing to you as a registered user of the SourceForge.net site to convey important information regarding your SourceForge.net account or your use of SourceForge.net services. We make a small number of directed mailings to registered users each year regarding their account or data, to help preserve the security of their account or prevent loss of data or service access. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New (pre-)release
On Thu, 4 Apr 2013, Brian Hinz wrote: Sounds good. In the interim, does anyone mind if I start posting pre-releases via DRC's upload script that's in trunk? I was thinking that I would provide RPMS/SRPMS for el5 el6, as well as a tarball with the el5 build contents. Personally, I'd also like to see a copy of each of the viewers (linux/windows/java/mac?) made available standalone as well. It can be very convenient when you just need a viewer but can't or don't want to install the whole package. We don't mind at all. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New (pre-)release
On Fri, 29 Mar 2013, Brian Hinz wrote: I started down the path of creating an EPEL branch for EL5, but the policies regarding duplication of system libraries make it virtually impossible to build an EL5 package that complies with FESCo rules. I gave up on the idea of an EL5 branch for EPEL when I was told that I would have to backport the code to make it work with the legacy system libraries. I'd still be willing to maintain that RPM and provide it via TigerVNC's download page (assuming that's OK with the other devs). The build is based on DRC's build script so the resulting binaries could also be packaged as a tarball and would likely function on other distros. Thanks for your work on this. The Xvnc and vncviewer that we ship in ThinLinc are known to work on a wide range of distributions. We have thought of using the same system for doing nightly builds of he upstream TigerVNC source as well, but unfortunately we haven't been able to find time for this yet. Pierre is working on the keyboard handling (XKB), but as soon as this work is complete, we can create a 1.3 beta. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On Wed, 16 Jan 2013, DRC wrote: If you want, I can see if we can switch our internal FLTK build to CMake instead of Autotools, but I'm not sure what else we can do. Now done. I've also updated BUILDING.txt so that the list of patches is in sync. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[5031] trunk/BUILDING.txt
://p.sf.net/sfu/learnnow-d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
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 folks? Again, probably makes sense to
wait with further debugging on this until we have 1.3.2.
No, because it's frankly not my problem, and it would be a lot quicker
for you and Pierre, who have inroads into the FLTK project, to report
it.
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 :-)
(4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
FLTK build system is patched as follows:
As point 3), I think.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
Ok, that makes sense. Would it be possible for you to extend the patch in
this way? We do not build FLTK with CMake.
(6) The TigerVNC build will fail unless I patch TigerVNC's
CMakeLists.txt as follows:
--- CMakeLists.txt(revision 5021)
+++ CMakeLists.txt(working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
distribution vendors will run into this problem, since they'll probably
want to use the system libpng. Since the patch above does no harm when
using FLTK's internal PNG library, I would suggest going ahead and
applying it to TigerVNC.
Shouldn't this go into vncviewer/CMakeLists.txt instead?
Effectively, it probably doesn't matter either way, since FLTK is only
used when building vncviewer, but since libpng is a dependency
introduced by FLTK, it made sense to me to include it in FLTK_LIBRARIES.
But either way you want.
I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
this:
if(UNIX AND NOT APPLE)
# Needed to load icon files
target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY} png
-Wl,-Bdynamic)
endif()
(7) Building FLTK using MinGW is problematic because of the dependency
on the libgcc and libstdc++ DLL's. These dependencies are automatically
Yes, this is somewhat problematic, but as you point out, this is really
a problem with FLTK rather than TigerVNC.
You keep saying that, but I'll say again like I said before-- this is
effectively a regression in the TigerVNC build, because this problem did
not exist in the 1.2 build by virtue of the fact that FLTK was being
built in tree.
Yes, we should make it as easy as possible. Shouldn't be necessary to
tweak FLTK though; linking libgcc and libstdc++ statically can be done
from the TigerVNC make files.
The problem is that Windows has a convert executable that's part of
the operating system, but of course it is not the right convert
executable. On Linux, if ImageMagick is not installed, the build fails
cryptically with cannot find /usr/bin/convert or something like that.
Rather than argue, I checked in a patch (5024) that I have verified to
fix the issue and build correctly on all platforms.
Thanks.
I will now take a look at adjusting the build procedure for FLTK 1.3.2.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
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? And a fix?
Yes, a fix, but I don't understand on which machines this is failing, or
why.
Really, it's much better if you communicate with the FLTK upstream
directly. We have no special communication channels.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
Ok, that makes sense. Would it be possible for you to extend the patch
in this way? We do not build FLTK with CMake.
Well, if you don't build FLTK with CMake, then why does the documented
procedure for building FLTK (in BUILDING.txt) require CMake?
I think this was my mistake. If I remember correctly, I assumed that we
were also building FLTK with CMake and didn't check this. One advantage
though is that it imposes fewer dependencies. For example, if you are
building on Windows, I suppose building with Autotools requires you to
install more packages(?).
This is the basic problem I've been complaining about all along-- a
fundamental disconnect between what users of the open source code are
expected to do and what Cendio actually tests. In other words, you guys
need to eat your own dog food.
We are working in this direction. Removing the in-tree FLTK version was
one such step. We are not using it, so it constantly got out of sync.
Nowadays, the documentation in BUILDING.txt is directly copied from our
build scripts, and we are documenting and recommending exactly that FLTK
version and those patches that we are actually using.
I think it's unfortunate that FLTK is trying to support two different
build systems. My experience is that this never works. Accordingly, I have
opened up http://www.fltk.org/str.php?L2916 .
Anyway, in the mean time, the question is if we should start building FLTK
with CMake, or if we should change the documentation to recommend
Autotools instead? When looking in the FLTK repository, it seems to me
that the CMake build system gets less attention than the Autotools one,
and is constantly lagging behind. For example, configure.in says we are at
FLTK 1.3.1, while CMakeLists.txt says 1.3.0. There are several bug reports
of that the CMake files are out of sync, for example
http://www.fltk.org/str.php?L2088 .
My suggestion is therefore that we start recommending building FLTK with
Autotools instead. Ok with everyone?
I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
this:
if(UNIX AND NOT APPLE)
# Needed to load icon files
target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY}
png -Wl,-Bdynamic)
endif()
So add it to everyone's build, then.
We have additional makefile tweaks; we'll need to check if they are
required as well. I'll see if I can find some time for this.
Yes, we should make it as easy as possible. Shouldn't be necessary to
tweak FLTK though; linking libgcc and libstdc++ statically can be done
from the TigerVNC make files.
Try it. I think you'll find, as I did, that it doesn't work that way.
It works in our build system, so I'm sure it's possible. I'm not saying
that it's easy though...
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On Wed, 16 Jan 2013, DRC wrote: My suggestion is therefore that we start recommending building FLTK with Autotools instead. Ok with everyone? sigh No. Again, goes back to the eat your own dog food thing. If you ever actually tried to build TigerVNC on a real Windows platform, you would understand why most things you have done to make it easier on yourself as a Linux developer have made it harder on Windows developers. 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 handful of platforms. We are building and testing TigerVNC for all supported platforms (Linux, Solaris, Windows, Mac), but with only one build system (cross compilation under Linux). We are not building on any version of Windows, Solaris, or Mac OS X. We don't have the resources to do that. Sorry. If you want, I can see if we can switch our internal FLTK build to CMake instead of Autotools, but I'm not sure what else we can do. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On Sat, 5 Jan 2013, DRC wrote:
(1) BUILDING.txt needs to be modified to indicate that
fltk-xfixes-xcursor-cmake.2.patch should be applied with patch -p0, not -p1.
Fixed.
(2) It would be much more convenient if BUILDING.txt contained full
links to the patches, rather than links to the page from which they are
downloaded. That way, one could use wget to download them, which is a
more streamlined workflow, since one is building from the command line.
Yes, I guess that would be useful. Right now, however, the plan is to
update to FLTK 1.3.2 as a base. That will get rid of many patches.
(3) CMakeLists.txt in the FLTK build system needs to be patched as follows:
--- CMakeLists.txt (revision 9619)
+++ CMakeLists.txt (working copy)
@@ -167,6 +167,9 @@
endif(LIB_png)
CHECK_FUNCTION_EXISTS(png_get_valid HAVE_PNG_GET_VALID)
CHECK_FUNCTION_EXISTS(png_set_tRNS_to_alpha HAVE_PNG_SET_TRNS_TO_ALPHA)
+if(LIB_png)
+ set(CMAKE_REQUIRED_LIBRARIES )
+endif(LIB_png)
CHECK_FUNCTION_EXISTS(scandirHAVE_SCANDIR)
CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF)
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 folks? Again, probably makes sense to
wait with further debugging on this until we have 1.3.2.
(4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
FLTK build system is patched as follows:
As point 3), I think.
(5) When building FLTK, one needs to manually specify
-DCMAKE_BUILD_TYPE=Release if one wants optimized code. Either the FLTK
CMakeLists.txt needs to be modified to make CMAKE_BUILD_TYPE=Release the
default, or it needs to be documented in TigerVNC's BUILDING.txt that
adding this variable is necessary to produce optimized code.
Fixed.
(6) The TigerVNC build will fail unless I patch TigerVNC's
CMakeLists.txt as follows:
--- CMakeLists.txt (revision 5021)
+++ CMakeLists.txt (working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
distribution vendors will run into this problem, since they'll probably
want to use the system libpng. Since the patch above does no harm when
using FLTK's internal PNG library, I would suggest going ahead and
applying it to TigerVNC.
Shouldn't this go into vncviewer/CMakeLists.txt instead?
(7) Building FLTK using MinGW is problematic because of the dependency
on the libgcc and libstdc++ DLL's. These dependencies are automatically
taken care of in the TigerVNC build system, but the FLTK build system
doesn't have that same code. It's particularly a problem with MinGW64,
since those DLLs aren't in the PATH, and thus the build will actually
fail because it's trying to run a test program that it just built. It's
problematic in general because, if FLTK depends on libgcc and libstdc++,
so will the TigerVNC executable, which makes packaging it difficult.
This was one reason why it was advantageous to build FLTK in the
TigerVNC tree (it took on the build properties of the rest of the
TigerVNC code.) The only way I was able to hack around the issue was by
copying the BUILD_STATIC code from the TigerVNC CMakeLists.txt file into
the FLTK CMakeLists.txt file. Yuck.
Yes, this is somewhat problematic, but as you point out, this is really a
problem with FLTK rather than TigerVNC.
(8) You are using ImageMagick to generate tigervnc.png. Of course
ImageMagick is not available on Windows, so the Windows build fails. I
mean, seriously, check the PNG files into SVN. They're all of, what, 2
kilobytes?!
I have no objections to checking in the PNG files, but is this really
enough? Have you tried running the build with the PNG files already in
place? My guess is that CMake and the make files will still look for
convert etc and fail if it's not available. We would probably need some
kind of logic that only looks for convert if the PNG files needs remake.
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone: +46-13-214600http://plus.google.com/112509906846170010689--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net
[Tigervnc-devel] Migration to Allura
Hi. As you perhaps know, Sourceforge is introducing a new platform called Allura. Old projects can quite easily migrate. There are several advantages of doing so: * SF want projects to migrate, and they are not working on the old framework any longer. Support cases are often closed with wont fix. * The new interface is nicer and should be easier to use. More details about Allura can be found here: https://sourceforge.net/p/allura/wiki/Features/ I think we should proceed with the migration to Allura, but if anyone objects, please say so. If there are no objections, I will do the migration 2012-11-29. Please note that the SVN URL will be changed. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Migration to Allura
Oh, 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 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 option before the new SF platform is released. I migrated libjpeg-turbo and have regretted it, because I use the online repo browser enough that not having a fully functional one has been an impediment. On Nov 21, 2012, at 3:45 AM, Peter Åstrand astr...@cendio.se wrote: Hi. As you perhaps know, Sourceforge is introducing a new platform called Allura. Old projects can quite easily migrate. There are several advantages of doing so: * SF want projects to migrate, and they are not working on the old framework any longer. Support cases are often closed with wont fix. * The new interface is nicer and should be easier to use. More details about Allura can be found here: https://sourceforge.net/p/allura/wiki/Features/ I think we should proceed with the migration to Allura, but if anyone objects, please say so. If there are no objections, I will do the migration 2012-11-29. Please note that the SVN URL will be changed. Rgds, --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4950] trunk/vncviewer
On Wed, 8 Aug 2012, Brian Hinz wrote: Hi Peter, I haven't tried this yet, but unless I've missed something, won't it cause the values of the global parameters to be changed when a config file is loaded? Without a rollback mechanism, if the user then cancels the options dialog those changes will still go into effect. I don't think that's the behavior that most people would expect. Loading is not done with the options dialog open, but from the main window. Thus, you cannot cancel a load once it is done. The options are then saved as default options when you click on Connect. FWIW, I've been working on adding this functionality to the java viewer and used an instance of an rfb::Configuration object to hold temporary values of the parameters. That way, all of the changes made in the dialog don't get committed until the dialog is OK'd. The global config and options config are sync'd up via the assignment operator defined in rfb::Configuration when the dialog is opened (options = global) and when the changes are OK'd (global = options). This has required a little more rework than I would have liked, but that was mainly due to the fact that many of the get/set methods in rfb::Configuration are implicitly linked to the global config. This approach may not be better, I'm just tossing it out as another idea. Perhaps it would be good if you try the native client implementation first, to see how it works. You can get a Windows binary here: http://www.cendio.com/~astrand/tigervnc/tmp/ Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Default to use -gstabs2?
In order to build vncviewer with debug information, I was adding -DCMAKE_BUILD_TYPE=DEBUG as a cmake argument. However, this is not enough to produce debug information that Dr Mingw can understand. I had to replace -g with -gstabs2 in ./vncviewer/CMakeFiles/vncviewer.dir/link.txt and ./vncviewer/CMakeFiles/vncviewer.dir/flags.make. How can this be avoided; can we have -gstabs2 as default on Windows? --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [ tigervnc-Bug Tracker-3531487 ] Double buffering doesn't work properly in new viewer
On Mon, 4 Jun 2012, DRC wrote: At minimum, I think you need to add a double buffering parameter which, when enabled, will cause the viewer to strictly wait until the end of the framebuffer update before repainting. We're not just talking about tearing. We're taking about ugly black rectangles that appear in the middle of the video or the 3D scene as it is animating. Regardless, though, the point is that the FLTK viewer cannot claim to support double buffering at the moment. It would be very easy to make it do so (a new parameter and a one-line code change.) Personally, I think the new parameter should be enabled by default, but if history is any indication, you're likely to disagree. 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. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH:tigervnc-trunk] Make fb header transformations work with Xorg 1.12.1
I can give you commit access. What is your SF account name? acoopersmith (had to go look it up it's been a while) Welcome aboard! Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH:tigervnc-trunk] Make fb header transformations work with Xorg 1.12.1
On Tue, 1 May 2012, Alan Coopersmith wrote: Btw, would you like commit rights? I'd say you have enough street cred for that not to be an issue. :) I'm not actively developing on TigerVNC, mostly just noticing problems when we integrate new versions of either Xorg or TigerVNC to the Solaris packages, so I won't have a lot to commit, but if you'd like to give me commit access, I'll promise to behave.I assume you still like to see changes reviewed on the list before committing. I can give you commit access. What is your SF account name? Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] automatic lossless refresh: introduce lossy region tracking for smaller automatic updates.
;
+ lossy_tracker-getUpdateInfo(ui, Region(Rect(0, 0, 1, 1)));
+ if (!ui.is_empty()) {
+std::vectorRect rects;
+std::vectorRect::const_iterator i;
+ui.changed.get_rects(rects);
+for (i = rects.begin(); i != rects.end(); i++) {
+ updates.add_changed(*i);
+}
+ }
-// Reset to previous compression settings
-cp.qualityLevel = q;
-cp.fineQualityLevel = fq;
-cp.subsampling = subsampling;
-cp.noJpeg = noJpeg;
+ writeFramebufferUpdate();
+ refreshTimer.stop();
+ lossy_tracker-clear();
+
+ // Reset to previous compression settings
+ cp.qualityLevel = q;
+ cp.fineQualityLevel = fq;
+ cp.subsampling = subsampling;
+ cp.noJpeg = noJpeg;
}
diff --git a/common/rfb/tightEncode.h b/common/rfb/tightEncode.h
index 446d45e..5c46879 100644
--- 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);
+ lossy_tracker.add_changed(Region(r));
break;
}
#endif
ENCODE_FULLCOLOR_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
break;
case 1:
// Solid rectangle
ENCODE_SOLID_RECT(pixels, os);
+lossy_tracker.subtract(Region(r));
break;
case 2:
// Two-color rectangle
ENCODE_MONO_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
break;
#if (BPP != 8)
default:
// Up to 256 different colors
ENCODE_INDEXED_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
#endif
}
}
--
1.7.9.2
--
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.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00--
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.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
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 special script turbovncserver, vglvncserver or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick dirty benchmarks. We need something more quantifiable. I think we have provided quantifiable data. I agree that additional tests would be useful though, but there are also other things that needs attention. I think the core of the problem is there will always be some kind of tradeoff/compromise, and if I understand the VirtualGL/TurboVNC perspective correctly, there's no interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. This is why I'm suggesting a wrapper script. Assuming that you will no longer ship the file /opt/TurboVNC/bin/vncserver, users will need to learn another path/command in any case. I don't think 3D users will find it more difficult to learn to run, say, /opt/TigerVNC/bin/vncserver-vgl than /opt/TigerVNC/bin/vncserver, at least not much more difficult. Btw, wrt the latency work, we have done extensive testing, and it turns out that Pierres work gives a huge improvement. Common usage cases such as writing text in OpenOffice is now much faster on high latency links. The typing lag is basically gone. I don't know about that-- I certainly still see a lag when typing (I mean, latency is still latency, and the time between typing a character on the screen and seeing it on your client is still equal to RTT), but the extensions have definitely eliminated the latency-dependent update rate cap. The extensions allow you to now type ahead of the latency, which makes it less apparent, but I can still feel it on a 200 ms connection. Of course you can never get rid of the RTT latency; that's why I said basically gone. What is the status of getting the extensions officially adopted as part of the RFB spec? As far as I can tell, all extensions have official numbers. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] 2D vs 3D performance
On Wed, 28 Dec 2011, DRC wrote: interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. Not difficult at all. We have a solution that fits both use cases by default: it's the same solution we used with 1.1.0 and are now using with 1.2 beta1, which is setting DeferUpdate to 1 ms. You and Pierre have not provided any test cases which demonstrate that 10 ms is beneficial, and Pierre admitted that the choice of that value was more of a gut instinct, which is why we changed it back until further information can be gathered. Pierre and I have reached at least a temporary agreement regarding this, so I'm not sure what you hope to gain by continuing to argue the point. 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 the -DeferUpdate problem, but as long as the VirtualGL/TurboVNC standpoint is no compromise at all, any CPU increase is a no-no etc, there will be tons of issues on which we cannot find solutions that are optimal for both cases. Without room for compromises and tradeoffs, it's an impossible goal. Having a special script for the ultimate-performance-on-LAN-case would be an easy solution. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] 2D vs 3D performance
On Wed, 28 Dec 2011, DRC wrote: If we start getting into such esoteric stuff as having separate launcher scripts, then why wouldn't I just create a completely different build procedure that gives me all the defaults I want? I don't understand why you think a two-line script is esoteric. The advantage of having two launch scripts instead of a customized build procedure is that only one type of binares are necessary. This also means that you can run multiple Xvnc instances with settings optimal for 2D and 3D at the same time, on the same server. Different users might use different applications or might be on different networks with different performance. Or better yet, why wouldn't I just fork the project so I wouldn't have to deal with your grief anymore? You must answer that question yourself. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On Wed, 21 Dec 2011, DRC wrote: We are currently based on TigerVNC revision 4816, but we might make a new code drop if we find any major bugs. Cool. This is very good info. AFAIC, we could enter beta with the project as well, and probably should so we can leverage your bug squashing. It would be nice to get out some official project builds that contain the performance improvements. Sounds good. Note however that we will likely have a short beta period, since we are aiming for a stable ThinLinc release before the end of the year. I would still like to see a quantifiable test case that demonstrates the efficacy of setting the deferred update timer to 10 ms. Barring that, if you're insistent that 10 is what you want as a default, I would like to modify the build system such that that value can be tweaked using a #define or something like that, so my builds can use 1 ms as the default. It's pretty easy to tell people if you want TurboVNC-like performance, set the compress level to 1, but telling them that they also have to remember to add -DeferUpdate=1 every time they launch vncserver makes things difficult. 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 special script turbovncserver, vglvncserver or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Btw, wrt the latency work, we have done extensive testing, and it turns out that Pierres work gives a huge improvement. Common usage cases such as writing text in OpenOffice is now much faster on high latency links. The typing lag is basically gone. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Can we *please* revisit the reply policy on this list?
On Fri, 2 Dec 2011, Adam Tkac wrote: On Wed, Nov 30, 2011 at 05:43:44PM -0600, DRC wrote: When we created this project a couple of years ago, it was decided (I was outvoted) that mailing list replies would go to the user rather than the list, but we are losing a lot of information this way. People will typically hit Reply rather than Reply All, and their response will go only 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? I don't remember if we discussed this but you have my vote, all replies should go to ML by default. Fixed now. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance
On Wed, 16 Nov 2011, DRC wrote: We could, but we generally would like not to. We prefer if our goals align with the upstream projects we use. There is less friction when it comes to long term plans that way, and having our users running basically the same product as the project's users benefits both when it comes to finding and fixing bugs. I'm trying hard not to laugh. Let's be realistic-- besides Cendio, Brian and I are the only ones doing any significant development in recent months. Thus, I'm not sure we really have an upstream project here. You are too pessimistic. TigerVNC is a nice project, and we are making great progress. We have always had a hope that TigerVNC could replace TurboVNC, but not necessarily out-of-box. If we cannot make the system clever enough to work for everyone, then it is the niche users (like high performance 3D) that will have to tweak things. The average joes should just be able to install and run. This tweaking could of course be handled by custom packing, like TigerVNC - VirtualGL Edition or such. We could also look at having the vncserver script do some magic like seeing if VirtualGL is configured on the machine. My goals are a direct out-of-box replacement for TurboVNC. I would hope we can come to a solution that achieves that goal while still maintaining the goal of making TigerVNC a general-purpose VNC solution. As you said, the goal is to have a general-purpose VNC solution which can be as fast as TurboVNC, thus replacing that project. It may not be possible that the defaults are optimal for all scenarios ie common office applications vs 3D apps, but we should be able to handle this. It might be difficult to argue about which type of users are most common. However, the fact that the high performance 3D case requires the VirtualGL software gives us a technical possibility to distinguish the 2 cases. There are various ideas how this could be done: * We could provide a script /opt/TurboVNC/bin/vncserver that launches TigerVNC with defaults suitable for the 3D case. * We could include a script vglvncserver. * We could modify the normal vncserver script to detect if VirtualGL is installed and/or configured, and in that case use suitable default settings. Could something like this be acceptable to you? Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance
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 Nice work! If Cendio wants the CUT always enabled for their product, then that is easily accomplished by modifying the vncserver startup script, which I assume is something they already do. I do not think that enabling it by Actually, we are not using the vncserver startup script at all. The ThinLinc session manager executes Xvnc directly. Of course it is still possible for us to have different defaults than the upstream TigerVNC, even though we generally tries to avoid this. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] WinVNC, Visual C++, etc.
On Mon, 7 Nov 2011, DRC wrote: I'm not in a good position to own the WinVNC portion of the code, and unless someone else steps forward to own it in the long term, I'd rather we just abandon it as opposed to pretending it works. Right now, it seems like we're maintaining the build only because we hope to attract someone to work on it. Well, it works on XP, which is my favourite Windows version :-) (I was actually able to buy a brand new laptop with XP this autumn, and I have recently upgraded my HTPC from Vista to XP as well.) As you pointed out, the modifications required to make it work on modern Windows platforms are fairly extensive. I think the best approach would be to migrate W7 support from TightVNC, but someone needs to do the work, and I'm not very interested in this either. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
Ok to commit? If so, this means that we will start building WinVNC (and vncconfig.exe) during our automatic nightly builds. I've committed the patch with minor modifications (changing TightVNC Team to TigerVNC Team, expanding the description text in CMakeLists.txt, and including MSVC in the platform checks-- necessary Very nice! I've verified that it works on our end as well. There are still some things that don't work with MinGW WinVNC-- Java integration doesn't yet work, and the build fails when BUILD_STATIC=1 (due to the build system trying to pass -static-gcc to windres.) I'll look into both of those issues. Thanks. Regarding moving WinVNC into a sub-build, we are leaning toward not using TigerVNC WinVNC for my customer's project for various reasons, and if that decision becomes final, then I will no longer object to removing Visual Studio support from TigerVNC entirely. I'll keep you posted. It Good. Note that I think it would be a good idea for Cendio to also get a MinGW64 build going in addition to your MinGW builds, since there are subtle but distinct differences caused by the differing GCC versions in those two platforms, not to mention 64-bit issues that sometimes pop up when the code is modified. I agree, this is important. We are currently not doing 64 bit builds every night, but I know that Pierre is doing such builds when he is developing vncviewer. Our 64-bit Windows environment is based on MinGW64. Eventually we will build 64 bit Windows builds nightly as well. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
On Mon, 10 Oct 2011, Peter Åstrand wrote: I mentioned it several times on the list, in the context of our discussions regarding moving to CMake for Windows, regarding the autotools performance problem on Windows, etc. I've done a gmane search for libuuid on the tigervnc-devel list. No matches, except for this thread, and an email I wrote myself about another thing. ... Why don't you try building it on a recent version of MinGW64 (it's probably reproducible using MinGW64 for Linux) and see for yourself? We do not have a MinGW64 installation at hand, but I'll put this on my TODO list. ... We can start with making sure WinVNC works with MinGW. If you have no objections, I'd like to commit the patch. I have strong objections, since the patch breaks MinGW64. We have tried MinGW64 now. It is correct that it has a broken IActiveDesktop implementation: It defines CLSID_ActiveDesktop in the headers, but not in the lib. I have updated the patch so that it handles this case as well. This could be done quite easily. Ok to commit? If so, this means that we will start building WinVNC (and vncconfig.exe) during our automatic nightly builds. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00Index: common/os/os.h === --- common/os/os.h (revision 23178) +++ common/os/os.h (arbetskopia) @@ -23,6 +23,8 @@ #include config.h #endif +#include os/w32tiger.h + /* * Get VNC home directory ($HOME/.vnc or %APPDATA%/vnc/). * If HOME environment variable is set then it is used. Index: common/os/w32tiger.c === --- common/os/w32tiger.c(revision 0) +++ common/os/w32tiger.c(revision 0) @@ -0,0 +1,33 @@ +/* Copyright (C) 2011 TightVNC Team. All Rights Reserved. + * + * This is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This software is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this software; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, + * USA. + */ + +#ifdef HAVE_CONFIG_H +#include config.h +#endif + +#ifdef WIN32 + +#define INITGUID +#include basetyps.h + +#ifndef HAVE_ACTIVE_DESKTOP_L +DEFINE_GUID(CLSID_ActiveDesktop,0x75048700L,0xEF1F,0x11D0,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); +DEFINE_GUID(IID_IActiveDesktop,0xF490EB00L,0x1240,0x11D1,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); +#endif + +#endif /* WIN32 */ Index: common/os/w32tiger.h === --- common/os/w32tiger.h(revision 0) +++ common/os/w32tiger.h(revision 0) @@ -0,0 +1,182 @@ +/* Copyright (C) 2011 TightVNC Team. All Rights Reserved. + * + * This is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This software is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this software; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, + * USA. + */ + +#ifndef OS_W32TIGER_H +#define OS_W32TIGER_H + +#ifdef WIN32 + +#include windows.h +#include wininet.h +#include shlobj.h +#include shlguid.h +#include wininet.h + + +/* MSLLHOOKSTRUCT structure*/ +#ifndef LLMHF_INJECTED +#define LLMHF_INJECTED 0x0001 +#endif + + +/* IActiveDesktop. As of 2011-10-12, MinGW does not define + IActiveDesktop in any way (see tracker 2877129), while MinGW64 is + broken: has the headers but not the lib symbols. */ +#ifndef HAVE_ACTIVE_DESKTOP_H +extern const GUID CLSID_ActiveDesktop; +extern const GUID IID_IActiveDesktop; + +/* IActiveDesktop::AddUrl */ +#define ADDURL_SILENT 0x0001 + +/* IActiveDesktop::AddDesktopItemWithUI */ +#define DTI_ADDUI_DEFAULT 0x +#define DTI_ADDUI_DISPSUBWIZARD0x0001 +#define DTI_ADDUI_POSITIONITEM 0x0002 + +/* IActiveDesktop::ModifyDesktopItem */ +#define COMP_ELEM_TYPE 0x0001
Re: [Tigervnc-devel] Visual Studio or not
. Having to try every simple change with two different toolchains is worse. It's actually quite simple to do if you have a real Windows machine. However, since you don't, that is why I proposed a compromise. We have many Windows machines. Still we think it's a bad idea to require one to be able to develop. Enterprise-quality software is not built by hacking. Enterprise means different things to different people. Very often it is not a positive thing. Take a look at http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx (or search for other Enterprise articles) and you'll see what I mean. http://www.cendio.com/products/thinlinc/ Cendio is an enterprise software company offering a Terminal Server solution to enable Server Based Computing. You need to be able to adapt your language to the audience. Many decision makers likes to hear the E word, and they do not object to sales persons wearing tuxedos. But if one developer tried to convince me of a certain toolchain by dressing up, well, that would have the opposite effect on me... :-) So in the open source meritocracy, enterprise may very well be a bad thing and hacking something positive. In this context, it's easier to impress somebody by, say, showing a Linux kernel commit, rather mentioning that one have worked for a Fortune 500 company. For me, it doesn't have *anything* to do with feeling uncomfortable. It's about selecting one toolchain that does the work; supports all of our platforms. If Visual Studio could run under Linux and generate binaries for Linux, Solaris, OS X etc, then we could discuss getting rid of MinGW. But that won't happen. Peter, it *doesn't* do the work, not without lots of *hacking*. We think differently. The fact that you would even recommend building *Mac* software on a *Linux* platform proves my point. Who does that? Certainly no one building Mac software professionally. If you look at the embedded world (including mobile devices with Symbian and Android), cross compiling is the standard approach; typically the only supported configuration. If you think of it, every professional Mac software vendor which builds fat binaries (ie containing both PPC and x86 code) are also cross compiling. So this principle is in no way strange or unprofessional. Sure, the exact combination of building OS X binaries on Linux might not be as widespread, even though there are many great tutorials about it on the net. But it's still a very powerful and professional approach. We are using GCC as well as Apples headers libs, so this build environment is not that different from that on a native Mac. So basically, what you're saying is that everyone who wants to work on our code needs to have a Linux machine? No, this is not what I am saying. Most people who develop Windows code use a Windows machine, and most people who develop Mac code use a Mac machine. We need to support those people. This is not just Cendio's baby. Of course not. That's why MinGW is so great, because it runs so well on both Windows and Linux. For Mac, Apple ships GCC, so developers can choose if they want to cross compile on Linux (or any platform), or build natively. We do not want to exclude anybody. My assumption is that Cendio isn't going to ever do the right thing and set up a Windows machine for dev testing, so the compromise is that you guys keep doing what you've always done, but since you're not going to test VStudio, I want to minimize the damage potential by minimizing the code that is built with VStudio. Thus, I move WinVNC into a sub-build, and that way, most of the stuff you work on regularly, such as FLTK, doesn't need to be supported on VStudio any longer. This sounds good. If I understand you correctly, this is certainly a step in the direction we want. Please post a suggested patch. We can start with making sure WinVNC works with MinGW. If you have no objections, I'd like to commit the patch. I have strong objections, since the patch breaks MinGW64. I'd like to resolve that problem. If you can provide us with details, that would be great. Otherwise, I'll try to look at the problem myself. Why are you so focused on this, Peter? I didn't think Cendio cared about WinVNC. We care about the entire TigerVNC project. WinVNC is an important component for more widespread use of TigerVNC. I regret that we do not have any resources to work on it, but we appreciate any contribution. Also, the issue of which toolchain(s) should be supported is of course a very important question that affects the entire project. I think it's important to take some time to discuss this. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your
Re: [Tigervnc-devel] Visual Studio or not
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 patch apparently worked fine for Adam and it worked fine for us. Well, curiously, apparently that patch made it into MinGW64, and I just tried again with that compiler-- same result. Compiles but does not link, because the stub is not in libuuid. Never heard of such a problem. Can you please give us the technical details? Which missing symbol, which error message... That was why we, as a team, decided it was necessary to continue supporting Visual Studio. This is not what I remember. I thought we just waited for MinGW to accept the patch. Interestingly, your new patch to libos does work with MinGW32, but now it interferes with the broken patch in MinGW64. How does it interfere? Please give us the technical details. Do you see where this is going? No. For every piece of Win32 functionality I need that isn't supported in MinGW, now I'm faced with MinGW contains most of the Win32 functionality one needs. Especially if you want to keep supporting older versions of Windows, which I suppose we want. We don't want a WinVNC or vncviewer which only works on Windows 7+. I thought you had the same goals, since you have been working on supporting platforms such as RHEL4? (a) reverse-engineering a stub for it Writing a short text file using the MSDN documentation is hardly reverse-engineering. (b) writing a CMake compile and link test to verify that it isn't in MinGW What's the problem? Writing CMake (or Autotool) tests is the standard approach when using functionality that is not guaranteed to work on all platforms. This is the approach we are using for UNIX as well, remember. and, if so, that the MinGW version isn't broken, This is seldom. The MS compilers also has bugs. and (c) conditionally using either the MinGW version of the header (if it exists) or our header and conditionally linking the MinGW version (if it exists) or our version. No, we should either use both header lib from MinGW, or our internal implementation. That isn't exactly an efficient development model. Having to try every simple change with two different toolchains is worse. You need to understand that my lack of comfort with MinGW is dictated by the somewhat hackish approach necessary to get stuff like the above to work. I think you consider it as being hackish just because you have little experience with it. Enterprise-quality software is not built by hacking. Enterprise means different things to different people. Very often it is not a positive thing. Take a look at http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx (or search for other Enterprise articles) and you'll see what I mean. I also understand your lack of comfort with Visual Studio. You haven't used it continuously for 15 years like I have. I'm not saying that you're wrong-headed for being uncomfortable with Visual Studio, but neither should you say I'm wrong-headed for being uncomfortable with MinGW. For me, it doesn't have *anything* to do with feeling uncomfortable. It's about selecting one toolchain that does the work; supports all of our platforms. If Visual Studio could run under Linux and generate binaries for Linux, Solaris, OS X etc, then we could discuss getting rid of MinGW. But that won't happen. Comfort level is very important when developing something. I don't want to feel like I have to patch libos every time I use something that MinGW doesn't have, and I don't want to have to maintain build tests for any advanced functionality to determine whether or not it's present or broken in MinGW. I feel like I've been more than reasonable and willing to compromise about this. As the one who's going to be developing WinVNC, I need to feel like I'm free to do what I need to do to make it work for my customer, and I am not comfortable using MinGW for WinVNC at this time. Ok. You don't want to change your habits, but you want to force us to test build with Visual Studio before every commit? How is this a compromise? All the extra work would be on us not currently using Visual Studio. Once things are working properly on W7 and Vista, then we can re-evaluate. We can start with making sure WinVNC works with MinGW. If you have no objections, I'd like to commit the patch. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more
Re: [Tigervnc-devel] Visual Studio or not
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 projects such as VLC. I'm not sure if you know about it, but VLC is a long-time open-source favorite, typically considered one of the best media players, and have had 36,900,001 downloads on cnet.com alone. Calling MinGW esoteric is just plain wrong. You are mixing your metaphors, Peter. Most people who use MinGW use it on an actual Windows machine, which is different from using it on a Linux machine. It doesn't matter if most people are using it on Linux or not. The point is that highly successful projects such as VLC *are* using it on Linux, so we are certainly not alone. We already encountered one problem caused by this difference-- the fact that autotools on Windows was unusably slow and, prior to implementing a CMake-based build system for Windows, there was no reasonable way to build our code on an actual Windows machine. I'm But now when we have migrated to CMake, this is no longer an argument. not asking you to change the way you build things. If you want to use MinGW, then that's fine. If we didn't need Visual Studio for certain functionality, I'd be fine with not supporting it at all for this project, but as long as it's needed to get full functionality, then the Remind me, which functionality is missing if you build without Visual Studio? primary project developers need to at least sanity check it. This most recent breakage went weeks before I was able to get around to building on Windows and discovering the issue, then I wasted an hour figuring out what was wrong. I'm not asking you to do anything that I don't also do myself. It seems to me that instead of wasting time on maintaining multiple tool chain, you could invest that time in streamlining the GCC based one. I think we should stop using Visual Studio. From the start my position has been that multiple tool chains will mean trouble. I accepted that approach however since I understood that you wanted it that way, but since you are now telling us that you are unhappy with the current situation, perhaps it's time to through Visual Studio out. Forcing everybody to use Visual Studio is not an option. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
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. 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 be able to include the missing definitions in the TigerVNC code base. This is about to become even more of a problem, because I'm being contracted by another company to improve WinVNC so that it can be used on Vista and W7, and that may yet require the use of more APIs that aren't supported in MinGW. It has nothing to do with streamlining. It has to do with the fact that MinGW will always be playing catch up with Microsoft, and some of the Microsoft API's can't be included because of IP concerns. Thus, there will always be certain functionality that can't be leveraged through the MinGW toolchain. It It can, it's just a matter of fixing a few missing stubs. It's not that difficult, and it's a better investment of time than the never-ending maintenance of having two toolchains. The basic facts of this case are the same as they were 2 years ago: we cannot abandon Visual Studio without abandoning WinVNC, We can. Besides, let's back up a minute-- the modification that broke the Visual Studio build was in FLTK. The FLTK Project supports Visual Studio as one of their build chains, so someone was going to have to fix the build eventually in order for it to be accepted upstream. I assume that upstream acceptance is the ultimate goal for these FLTK patches. Correct. Thus, I believe that it is quite reasonable to expect that whoever is developing the FLTK patches test them on the compilers that the FLTK Project supports. You can never test everything. You need to prioritize. From a TigerVNC perspective, if we could get rid of Visual Studio, we would no longer have to test every commit with that toolchain. That would be big win. When it comes to FLTK patches, we only need to do the minimum amount of work to get the patches accepted upstream. If we are lucky, others will fix up problems later. FLTK actually supports many toolchains, both MinGW- and Cygwin, both VS 2008 and VS 2010 etc. I doubt that a typical patch contributor tests all combinations. In any case, the FLTK patches are small compared to the entire TigerVNC code base. So in any case, it would be a big win if we do not need to test with two toolchains. Every minute you guys spend arguing with me is a minute less that I have to spend on optimizing the VNC Viewer or doing other things that are supposed to be a priority, so I'll let you decide whether it's worth it to continue this discussion. Having to always check the build with MSVC prior to committing, ie test build with two different toolchains, will also require a lot of time, forever. We do not believe that this is an efficient way of working. Here's an offer: If we fix so that WinVNC can be built with a standard MinGW distribution, can we then remove support for Visual Studio? Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
On Thu, 6 Oct 2011, DRC wrote: IMHO, this is not unsolvable. If MinGW still refuses to add support for this, we should be able to include the missing definitions in the TigerVNC code base. It's not just missing definitions. The patch you guys tried to commit upstream didn't work, because it did not include support for IActiveDesktop in the actual link libraries. AFAIK, including such support would require back-engineering the Windows libs, which is why MinGW rejected the idea. It seems that you have misunderstood how build time linking of Windows binaries works. You don't actually need the full library; only a stub. This stub can be generated with dlltool, typically from a .def file. In the case of the ActiveDesktop constants though, you also need to have a small .c file containing 2 rows of DEFINE_GUID. MinGW hasn't yet accepted the patch because one single constant (IID_IActiveDesktop ) cannot be found in the registry or the MS documentation on MSDN. Instead, a binary was used to retrieve the value. They haven't used that approach before. (The constant can now also be found on http://social.msdn.microsoft.com.) Here's an offer: If we fix so that WinVNC can be built with a standard MinGW distribution, can we then remove support for Visual Studio? Assuming you could fix WinVNC in its current incarnation, my main concern would still be that you would be painting me into a corner, whereby I couldn't use any other advanced functionality if I needed it in the future. Plus, I think it's probably a moot point, because I'm doubtful that anyone can make WinVNC work with MinGW, even in its current incarnation. Could you please stop saying that things are close to impossible without even trying? Attached is a patch that adds the missing definitions to the internal libos, if necessary. With this patch, building WinVNC with MinGW seems to work fine. If you would need any advanced functionality in the future, you can just add the missing constants and/or stubs, just as I did. This is typically very straight forward. We have been using MinGW for almost 10 years, and with the exception of this ActiveDesktop COM stuff, we haven't had much problems. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00Index: common/os/os.h === --- common/os/os.h (revision 23140) +++ common/os/os.h (arbetskopia) @@ -23,6 +23,8 @@ #include config.h #endif +#include os/w32tiger.h + /* * Get VNC home directory ($HOME/.vnc or %APPDATA%/vnc/). * If HOME environment variable is set then it is used. Index: common/os/w32tiger.c === --- common/os/w32tiger.c(revision 0) +++ common/os/w32tiger.c(revision 0) @@ -0,0 +1,34 @@ +/* Copyright (C) 2011 TightVNC Team. All Rights Reserved. + * + * This is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This software is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this software; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, + * USA. + */ + +#ifdef HAVE_CONFIG_H +#include config.h +#endif + +#ifdef WIN32 + +#define INITGUID +#include basetyps.h +#include shlguid.h + +#ifndef HAVE_ACTIVE_DESKTOP +DEFINE_GUID(CLSID_ActiveDesktop,0x75048700L,0xEF1F,0x11D0,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); +DEFINE_GUID(IID_IActiveDesktop,0xF490EB00L,0x1240,0x11D1,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); +#endif + +#endif /* WIN32 */ Index: common/os/w32tiger.h === --- common/os/w32tiger.h(revision 0) +++ common/os/w32tiger.h(revision 0) @@ -0,0 +1,180 @@ +/* Copyright (C) 2011 TightVNC Team. All Rights Reserved. + * + * This is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This software is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4689] trunk/common/fltk
On Tue, 4 Oct 2011, dcomman...@users.sourceforge.net wrote: Re-commit MSVC build fixes, which were forcibly removed by 4675. Please (a) bring these upstream so they don't get deleted again, Can you submit them to: http://www.fltk.org/site/str.php?U+P0+S-2+C0+I0+E0+Q ? and (b) always check the build with MSVC prior to committing modifications to any libraries that affect that build. Unfortunately, we have no easy way of building with MSVC. To be honest, we are avoiding it like the plague :-) I guess this situation where the MSVC build will occasionally go broken is the price we have to pay for supporting two toolchains. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4689] trunk/common/fltk
On Tue, 4 Oct 2011, DRC 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 projects such as VLC. I'm not sure if you know about it, but VLC is a long-time open-source favorite, typically considered one of the best media players, and have had 36,900,001 downloads on cnet.com alone. Calling MinGW esoteric is just plain wrong. though, we're all in the dark regarding what Cendio is doing with the code. It would be helpful to at least have some communication regarding upcoming ThinLinc releases, so we know generally what snapshot of the code that Cendio is testing/stabilizing. We are always using the trunk version. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Drop old viewers?
DRC wrote: 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 I agree. Let's remove old viewers from trunk. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Moving to the wiki
On Mon, 26 Sep 2011, DRC wrote: 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 admins could switch over to have it as our primary web page. Cool! Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Multithreaded ComparingUpdateTracker
On Thu, 1 Sep 2011, Pierre Ossman wrote: Have you done any research to validate the usefulness of the ComparingUpdateTracker? Personally, I found that, in Xvnc, it wasn't catching very many duplicate updates, and the dupes it was catching would not have significantly slowed down performance (they tended to be areas of solid color, which the Tight encoder already optimizes out.) The CUT might be beneficial in cases where an ill-behaved app draws the same frame over and over again, but that is a corner case, not the norm. We've seen issues in the past where the update tracker has solved things. It has always been crappy applications that keep redrawing the same thing over and over again. If memory serves me, Java was a bad offender here. Peter, do you remember any details? We have seen that VNC is a great improvement over X11 with Java applications, but I'm not sure if we have verified if the ComparingUpdateTracker is causing the improvement or not. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Support more menu keys
On Tue, 30 Aug 2011, DRC wrote: On 8/30/11 5:33 AM, Pierre Ossman wrote: You seem to be providing good stufftm, so I'd vote for you getting commit rights. Adam? DRC? Any objections? No objections here-- just standard rules for everyone: before committing any potentially disruptive new features, always discuss with the list first. I can add you as a member. What is your SF account name? Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4646] trunk/vncviewer
. */ +#ifdef HAVE_CONFIG_H +#include config.h +#endif + #include parameters.h using namespace rfb; Modified: trunk/vncviewer/vncviewer.cxx === --- trunk/vncviewer/vncviewer.cxx 2011-08-22 11:38:35 UTC (rev 4645) +++ trunk/vncviewer/vncviewer.cxx 2011-08-23 12:04:46 UTC (rev 4646) @@ -18,6 +18,10 @@ * USA. */ +#ifdef HAVE_CONFIG_H +#include config.h +#endif + #include string.h #include stdio.h #include stdlib.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-commits mailing list tigervnc-comm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-commits -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Testing with the 1.2 Alpha version
On Thu, 21 Jul 2011, DRC wrote: On 7/21/11 1:24 AM, Peter Åstrand wrote: There's a state at the server and a state at the client. When you say numlock is pressed, I assume that you mean that numlock is active at the client side? This will typically produce keysyms such as KP_1, which will sent over VNC. But in the Xvnc session, numlock is typically still off. This approach is what I recommend. But having numlock active in the Xvnc session may cause strange effects such as the one you are describing. I guess the thing I'm curious about is: why did it work before on some platforms? Based on Robert's original message, I infer that it worked with, for instance, the TigerVNC 1.1 Viewer for Windows connecting to the TigerVNC 1.1 Server. I am also wondering. Could it be that the version of Xorg that you have been using to build your binaries automatically starts up with numlock enabled on the server side? We are still building Xvnc binaries with XOrg server 1.5.3, and we are not seeing this. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Testing with the 1.2 Alpha version
On Tue, 19 Jul 2011, Robert Goley wrote: The second issue is with the numpad keys. I had seen this issue previously only with a linux viewer connecting from 1 ubuntu machine to the server running Debian with DRC's Xvnc binary. It now seems to happen with the FLTK viewer on all platforms. By default, the numlock is on both on the local workstation and in the VNC session. This is somewhat strange. I've never seen that Xvnc starts up with numlock enabled. Can you verify if this happens even if you start something basic such as an xterm? My guess is that the Ubuntu desktop or something similar activates numlock. Since the VNC protocol lacks numlock sync, I recommend that you have numlock off in the Xvnc session. If you fail to locate what's activating numlock, you might want to try to removing Num_Lock from the xmodmap modifier map (ie xmodmap -e remove mod2 = Num_Lock). There's also a numlockx utility. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Run-time copyright acknowledgments
On Fri, 24 Jun 2011, DRC wrote: Currently, whenever you launch Xvnc or the legacy Unix or new FLTK viewers, they print an outdated copyright acknowledgment: Copyright (C) 2002-2005 RealVNC Ltd. Copyright (C) 2000-2006 TightVNC Group Copyright (C) 2004-2009 Peter Astrand for Cendio AB This needs to be changed or updated. The problem is that the actual copyright history is about a mile long (see the new README.txt I just added in the top-level source directory.) Thus, I think we really need to replace the run-time copyright message with something more generic. It's been the convention of the Windows viewer and server for a while to say: Copyright (C) 1999-2011 [many holders] That seems somewhat unsatisfying to me, but I can't come up with anything better. I guess we could print something as: Copyright (C) 2002-2005 RealVNC Ltd. Copyright (C) 2000-2006 TightVNC Group Copyright (C) 2004-2011 The TigerVNC Team But many holders is also OK with me. Just trying to eliminate the need to maintain a list of the copyrights in multiple places. I question whether it's even important to maintain that list in the README files, since it's likely to get out of date as well. If people really want to know who wrote the code, they can grep the source. For rdesktop, I wrote a Python script that generates an AUTHORS file from the source code. See http://rdesktop.svn.sourceforge.net/viewvc/rdesktop/rdesktop/trunk/genauthors?view=log . Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] building with host headers
Need Cendio's feedback on that in particular, since they were the ones who paid for the '-version 7.5' modification to build-xorg +1, I'm for removal of 7.5 support and we can consider removal of the build-xorg-git script as well. Still need feedback from Peter or Pierre regarding this. We are still building against xorg-server-1.5, but we do not use the build-xorg-git script. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Patch: gettext support for new vncviewer
On Tue, 26 Apr 2011, Pierre Ossman wrote: This patch adds gettext support for our new vncviewer. CMake only. The change of the project name is to make the CMake build behave like the Autotools build - define PACKAGE_NAME in the same way. Seems like a shame that we can't have proper capitalisation of the project name. Is there no other way to solve this? Where is it used for gettext? We are using the lower case name in Autotools today. The name is used in the .mo file name, for example. I think it's best to stick to the lower case name right now, especially when we still have two build systems. And you seem to call find_package(Gettext) twice in that patch. I've removed the one in po/CMakeLists.txt. Committing. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Several problems/questions when trying to generate pristine source tarball
On Mon, 7 Feb 2011, DRC wrote: (1) Can we please get rid of the Visual C++ project files that are still hanging around? +1, ok with me. (2) What is the purpose of the common/javabin directory? Can it be deleted? I think it should be deleted. (3) unix/xorg-7.5-patches/0001-Add-dridir-parameter-to-specify-DRI-drivers-director.patch and unix/xorg-7.5-patches/0001-Add-xkbcompdir-parameter-to-modify-xkbcomp-path-from.patch both have filenames that are too long for tar. Feel free to make them shorter. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] XDrawArc from XTS crasches Xvnc
On Mon, 6 Dec 2010, Adam Tkac wrote: I must admit it seems useless to hook pixmaps. I don't remember why I introduced pixmap hook in r2452, maybe due to Composite extension, not sure. I will try to remove it and perform some tests and if the removal doesn't cause any screen defect we can remove the pixmap hook. Ok, seems pixmap hook is not needed. Can you please check if attached patch fixes the XDrawArc crash, please? Thank you in advance. Looks fine, seems to fix the XDrawArc crash. Can you apply this patch? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] XDrawArc from XTS crasches Xvnc
I'm running the XTS (http://cgit.freedesktop.org/xorg/test/xts/) test suite
against Xvnc. The XDrawArc crashes the server every time. This happens with
both our own build (using xserver 1.5), as well with the Xvnc shipped with
Fedora 14. For some unknown reason, I'm not getting any core dumps from the
F14 Xvnc, but from our build, I've retrieved this backtrace:
The core dump problem was caused by abrt, see
https://bugzilla.redhat.com/show_bug.cgi?id=583407 .
The actual problem seems to be this function in vncHooks.cc:
static void vncHooksFillSpans(DrawablePtr pDrawable, GCPtr pGC, int nInit,
DDXPointPtr pptInit, int *pwidthInit,
int fSorted)
{
GC_OP_UNWRAPPER(pDrawable, pGC, FillSpans);
RegionHelper changed(pScreen, ((WindowPtr)pDrawable)-borderClip);
(*pGC-ops-FillSpans) (pDrawable, pGC, nInit, pptInit, pwidthInit, fSorted);
vncHooksScreen-desktop-add_changed(changed.reg);
}
We are casting pDrawable, but with the XDrawArc case, the drawable is not
a window but a pixmap. Pixmap structures doesn't have a borderClip member.
Why do we need to deal with pixmaps at all? In revision r2452, we started
hooking them:
r2452 | atkac | 2008-03-26 19:59:58 +0100 (ons, 26 mar 2008) | 3 lines
PaintWindowBackground and PaintWindowBorder hooks are no longer used.
PolyFillRect hook is used instead and it needs modified ValidateGC hook.
Adam, can you explain the reasoning behind this?
Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Internationalization and CMake
Yeah, trust me, I scoured the Internet before posing the question on this list. The issue is that our current i18n system seems to be geared toward integration with autotools and GNU Make. I can't simply call Unix commands from CMake, because that wouldn't work in Visual Studio. The current i18n system, gettext, should work fine with any build system, even though it is probably most often used with Autotools. msgcat, msgmerge etc are not Unix commands - they are gettext commands. If you want to build on Windows with gettext support, you need to have gettext installed, and call the appropriate commands from whatever build system you are using. It seems there are some basic information at http://www.gnu.org/software/gettext/FAQ.html#windows_howto about this. The rest should be in the gettext manual. If I understood how the existing system worked, I might be able to figure out how to port it. For instance, where did po/Makefile.in.in come from? Did someone write that by hand? No, its from gettext. On my Fedora 13 machine, the file can be found as /usr/share/gettext/po/Makefile.in.in. It is owned by the gettext-0.18.1.1 package. If I rembember correctly, it is copied to the project directory when you run gettextize. Rgds, Peter On 10/26/10 4:28 AM, Peter Åstrand wrote: The current build system uses gettext. The make files (although difficult to read) should be standard, generated by gettext. After all, gettext is the most common system for I18N in UNIX. I would be surprised if it's not possible to use gettext with CMake. Check out: http://search.gmane.org/?query=gettextgroup=gmane.comp.programming.tools.cmake.user There are quite a few emails on the subject there. -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Point of clarification regarding new build system
This question is mainly for Cendio, since they are primarily using a MinGW cross-compiler environment to build TigerVNC for Windows. Is it necessary to support building WinVNC under MinGW, or would it be sufficient to simply say that WinVNC can only be built under Visual C++ for now? We are not shipping WinVNC at all, so from a Cendio perspective, this is acceptable. I do think it's a little bit sad though, but we can of course re-add support for MinGW later. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Internationalization and CMake
OK, so next issue -- the scheme that TigerVNC uses for internationalization is heavily Unix-centric and based on a Makefile template that I'm having trouble parsing. Does anyone know what this file does well enough to explain it to me? For obvious reasons, if I have to run a Unix script to generate internationalization files, then it defeats the purpose of using a cross-platform build tool. The current build system uses gettext. The make files (although difficult to read) should be standard, generated by gettext. After all, gettext is the most common system for I18N in UNIX. I would be surprised if it's not possible to use gettext with CMake. Check out: http://search.gmane.org/?query=gettextgroup=gmane.comp.programming.tools.cmake.user There are quite a few emails on the subject there. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Win32 build with MinGW
On Mon, 17 May 2010, Adam Tkac wrote: As I wrote above I will test MS Visual Studio 2010 Express. If it will work fine then I will update *dsp build scripts and I will start to maintain them, it shouldn't be so hard. I agree with you that for Windows only developers Visual Studio environment is more natural and will bring more manpower to our project. Wouldn't it make more sense to fix the problems with MinGW instead? If the official downloads are bad, we can provide our own MinGW-for-windows. Shouldn't be very difficult. Sounds more fruitful than trying to maintain multiple build systems. Windows developers would still be able to edit and browse the source with Visual Studio, even if they need to build with MinGW. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] building with MinGW
Do you use MinGW on Windows or as a cross compiler on some other platform? I'm new to mingw (and using it as cross compiler), so I dont really know how to proceed past: cd tigervnc/trunk/win Any more pointers would be much appreciated. Use a distro that includes MinGW, such as recent Fedora versions. Install the mingw32 packages. Then, try something like (untested): cd tigervnc/trunk autoreconf -fi ./configure --host=i686-pc-mingw32 make Best regards, Peter Åstrand On 4/28/10 5:22 PM, Antoine Martin wrote: Hi, Is building with mingw supported now? Last time I sent some patches for building with Visual Studio C++ 2008 V9, I was told: we're going to start building with MinGW at some point in the not-so-distant future http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00440.html Cheers Antoine -- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] TigerVNC 1.1 development status
While we're on the subject of documentation, though ... Assuming we did develop documentation for TigerVNC, what are some ideas regarding the preferred markup to use? The TurboVNC and VirtualGL documentation was written using Deplate, so I assume we'd want to use something a little more standard for TigerVNC, like maybe Docbook (?) I've always been partial to good ol' text/plain. :) So if it's sufficient, my vote is for rst. +1 --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] xfs, GLX, and TigerVNC on Linux
On Sun, 10 Jan 2010, DRC wrote: (2) GLX support. I have this working, but Xvnc seems to only want to load swrast_dri.so if that file is located within my build directory (putting it elsewhere in the LD_LIBRARY_PATH doesn't work.) Wondering if there is any way to make Mesa load swrast_dri.so from a path I specify at run time. AFAIK: No. You need to specify a suitable prefix. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Modifiers (such as shift) sticking
On Thu, 12 Nov 2009, Adam Tkac wrote: Nice catch, I've never reproduced original issue but it seems your patch solves it. Please apply it to both trunk and 1_0. Done. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Modifiers (such as shift) sticking
Hi. I'm debugging a keyboard problem where modifiers, such as shift, sometimes are stuck. Unfortunately, the problem happens very seldom, which makes it hard to debug. What's worse is that it seems like we are facing multiple problems: I believe we have a VNC specific bug, but the fact is that similar problems are also occuring on fat machines, ie there are a bunch of keyboard and modifier related bugs in Xorg as well (no news...). I'm referencing Fedora bugs here, as examples: https://bugzilla.redhat.com/show_bug.cgi?id=481225 (random key-repeats and shift key causes shift-lock) https://bugzilla.redhat.com/show_bug.cgi?id=445898 (Slow keys turn on spontaneously, output two symbols at once) ...both describes similar problem, although in different components. We also have my favourite (most hated) bug: https://bugzilla.redhat.com/show_bug.cgi?id=494999 (Mouse freezes - moves but won't click) We have also occasionally seen shift lock problems on Fedora 11 as well as the Fedora 12 beta workstations... As I said, however, the particular problem I'm debugging is /probably/ VNC specific. There are earlier reports of this problem, such as: https://bugzilla.redhat.com/show_bug.cgi?id=386091 (Alt-key gets stuck in vnc server.) I've also been able to reproduce this problem with the vnc-server package that's shipped in Fedora 10 (RealVNC with X.Org 1.5.3). In some cases, such as with F10, it's really difficult to trigger the problem. With our build of TigerVNC, however, it's easier. What I usually do is to continously press a key such as a, and at the same time (but more seldom) also press the shift key. When you start seeing A releases and Shift presses even in between the shift presses, you have triggered the bug: Shift is stuck down. (You can recover by pressing shift once.) I've also managed to catch a Xvnc log: XserverDesktop: keycode 38 up XserverDesktop: keycode 38 down XserverDesktop: keycode 38 up XserverDesktop: keycode 38 down XserverDesktop: keycode 62 down XserverDesktop: keycode 38 up XserverDesktop: keycode 62 up XserverDesktop: fake keycode 62 up XserverDesktop: keycode 38 down XserverDesktop: fake keycode 62 down The fake keycodes starts when the bug is triggered. As you can see, Xvnc is trying to fake a shift up even though it just generated such an event! It then tries to clean up before finishing this keyboard even by (incorrectly) restoring the shift down state. The question is of course why it's trying to do that. If one inspects the code, one can see that Xvnc is checking if a modifier is active by looking at vncKeyboardDevice-key-state. Events are generated by calling mieqEnqueue(). Without knowing the internals of mieqEnqueue(), this looks suspicious to me. Perhaps the queue isn't processed immediately, so that vncKeyboardDevice-key-state isn't (yet) updated when Xvnc is about to create/queue the next event? I think we need some kind of mieqFlush() operation, or redesign the fake modifiers code paths. Or perhaps I have misunderstood the problem completely... Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] String handling in TigerVNC - C-like or C++-like
1. Use the C++ String class 2. Use the rfb/util.h:CharArray class 3. Use standard C strings with *printf() and str*() functions From my point of view the best solution will be to use variant 3. (C-like handling) because you don't have to deal with objects and affraid of additional overhead. But the 1. variant is probably also a good idea. The 2. variant should not be choosen because I don't see any advantage from CharArray class. What is your opinion? Do you vote for C or C++? ;) I'm no fan of C++ either, but the string features is actually one of those things that I like. Aren't the three different variants above somewhat apples and oranges? If I remember correctly, both 1 and 2 can handle embedded null characters, while 3 cannot. At least not without passing along an extra variable that indicates the length. OTOH, perhaps strings with embedded nulls are uncommon. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-users] Some issues found with Tiger VNC 0.0.90 (Windows XP)
On Mon, 6 Jul 2009, Peter Åstrand wrote:
2. vnc viewer's About dialog box title About VNC Viewer for Windows
(should be about TigerVNC ...) [minor]
I agree. A patch that corrects this is attached.
If there are no objections, I'll commit this patch.
Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00Index: unix/vncviewer/AboutDialog.h
===
--- unix/vncviewer/AboutDialog.h(revision 3864)
+++ unix/vncviewer/AboutDialog.h(arbetskopia)
@@ -35,7 +35,7 @@
class AboutDialog : public TXMsgBox {
public:
AboutDialog(Display* dpy)
-: TXMsgBox(dpy, aboutText, MB_OK, _(About VNC Viewer)) {
+: TXMsgBox(dpy, aboutText, MB_OK, _(About TigerVNC Viewer)) {
}
};
Index: unix/vncviewer/CConn.cxx
===
--- unix/vncviewer/CConn.cxx(revision 3864)
+++ unix/vncviewer/CConn.cxx(arbetskopia)
@@ -454,7 +454,7 @@
menu.addEntry(_(New connection...), ID_NEWCONN);
menu.addEntry(_(Options...), ID_OPTIONS);
menu.addEntry(_(Connection info...), ID_INFO);
- menu.addEntry(_(About VNCviewer...), ID_ABOUT);
+ menu.addEntry(_(About TigerVNC viewer...), ID_ABOUT);
menu.addEntry(0, 0);
menu.addEntry(_(Dismiss menu), ID_DISMISS);
menu.toplevel(_(VNC Menu), this);
Index: unix/po/tigervnc.pot
===
--- unix/po/tigervnc.pot(revision 3864)
+++ unix/po/tigervnc.pot(arbetskopia)
@@ -16,7 +16,7 @@
Content-Type: text/plain; charset=CHARSET\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr
msgid VNC authentication
Index: unix/po/pl.po
===
--- unix/po/pl.po (revision 3864)
+++ unix/po/pl.po (arbetskopia)
@@ -13,7 +13,7 @@
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr O Przeglądarce VNC
msgid VNC authentication
Index: unix/po/sk.po
===
--- unix/po/sk.po (revision 3864)
+++ unix/po/sk.po (arbetskopia)
@@ -15,7 +15,7 @@
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr O aplikácií VNC Viewer
msgid VNC authentication
Index: unix/po/de.po
===
--- unix/po/de.po (revision 3864)
+++ unix/po/de.po (arbetskopia)
@@ -18,7 +18,7 @@
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr Über VNC-Viewer
msgid VNC authentication
Index: unix/po/sv.po
===
--- unix/po/sv.po (revision 3864)
+++ unix/po/sv.po (arbetskopia)
@@ -17,7 +17,7 @@
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr Om VNC-visaren
msgid VNC authentication
Index: win/winvnc/winvnc.rc
===
--- win/winvnc/winvnc.rc(revision 3864)
+++ win/winvnc/winvnc.rc(arbetskopia)
@@ -135,7 +135,7 @@
IDD_ABOUT DIALOG DISCARDABLE 0, 0, 249, 92
STYLE DS_MODALFRAME | DS_SETFOREGROUND | DS_CENTER | WS_POPUP | WS_CAPTION |
WS_SYSMENU
-CAPTION About VNC Server for Windows
+CAPTION About TigerVNC Server for Windows
FONT 8, MS Sans Serif
BEGIN
DEFPUSHBUTTON OK,IDOK,195,70,47,15
Index: win/vncviewer/vncviewer.rc
===
--- win/vncviewer/vncviewer.rc (revision 3864)
+++ win/vncviewer/vncviewer.rc (arbetskopia)
@@ -155,7 +155,7 @@
IDD_ABOUT DIALOG DISCARDABLE 0, 0, 249, 92
STYLE DS_MODALFRAME | DS_SETFOREGROUND | DS_CENTER | WS_POPUP | WS_CAPTION |
WS_SYSMENU
-CAPTION About VNC Viewer for Windows
+CAPTION About TigerVNC Viewer for Windows
FONT 8, MS Sans Serif
BEGIN
DEFPUSHBUTTON OK,IDOK,195,70,47,15
Index: win/vncconfig/vncconfig.rc
===
--- win/vncconfig/vncconfig.rc (revision 3864)
+++ win/vncconfig/vncconfig.rc (arbetskopia)
@@ -211,7 +211,7 @@
IDD_ABOUT DIALOG DISCARDABLE 0, 0, 249, 92
STYLE DS_MODALFRAME | DS_SETFOREGROUND | DS_CENTER | WS_POPUP | WS_CAPTION |
WS_SYSMENU
-CAPTION About VNC Config for Windows
+CAPTION About TigerVNC Config for Windows
FONT 8, MS Sans Serif
BEGIN
DEFPUSHBUTTON OK,IDOK,195,70,47,15
--
Let Crystal Reports handle the reporting - Free Crystal Reports
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[3876] trunk/common/jpeg/jpeg.dsp
I agree, it's better to hold off until the MinGW port. Regards, Peter On Thu, 20 Aug 2009, DRC wrote: OK, I guess the question I'm asking is -- is it worth it to try to bring the assembly files into the dsw/dsp projects, create custom build rules for NASM, etc., or would it be better to just hold off until we port to MinGW? My inclination is the latter, because I just realized I don't actually have a version of Visual C++ that can directly use the dsw/dsp projects. I am using VC Express 2008, which has to convert the project files into its own format before I can modify them. Peter Åstrand wrote: Just for my own clarity, though, aren't we moving away from VC at some point? I'm happy to fix this and make it work for the moment, if we think we want to be able to use libjpeg/SIMD in VC as an interim solution. Yes, we are moving away from VC, as soon as possible. We just need to make WinVNC etc build with MinGW. As I understand it, everybody has this on their TODO list :-) --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[3876] trunk/common/jpeg/jpeg.dsp
I'm now using libjpeg/SIMD in the VirtualGL 2.2 development branch and have successfully built and run it on Windows using VC. What problems did you run into? In that case, I doubt that you have been using the checked in .dsp/.dsw files, since one of these were referencing the now non-existent jsimd.c. I got an endless stream of link errors of type: vncviewer error LNK2019: unresolved external symbol _jsimd_rgb_ycc_convert_mmx referenced in function _jsimd_rgb_ycc_convert Any idea? Feel free to revert this commit, if you want, though. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[3876] trunk/common/jpeg/jpeg.dsp
Hmmm Well, upon further examination, the reason is that it's not assembling the SIMD files and including them in the link. Just for my own clarity, though, aren't we moving away from VC at some point? I'm happy to fix this and make it work for the moment, if we think we want to be able to use libjpeg/SIMD in VC as an interim solution. Yes, we are moving away from VC, as soon as possible. We just need to make WinVNC etc build with MinGW. As I understand it, everybody has this on their TODO list :-) Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-users] Some issues found with Tiger VNC 0.0.90 (Windows XP)
Hi, see comments inline.
1. Setup: when launched, asks This will install TigerVNC. Do you wish
to continue? - could be omitted, as it adds nothing but another dialog
box to the installation experience. [minor]
I agree that it's quite pointless. We are using Inno Setup 3.0, which is
fairly old. Perhaps it's possible to disable this screen; suggestions are
welcome. Or, perhaps the problem goes away when we are switching to a
newer installer.
2. vnc viewer's About dialog box title About VNC Viewer for Windows
(should be about TigerVNC ...) [minor]
I agree. A patch that corrects this is attached.
3. vnc viewer: 'server' dialog box cannot be reached using keyboard
shortcut (missing accelerator) [minor]
4. vnc viewer: options dialog box - lack keyboard shortcuts for some
options, and those that exist (such as *A*uto select in Colour
(Britsh?) Encoding ) do not work[minor]
5. vnc viewer: options dialog box - no help available, not even bubble
help, for the various options. [minor]
6. vnc viewer: toolbar lacks any descriptions to the buttons. [minor]
7. vnc viewer: info dialog box is not modal, although it's not really
updating in real time. [minor]
I don't really know how the keyboard accelerators or tooltips works in the
current viewer. It might be easier to wait with fixing these problems
unless we have migrated to the new toolkit.
8. vnc viewer: ctrl and alt buttons are not 'sticky' [medium]
The effect is sticky, but this is not reflected in the GUI. Yes, this is a
bug.
9. vnc viewer: from time to time, disconnects with 'Rect too big'
message [major]
Which VNC server are you using? Can you reproduce this easily? This
problem is perhaps already fixed.
Best regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00Index: unix/vncviewer/AboutDialog.h
===
--- unix/vncviewer/AboutDialog.h(revision 3864)
+++ unix/vncviewer/AboutDialog.h(arbetskopia)
@@ -35,7 +35,7 @@
class AboutDialog : public TXMsgBox {
public:
AboutDialog(Display* dpy)
-: TXMsgBox(dpy, aboutText, MB_OK, _(About VNC Viewer)) {
+: TXMsgBox(dpy, aboutText, MB_OK, _(About TigerVNC Viewer)) {
}
};
Index: unix/vncviewer/CConn.cxx
===
--- unix/vncviewer/CConn.cxx(revision 3864)
+++ unix/vncviewer/CConn.cxx(arbetskopia)
@@ -454,7 +454,7 @@
menu.addEntry(_(New connection...), ID_NEWCONN);
menu.addEntry(_(Options...), ID_OPTIONS);
menu.addEntry(_(Connection info...), ID_INFO);
- menu.addEntry(_(About VNCviewer...), ID_ABOUT);
+ menu.addEntry(_(About TigerVNC viewer...), ID_ABOUT);
menu.addEntry(0, 0);
menu.addEntry(_(Dismiss menu), ID_DISMISS);
menu.toplevel(_(VNC Menu), this);
Index: unix/po/tigervnc.pot
===
--- unix/po/tigervnc.pot(revision 3864)
+++ unix/po/tigervnc.pot(arbetskopia)
@@ -16,7 +16,7 @@
Content-Type: text/plain; charset=CHARSET\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr
msgid VNC authentication
Index: unix/po/pl.po
===
--- unix/po/pl.po (revision 3864)
+++ unix/po/pl.po (arbetskopia)
@@ -13,7 +13,7 @@
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr O Przeglądarce VNC
msgid VNC authentication
Index: unix/po/sk.po
===
--- unix/po/sk.po (revision 3864)
+++ unix/po/sk.po (arbetskopia)
@@ -15,7 +15,7 @@
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr O aplikácií VNC Viewer
msgid VNC authentication
Index: unix/po/de.po
===
--- unix/po/de.po (revision 3864)
+++ unix/po/de.po (arbetskopia)
@@ -18,7 +18,7 @@
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr Über VNC-Viewer
msgid VNC authentication
Index: unix/po/sv.po
===
--- unix/po/sv.po (revision 3864)
+++ unix/po/sv.po (arbetskopia)
@@ -17,7 +17,7 @@
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
-msgid About VNC Viewer
+msgid About TigerVNC Viewer
msgstr Om VNC-visaren
msgid VNC authentication
Index: win/winvnc/winvnc.rc
===
--- win/winvnc/winvnc.rc(revision 3864)
+++ win/winvnc/winvnc.rc(arbetskopia)
@@ -135,7
Re: [Tigervnc-devel] [PATCH] Polish translation
On Thu, 18 Jun 2009, Adam Tkac wrote: Hi all, Piotr Drąg created polish translation for us (https://bugzilla.redhat.com/show_bug.cgi?id=505675). I would like to commit it to both 1.0 and trunk. Patch is attached. +1 --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Translation updates
I've performed some translation updates: - converted all .po files to UTF-8 - updated version strings - minor corrections - bumped versions to 0.0.91 Do you have any comment? I would like to commit changes to both 1.0 and trunk. +1 --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Are we ready for 1.0.0 RC1?
On Fri, 12 Jun 2009, Adam Tkac wrote: I think it's right time to release TigerVNC 1.0.0 RC1, isn't it? ;) I agree. I think we could even release a 1.0.0 version directly, but an RC is also OK. Patch which bumps up version numbers is attached. I also created doc/version_numbers which contains list of files whose have to be modified during release process. Proposed announcement is attached as well. Do you have any comments? Looks fine. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Internationalized viewer doesn't work with UTF-8 charset
On Fri, 29 May 2009, Adam Tkac wrote: Ok, based on discussion in this thread I created proposed patch. Gettext is used only if user uses iso-8859-1 or iso-8859-2 encoding. I'm not convinced. What would be the advantage of this big patch, compared to just removing ru from the LINGUAS file? Why only iso-8859-1 and iso-8859-2, and not, say, iso-8859-15? I also don't understand we would need a special underscore-function, wouldn't it be sufficient with just skipping the activation of gettext, if the locale is wrong? Ok, you have persuaded me. Improved patch is attached. Looks great. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] New tracker submissions to this list
I suggest that we activate Send email on new submission for all of our trackers, so that new submissions are sent out on this devel list. This allows developers to be notified of new bugs and requests. This has worked great within the rdesktop project. Comments? Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Internationalized viewer doesn't work with UTF-8 charset
On Thu, 28 May 2009, Adam Tkac wrote: one man reported problem that vncviewer doesn't show Russian letters (https://bugzilla.redhat.com/show_bug.cgi?id=501832). Ok, based on discussion in this thread I created proposed patch. Gettext is used only if user uses iso-8859-1 or iso-8859-2 encoding. I'm not convinced. What would be the advantage of this big patch, compared to just removing ru from the LINGUAS file? Why only iso-8859-1 and iso-8859-2, and not, say, iso-8859-15? I also don't understand we would need a special underscore-function, wouldn't it be sufficient with just skipping the activation of gettext, if the locale is wrong? Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Xvnc hogs the CPU
Here's another strange bug, also found during TigerVNC Xvnc testing. On
Ubuntu 9.04 beta[*], after starting GNOME, Xvnc consumes all CPU it can
get. An strace indicates:
time(NULL) = 1240494241
setitimer(ITIMER_REAL, {it_interval={0, 2}, it_value={0, 2}}, NULL) = 0
gettimeofday({1240494241, 713782}, NULL) = 0
gettimeofday({1240494241, 713837}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
gettimeofday({1240494241, 714036}, NULL) = 0
select(256, [0 1 3 4 5 6 7 9 10 11 12 13 14 15 16 18 19 21 25 26], NULL, NULL,
{0, 0}) = 0 (Timeout)
gettimeofday({1240494241, 714176}, NULL) = 0
Since the nfds argument is 256, this is most likely a select() invocation
with FD_SETSIZE. As far as I can tell, there's no such call in the VNC
specific parts of Xvnc, so the select call is most likely in generic Xorg
code.
[*]: Actually, it doesn't matter if Xvnc itself is running on Ubuntu or
not. The problem also happens when Xvnc is running on some other platform
and X11 forward is used: The trigger seems to be the Ubuntu version of
GNOME.
Seen before?
Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Lost keyboard events after starting DBUS
Perhaps, but since the events are actually delivered to the application, I think it looks like a problem with libX11. Maybe a libxcb bug or change in semantics? Perhaps try an old libX11.so using LD_LIBRARY_PATH, or run terminal from an older machine. I've now tried running the xterm on a Red Hat 7.3 machine against an Xserver running on Fedora 8. When SSH:ing back to the Fedora 8 machine and running the eval command, the problem is present even in this case. The installed version of libX11 on the 7.3 machine is XFree86-libs-4.2.1-16.73.31.legacy. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Lost keyboard events after starting DBUS
On Mon, 20 Apr 2009, Adam Tkac wrote: I have seen the same symptom here as well, but not just with dbus. When using TigerVNC with Konsole, I have observed keystrokes disappearing if I type too fast. I've now been able to reproduce this problem with the Fedora 11 VNC package as well, tigervnc-server-0.0.90-0.5.20090403svn3751.fc11.x86_64. Probably, it has nothing to do with dbus, but for us this is an easy way of triggering the problem. Adam, any ideas? Interesting. Could you check if all events are received on server side correctly, please? (run Xvnc with -log *:stderr:100 param, for example) Yes, I've verified this, both using Wireshark and also by checking the output from -log *:stderr:100. The event is lost later, inside Xvnc. Unfortunately, I'm not very familiar with the Xorg event systems, which seems to be moving target :-( Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build system suggestion: SCons
On Wed, 15 Apr 2009, Matt Campbell wrote: 1. SCons can use native tools on both Unix and Windows. No Unix emulation layer is required on Windows. The more I develop under Windows, the more I understand how different the two systems are, and the more I want to avoid trying to emulate Unix on Windows. MinGW+MSYS requires no emulation layer on Windows. The tools are native. 2. SCons uses a single, powerful programming language (Python) for its project files, rather than shell+make+m4+Perl as in autotools, or inflexible XML project files as in Visual Studio. Version number as SPOT? Sure. Auto-generation of license file with CRLF? Easy! Yes, Peter, I've been reading your SVN commit messages. Nice :) I like Python very much, but I don't believe that we should switch build system based on language preference only. The autotool toolchain is ugly, but mostly works. If we should switch, it should be because the new build system should substantially reduce the amount of time we need to spend on it. Any new build system such as SCons or CMake will start below zero, since it would be necessary to start learning the new system, plus do the migration. Thus, they must really save time and trouble in the long run, if the switch should be worth it. 3. I think many developers have grown tired of autotools. Major projects still use it because it's considered some kind of standard; perhaps they think users will be severely disoriented or something like I'm not concerned about users getting confused, but from a developer point, it's nice to build on a standard system, even if it's ugly. If I have some problems, a quick Google usually gives me the answer. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[3767] trunk/unix/download-xorg
+if hassubprocess == 1: +assert 0 == subprocess.call([wget, -N, -c, -O, fname, loc]) +else: +assert 0 == os.spawnvp(os.P_WAIT, wget, [-N, -c, -O, fname, loc]) Why not use os.spawnvp even with newer versions? Less complex. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] RHEL 4 build
On Sat, 11 Apr 2009, DRC wrote: However, I ran into a problem with dbus. RHEL 4 ships a pre-release version (0.22) which isn't compatible with the X server 1.5 source. For comparison, RHEL 5 uses a significantly newer version (1.12.) Unfortunately, however, other system applications are tied to the ABI-incompatible pre-release, so it isn't a simple matter of upgrading the RPM. I'd need to build it from source and then link Xvnc to my version of it (probably statically.) Any sage advice? I'm hoping that maybe there's a magic flag to disable the dbus requirement or something like that. There's a configure flag: $ ./configure --help 21 | grep -i dbus --enable-config-dbusBuild D-BUS API support (default: no) Does this flag help? What's strange is that the help text says it defaults to no, but apparently this isn't the case. In any case, DBUS doesn't seem to be a hard dependency; we don't have it all on our build system. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] File transfer
I agree. Also, it wasn't just the implementation that was broken - the special protocol had many problems as well. I would say that the design was flawed from the start: If a file transfer feature should at all be included in a VNC implementation, it should at least be based on some existing protocol. Reinventing the wheel is always bad. In ThinLinc, we are using NFSv3 and the unfs3 server. Works great. Best regards, Peter Åstrand On Mon, 13 Apr 2009, DRC wrote: We may have discussed it before the list was created, because I can't seem to find the thread in the archives. However, IIRC, the reason was mainly that the feature was broken and we didn't have anyone who cared about it enough to fix it and maintain it. File transfer only exists in the Windows VNC server, and one of the reasons why we forked the project was so we would be able to focus more on the Unix VNC server. Don't get me wrong-- we're still shipping WinVNC and VNCviewer. In particular, my project still has a vested interest in the Windows TigerVNC code. However, the Windows code may not receive as much attention from the project as a whole. Matt Campbell wrote: Hello all: I noticed that file transfer was removed from TigerVNC about a month ago. Why was this done, and is there any plan to bring file transfer back? If the decision has already been explained, I'd appreciate a link to the original explanation. Thanks, Matt -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] libjpeg/SIMD 64-bit build, etc.
MSVC 2008 is certainly a problematic requirement for many people. As we have discussed before, one idea, which I still believe we should implement, is to get rid of all MS compiler dependencies. This means that the Autotools toolchain, GCC, and NASM could be used an all platforms. I agree with getting rid of MS compiler dependencies and using MSYS or Cygwin. But I don't think MSVC 2008 is as problematic as you think. The compiler is available for free these days, and it's easier for most people to install than a full-blown Cygwin distribution. The MSVC compiler might be free today, but what about tomorrow? The history also indicates that MS moves quite rapidly when it comes to development environments: The 2008 version might soon be replaced with something new and incompatible. This has happened numerous times before. In fact, when I started working with TightVNC, one problem I had was that the build system required MSVC 6.0, but that version wasn't available any longer... MSVC also has some other serious limitations, such that it only supports compiling code that's are located on local drives. Samba shares, for example, does not work. (At least this was the case last time i checked.) If you use MSYS, Cygwin is not necessary. So I think it's safe to say installing MSYS, MinGW and even NASM on Windows should be as easy or even more easy than installing MSVC 2008. Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Migrate to GPLv3?
Someone has to be first, right? One main reason why we created TigerVNC was that we should be able to work faster, move faster. So it might not be surprising that the slower projects have not yet migrated. Be careful. One of those slower projects is the very one you're trying to siphon performance enhancements off of. Our project chose to remain with GPL v2 not because of slowness but because we didn't like the provisions of GPL v3. I suspect that many projects have made this With slower projects I meant projects that haven't yet considered the v3 migration issue at all. Obviously, TurboVNC is not such a project. I'm not saying that it's bad to take it slow either, I'm just saying that v3 is after all quite new and time is one factor that explains why there are still many projects which haven't migrated to v3. I respect that, but the motivation for doing this is to prevent people from using the code in a way that we don't but which is still allowed by v2. Say, IGEL. OK, so can you explain the loophole in GPL v2 that they exploited? http://en.wikipedia.org/wiki/Tivoization seems to explain it quite good. As far as I understand, this policy is not new to v3; it's been in the FSF FAQ for many years and applies to v2 as well. We've had this discussion at length on the TightVNC list before, so I won't repeat it here. In a nutshell, different lawyers disagree on this. The OSI, for instance, doesn't believe that, if the GPL were tested in court, it would even apply to static linking, much less dynamic. There are a lot of grey areas to the argument, though. I agree, there are different interpretations and this is a grey area, but in my opinion, v3 provides some good clarifications. Additionally, I find the language in paragraph 1 of the GPL v3 which defines corresponding source to include all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities to be somewhat draconian and open to all sorts of bad interpretations (for instance, if you require a newer version of Java to run your object code, does that mean you have to ship Java?) Regardless of whether one think this new wording is good or bad, please note that this already applies to TigerVNC and TurboVNC, since they are v2+. Users can choice v3 if they want. In general, I think that choosing GPL v3 is giving up some of our freedom in exchange for the promise of additional security. I understand. To summarize: I understand that you both sees a need for v2 compatibility as well as have some doubts over the v3 wording. Since the current source is v2+, we cannot get rid of v3 entirely; I guess you have to accept it. When it comes to keeping v2 compatibility, I understand that this is important to you, but you haven't yet convinced me. The main argument as I understand it is to allow code copying to v2 projects, but I don't see a real need for this. In any case, a migration to v3 is not a must for me. I'm fine with sticking to v2+ as well, at least for some additional time. What I'm suggesting is that we keep v2+ for now and then we can revisit the issue sometimes in the future. By then, we can take another look at how many projects have migrated to v3, how many projects that have copied source from us, how big the Tivoization problem has been etc. Is everyone happy with this approach? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] quick bandaid for encoding autoselection
On Wed, 11 Mar 2009, Adam Tkac wrote: We should always send second preferred encoding to server in case that server doesn't support JPEG. So, in theory, existing code will be improved this way: for speeds = 16Mbps client sends Raw, JPEG, hextile, zrle for speeds 16Mbps client sends JPEG, zrle, hextile As I understand it, Pierres results shows that JPEG is preferrable even on fast networks. My experience is that Raw is pretty bad even if you have a superfast connection. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
