DRC, No, your original understanding of the symptoms were correct, but I'm saying that it's not a simple TurboVNC Server versus TigerVNC Server comparison - there are other variables at play from our customizations in regard to default xstartup, %gconf.xml etc., so first we need to check that those customizations are being done consistently to eliminate confounding factors.
Cheers, James On 22/12/2012, at 6:06 PM, DRC <[email protected]> wrote: > Sorry, I guess I misunderstood the bug. I thought he meant that he was > dragging other application icons to the desktop and they weren't > launching, not that he was dragging the TurboVNC/TigerVNC icons to the > desktop and those weren't launching. The released binaries for TigerVNC > don't have a desktop icon, and the one that we release in TurboVNC > refers to absolute paths. But if these icons are being created by a 3rd > party or are being customized, then all bets are off. > > > On 12/21/12 6:47 PM, James Wettenhall wrote: >> Jupiter, >> >> Whilst DRC's instructions for building TurboVNC server with Mesa >> support are very helpful and much appreciated, the conclusion that >> there must be a bug in TigerVNC server makes no sense to me. You >> should mention that you are packaging up both TurboVNC and TigerVNC >> within the modules environment, and that you are including >> configuration information for xstartup and for the XFCE desktop >> environment within your packaged versions of TurboVNC and TigerVNC >> within the /usr/local/<module_name>/<version_number>/config/ >> directory. I can see major differences in the contents of those >> config/ directories between the TurboVNC and TigerVNC modules on at >> least one of our virtual machines. >> >> Also, as discussed off list, I don't think you can safely rely on >> environment variables like $HOME being available in a .desktop >> launcher, because desktop launchers are not guaranteed to be run >> within a shell environment. My preference would be to omit the >> "Path=$HOME" line from the desktop launchers. >> >> Cheers, >> James >> >> >> On 22/12/2012, at 10:42 AM, jupiter <[email protected]> wrote: >> >>> Thanks for the tips of likely bugs in tigervnc to cause the problem, >>> and thanks for the wiki link, that is definitely the solution we need >>> go. >>> >>> Cheers, >>> >>> j >>> >>> On 12/22/12, DRC <[email protected]> wrote: >>>> Such an issue has nothing to do with client/server interaction. It's >>>> most likely due to a bug in the TigerVNC server. I ceased my >>>> involvement with that project about a year ago, for a variety of >>>> reasons, but one of the largest was that I felt like I was fighting an >>>> uphill battle to make TigerVNC as performant and stable as TurboVNC. It >>>> was going to be easier to migrate the "interesting" features from >>>> TigerVNC into TurboVNC (which we're in the process of doing for TurboVNC >>>> 1.2) rather than stabilize TigerVNC and add the features to it that >>>> TurboVNC users needed. The TigerVNC Project has no QA, beta, and >>>> release process, so even when I stabilized it, it tended not to stay >>>> that way for long. On the server end, TigerVNC's stability depends a >>>> lot on the stability of a particular X.org release, so it is really >>>> designed for system integrators (such as Red Hat, etc.) to maintain, and >>>> it relies on the system integrators to do QA and fix bugs. TurboVNC, on >>>> the other hand, is designed as a self-contained, enterprise-class >>>> product, so any time a bug is fixed for one user, all users benefit. >>>> >>>> Since I've gotten asked about using Mesa with TurboVNC several times in >>>> recent months, I went ahead and created a wiki article on it: >>>> http://www.virtualgl.org/Documentation/Mesa >>>> >>>> The procedure is simple. It just requires you to build Mesa with the >>>> X11 driver, which isn't normally included in most vendor-supplied >>>> releases of Mesa. >>>> >>>> Note that we do things this way for two reasons: >>>> >>>> (1) We don't want software OpenGL to be enabled by default in TurboVNC, >>>> because if VirtualGL were not working properly for some reason (or if >>>> the user forgot to type in 'vglrun'), they might never know that >>>> something was wrong, other than for the fact that their application was >>>> running more slowly than expected. >>>> >>>> (2) One of the driving principles of the VirtualGL Project is to avoid, >>>> as much as possible, maintaining an implementation of the OpenGL API. >>>> Because that API changes relatively quickly, we provide a platform that >>>> allows applications to interact directly with other implementations of >>>> it (including Mesa.) Thus, when OpenGL changes, usually no changes are >>>> required to VirtualGL or TurboVNC. >>>> >>>> >>>> On 12/21/12 5:12 AM, jupiter wrote: >>>>> Hi, >>>>> >>>>> I am running tigervnc 1.2.0 on server and turbovnc 1.1 for client. I >>>>> can click applications on desktop menu without problems, but when I >>>>> dragged the application icon to desktop, I could not start desktop >>>>> launcher, it could not interpret $HOME parameter and it misinterpret >>>>> "terminal" to be xterm. >>>>> >>>>> It is fair to say, it does not have such problem if I run both >>>>> turbovnc server and client together. But we don't have GPU on VM and >>>>> we have to run tigervnc server for using mesa, >>>>> >>>>> It seems either bugs in tigervnc or mismatch between tigervnc and >>>>> turbovnc viewer. Is there workaround to fix the problem? > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
