I have the same fear wrt iOS, and in fact, the new Java/Mac viewer, as you know, is a product of paid research to develop TurboVNC for mobile platforms (but Android, not iOS.) The main issue with iOS isn't technical-- it's legal. Until or unless Apple allows GPL'ed software in the App Store, the open VNC ecosystem won't ever make it to that platform, and RealVNC will continue to be the only solution (but not really a solution for remote 3D-- not fast enough.) The beauty of open source is that it lets developers focus on what they're good at. I suck at writing GUI code from scratch, but I'm a wizard with making things lightning fast, and I'm good enough at editing other people's GUIs that it would be straightforward to take some other OSS VNC for iOS (assuming one existed) and Turboify it in the same way I did with TightVNC and TigerVNC. Coming up with a whole iOS viewer from scratch just won't happen, though.
I certainly wouldn't (and actually couldn't) object to you using parts of TurboVNC in another GPL'ed app. The more the merrier. In the meantime, I welcome your testing of the Java app as it is, since you're providing valuable feedback that will help ensure that we don't leave Mac users in the cold by switching from X11 to Java. Unfortunately, the HTML 5 conversion tool (AjaxSwing) just didn't work well with our Java viewer. It was a nice thought ... On Dec 13, 2012, at 3:24 AM, James Wettenhall <james.wettenh...@monash.edu> wrote: > DRC, > > Fantastic! > > As we have such a large number of Mac OS X users, I really appreciate all of > the work you have put into refining the Java Viewer ! > > As our application is GPL (like TurboVNC), we are now considering rewriting > our GUI from wxPython into Java Swing, so that it can be more tightly > integrated with TurboVNC Viewer, i.e. we can bundle the VncViewer classes > into our Java application. Then I assume you wouldn't have any objection to > us reusing parts of your code, e.g. the Options dialog within our GUI? Of > course any changes we make would be made available under a GPL licence. > > Assuming we do go down this path, I doubt that our Java GUI will be ready to > go by the time TurboVNC 1.2 is officially released, so I think we need to > continue testing whether any of the TurboVNC command-line arguments we are > currently need to be modified for the Java viewer, relative to the X11 > viewer. We're almost there... > > Our only fear regarding Java amongst our Mac user community is that one day > OS X could disappear and be replaced by iOS and that Java could be a casualty. > > I know you pointed out there are tools for converting Java Swing applications > to HTML5 / AJAX applications, but that doesn't sound easy to me. :-) > > Cheers, > James > > > > On 13/12/2012, at 7:50 PM, DRC wrote: > >> This should be addressed in the latest pre-release. I completely >> overhauled the exception handling, which took way longer than I wanted >> it to, but I felt like it needed to be done. I also fixed a ton of >> formatting issues with the code and attempted to make it at least >> consistent with itself and more or less compliant with the Java code >> conventions (at least the ones I agree with.) >> >> The exception handling now works similarly to that of the Windows >> viewer. There are three basic types of exceptions: WarningExceptions >> indicate failures that are generally expected as a result of either a >> user action or some other normal condition, ErrorExceptions indicate >> failures that are generally unexpected but have known causes, and >> SystemExceptions originate as exceptions in lower-level Java methods and >> indicate failures whose causes are generally not known. Examples of >> WarningExceptions are authentication failures, entering the wrong >> hostname, trying to connect to a display that has no VNC server running >> on it, losing the connection due to a network hiccup or the server being >> shut down, etc. WarningExceptions display a user-friendly message with >> a yellow caution symbol instead of the red stop sign, and they don't say >> "error", even though they still result in the viewer exiting. >> ErrorExceptions also display a user-friendly message, but it has the >> traditional red stop sign and says "Error". SystemExceptions display >> the traditional unfriendly text that contains information about the >> exception class. Stack traces are only printed out for >> SystemExceptions, since, unlike the other types of exceptions, the >> origin of SystemExceptions won't be obvious from the exception text. >> >> Hopefully that will get you where you need to go. Overhauling the >> exception framework lays the groundwork for possible future >> enhancements, such as a parameter that would allow one to specify that a >> particular type of exception should not raise a dialog, and we can also >> now easily convert an exception from one type to another if you discover >> other error dialogs that you want to be made friendlier. >> >> >> On 12/11/12 3:44 PM, James Wettenhall wrote: >>> DRC, >>> >>> Yes, it would be better if a "Connection Closed" message box was >>> displayed instead of seeing the EndOfStream exception. And for less >>> common Java exceptions, I think it's reasonable to display the raw >>> Java class name in a message dialog. >>> >>> For our cloud virtual machines, instead of having the End Session >>> button seen on our HPC system's desktop (which is triggering the >>> EndOfStream exception), the user finishes by simply closing the VNC >>> window. Our application then pops up a question dialog asking whether >>> the user wants to keep their VNC session open for future use, or >>> terminate it. So this use case (the user simply closing the VNC window >>> and exiting TurboVNC) wouldn't trigger any Java message boxes, which >>> is good for us. >>> >>> Cheers, >>> James >> >> ------------------------------------------------------------------------------ >> 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-Devel mailing list >> VirtualGL-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > > > ------------------------------------------------------------------------------ > 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-Devel mailing list > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel ------------------------------------------------------------------------------ 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-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
