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
