OK, glad to know it works. Maybe the newer versions of OS X try to outsmart us by looking in the bundle and checking whether an app with that same ID (our bundle ID is com.turbovnc.vncviewer.VncViewer, same as the Java class name used to launch it) already exists somewhere under /Applications.
I wish Apple would just adopt a packaging system that is based on some reasonable industry standard and includes a clean way to manage/upgrade/uninstall packages, etc. This has been a problem with OS X from the beginning. The Mac platform, in general, seems to always expect you to use the straightforward method (drag-installing a self-contained app, in our case), but when that method proves insufficient for your needs, developing something more advanced always turns into a complete hack job. To paraphrase Churchill, OS X is the worst consumer desktop O/S out there -- except for all the others. On 11/21/12 5:29 PM, James Wettenhall wrote: > DRC, > > OK, I have finally solved this problem. :-) > > Apologies for all of your wasted time - it looks like it was definitely > specific to my Mac laptop. > > I have confirmed with my colleagues that none of them have experienced the > problem I encountered. > > So I'm no longer worried that my Mac users will have trouble installing > TurboVNC viewer, and I can focus on the task of ensuring that our application > can detect which viewer is installed (X11 or Java) and adjust the > command-line arguments we use accordingly. > > I think the problem was caused by having old versions of the TurboVNC Java > viewer app sitting elsewhere on my Mac laptop. This may not have been a > problem in older versions of Mac OS X, but recent versions are becoming more > like iOS, in which it doesn't make sense to have multiple copies of the same > application sitting on the same machine. > > While the latest TurboVNC pre-release installer was trying to install the > TurboVNC Viewer.app into /Applications/TurboVNC/, I had a previous > installation in /Applications/TurboVNC 1.2 Pre-release Preview/ and another > one (copied from a DMG) in /Applications/TurboVNC Viewer (Java).app which I > had renamed to /Applications/TurboVNC Viewer (Java).app.old. > > Then while trying to diagnose the problem, I had extracted Archive.pax.gz > from the TurboVNC.pkg a couple of times, so I had both an "Archive" folder > and an "Archive 2" folder in my ~/Downloads/, both containing the "TurboVNC > Viewer.app" bundle. > > I used Spotlight to ensure that I had deleted (or at least zipped up) all > occurrences of "TurboVNC Viewer.app". > > Then I re-ran the installer, and it worked perfectly. :-) > > Cheers, > James > > > On 22/11/2012, at 2:11 AM, DRC wrote: > >> Do you have a machine running an earlier version of OS X? That would at >> least tell us whether this has to do with the O/S version > > I have an old Mac Mini running OS X 10.6.8. I can't reproduce the problem on > that. > > My wife's MacBook Air is running OS X 10.7.5. I can't reproduce the problem > on that either. > > I've tried copying the /System/Library/CoreServices/Installer.app from my > wife's MacBook Air onto my MacBook Pro used for work, but that didn't solve > the problem. > > I've asked some of my colleagues to test this, and two have replied already, > (one using OS X 10.8, and the other using OS X 10.7, I think), saying that it > works fine for both of them. > > My MacBook Pro used for work is running OS X 10.7.5, on which the problem is > 100% reproducible, except for the times when I use the "Pacifist" shareware > application instead of Apple's built-in "Installer" to install the TurboVNC > PKG. I've never had a problem with any other PKG installers on my MacBook > Pro I use at work. But maybe something is corrupt in my MacBook Pro, > relating to /System/Library/CoreServices/Installer.app and/or the > package/receipts registry. > > So now, I guess I can stop worrying that users of my application will have > problems installing the TurboVNC viewer on Mac OS X, and focus on the problem > of how our application will detect which version of the viewer is installed > (X11 or Java) and adjust the command-line arguments accordingly. It's just > annoying that I currently have to use a non-standard method to install the > Java viewer, because while testing our application's ability to detect > between and adapt to the Java viewer versus the X11 viewer, I will need to > switch between them frequently, which has been painful during recent attempts. > > We have ordered a Mac Mini to use at work for testing and development of our > application, (which hopefully won't have the same problem as my MacBook Pro), > but it could be another week or two before it arrives. > > I've had a brief Google for discussions of problems with Mac OS X's PKG > installer, but so far, I haven't found anything which sounds like my problem. > > Cheers, > James > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > VirtualGL-Devel mailing list > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-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 _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
