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 <jupiter....@gmail.com> 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 <dcomman...@users.sourceforge.net> 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 VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
