DRC, Thanks for the update, sounds promising!
I have a snow leopard Mac mini at home, but I don't have a 10.6 test machine / VM at work - I'll try to get a 10.6 VM set up on my work laptop ASAP, so that I can more easily test how to detect lack of full-screen functionality in Java Swing. Cheers, James On 24/02/2013, at 8:53 PM, DRC <dcomman...@users.sourceforge.net> wrote: > I was able to get funding to implement this and have been working on it > over the past few days (most of that work involved upgrading my > development machine to Mountain Lion and then setting up a Snow Leopard > VM for backward compatibility testing.) The implementation is almost as > simple as you said, because in fact the Apple full-screen mode seems to > take care of a lot of the logic (re-creating scrollbars, remembering the > non-full-screen window position, etc.) that we were doing ourselves in > the TurboVNC code. > > I've run into one setback, though. Because the methods in > com.apple.eawt.FullScreenUtilities behave normally but "do nothing" on > Snow Leopard and prior, as opposed to throwing an exception, and because > those methods do not provide any return value or other state, there is > no way to determine whether or not the system actually supports the > full-screen extensions. This is important because, on Snow Leopard and > prior, the TurboVNC Viewer still needs to use the old emulated > full-screen mode (it has its limitations, but it's at least usable if > you have your dock set to auto-hide.) > > I could check os.version and assume that if it's >= 10.7, the > full-screen extensions should be used, but this seems error-prone. > > Hoping you may have some insight, because I'm stumped. I even thought > of perhaps using the full-screen listener, which is set up anyway so I > can change the state of the menu check boxes, but since the listener is > fired asynchronously, there is no way of knowing whether its failure to > fire is due to the extensions being unavailable or whether it simply > hasn't gotten around to it yet. > > So frustrating. > > On 2/20/13 11:04 PM, James Wettenhall wrote: >> DRC, >> >> Thanks for your reply, and thanks for all of the hard work that's gone >> into TurboVNC 1.2 beta1. :-) >> >> On 21/02/2013, at 1:54 PM, DRC wrote: >> >>> Gee, thanks, Apple. Any idea what other open source projects are doing >>> to work around this? >> >> No. I only came across it recently. But Oracle's guidelines for >> packaging a Java App for Distribution on a Mac mention the need for >> code-signing: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html >> >> It's frustrating that Apple, OpenJDK and Oracle are taking so long to >> sort out the transition from Apple supplying Java Runtime Environments >> to Oracle supplying them. The Apple-supplied JRE is based on Java 1.6 >> which is supposed to reach its end of life this month. The recommended >> approach is now to bundle a JRE into your application, but if you bundle >> Oracle's binary JRE, then your application can't be GPL, i.e. you need to >> build OpenJDK from source to make it GPL. >> >>>> com.apple.eawt.Application.getApplication().requestToggleFullScreen(turboVncViewport); >>> >>> Where are you calling that function? Presumably, it should go in >>> CConn.recreateViewport(). >> >> Not from any existing TurboVNC class. We had a go at rewriting our >> application in Java Swing, instead of wxPython so we could do stuff >> like full-screen ourselves without having to bug you. But that has been >> put on hold for now, maybe indefinitely, i.e. we're returning to our >> wxPython GUI development which calls TurboVNC using >> command-line arguments. I can point you to our Java code if you like. >> >> Our approach was that once the VNC viewport was visible, we wouldn't >> promise to support any of the interactive functionality of TurboVNC >> (pop-up dialogs etc.) in full-screen mode. All we did was add the >> full-screen button to the window's title bar, so that users could toggle >> full-screen mode themselves. Then they could use built-in Mac OS X >> functionality, e.g. a 3-finger swipe on a track-pad to switch between >> their Mac Desktop and their VNC Desktop, which some of them >> thought was pretty cool. >> >>> -- When requesting full-screen mode through the app, it will call >>> Application.requestToggleFullScreen() if that function is available >>> (determining whether it's available in a manner that will still compile >>> on non-Mac platforms is tricky. It requires using Reflect.) >> >> Yes, understood. >> >>> -- Presumably, the app needs to also call setWindowCanFullScreen() on >>> the Viewport when it is created. >> >> Yes, after checking for OS version. >> >>> -- Ideally, the app would also need to trap the full-screen events so >>> that, when the full-screen gadget is used, it will resize the viewport >>> properly and correctly set the full-screen state, etc. >> >> Catching the events isn't too difficult (apart for the Reflect stuff), but >> implementing the event-handlers nicely wouldn't be trivial. >> >> In our proof-of-concept, we didn't provide any support for altering the >> geometry of an existing VNC session. Our app detects the client >> resolution to determine the default VNC geometry, and then gives the >> user the option to overwrite it within our GUI before creating the VNC >> session using an SSH API. If you're talking about client-side >> auto-scaling, then the user-instigated full-screen mode will trigger >> a resize event which can be detected with a ComponentListener >> >>> I'm afraid it's just too complicated for me to do pro bono. If one of >>> my customers runs into this issue, perhaps they will be interested in >>> funding it. >> >> Understood. Thanks for explaining the difficulties. It sounds like this >> will end up in the too-hard basket for now, because we can't offer to >> sponsor its development. >> >> If by some miracle, I think of an easy work-around to the difficulties >> you have raised, and have time to submit a code offering and a test >> plan for it, I'll let you know. :-) >> >> All the best, >> James >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> >> >> >> _______________________________________________ >> VirtualGL-Devel mailing list >> VirtualGL-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel >> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > VirtualGL-Devel mailing list > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
