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
