DRC,
This document:
http://developer.apple.com/library/mac/releasenotes/Java/JavaLionUpdate1SnowLeopardUpdate6RN/JavaLionUpdate1SnowLeopardUpdate6RN.pdf
makes it clear that
- The Java full-screen mode functionality for Mac OS X was introduced in Java
version 1.6.0_29.
- The full-screen API "does nothing on OS X v10.6 Snow Leopard".
So you could do something like this:
String javaVersion = System.getProperty("java.version");
String[] javaVersionStringComponents = javaVersion.split("_");
int javaUpdateNumber = Integer.valueOf(javaVersionStringComponents[1]);
javaVersionStringComponents = javaVersion.split("\\.");
int javaMinorVersionNumber = Integer.valueOf(javaVersionStringComponents[1]);
String osVersion = System.getProperty("os.version");
String[] osVersionComponents = osVersion.split("\\.");
int osMinorVersionNumber = Integer.valueOf(osVersionComponents[1]);
boolean fullScreenModeSupported = false;
if (osMinorVersionNumber>=7 && javaMinorVersionNumber>=7)
fullScreenModeSupported = true;
if (osMinorVersionNumber>=7 && javaMinorVersionNumber==6 && javaUpdateNumber >=
29)
fullScreenModeSupported = true;
Cheers,
James
On 25/02/2013, at 8:05 AM, DRC wrote:
> The latest pre-release build
> (http://virtualgl.sourceforge.net/vnc.nightly/) has my current attempt
> at making it work by parsing os.version. Maybe that's good enough and
> just needs to be thoroughly tested, but I'm definitely open to a more
> robust method of detecting full-screen support if there is one.
>
> The pre-release build contains more Java fixes-- opening .vnc files in
> the finder (or dragging & dropping them onto the TurboVNC Viewer icon)
> now works, the viewer now integrates with the application menu for
> handling the "About" and "Preferences" options instead of having a
> separate menu for these, and it should now work properly with Java 1.5
> (and consequently with Leopard and Tiger.)
>
> As far as a Snow Leopard VM, I discovered through trial and error that
> such is not a trivial task. I highly recommend reading the following
> pages if you plan to install it in VirtualBox:
>
> http://techventura.wordpress.com/2012/12/03/installing-mac-os-x-snow-leopard-on-virtualbox-4-2/
> http://www.insanelymac.com/forum/topic/243727-virtualbox-40-snow-leopard-1066-post-installation-with-xcodeios-sdk-42/
>
> VBox's EFI can't boot Snow Leopard, so I had to disable the EFI and use
> iBoot to boot the OS X install DVD. Then, once 10.6.3 was installed, I
> had to use iBoot again to boot the hard drive. Updating to 10.6.8
> killed my mouse (see second page above for handy tips on how to navigate
> OS X with the keyboard-- it was news to me), so I had to install
> "Drivers & Bootloaders"-->"Kexts & Enablers"-->"Miscellaneous"-->"IOUSB
> Family Rollback" from Multibeast (link for Multibeast is in the first
> page linked to above.) I also installed the "Easybeast" option in
> Multibeast, as well as the "Chimera" bootloader in order to make VBox
> boot the hard drive properly. Once all of this was done and all of the
> available OS X updates were installed, things mostly worked. The VM
> tends to lock up when shutting down or rebooting, requiring me to either
> "power off" or "reset" it. I've also noticed that, on at least two
> occasions, when there was a high amount of disk activity on both the
> host and the guest, the host would lock up and just spin the beach ball
> forever. No idea whether that's a VirtualBox issue or a Mountain Lion
> issue. Once that happened the second time, I de-selected the "Use host
> I/O cache" option in VBox, but it's unknown whether that will address
> the issue in the long term.
>
> Good luck!
>
> On 2/24/13 5:01 AM, James Wettenhall wrote:
>> 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
>>
>
> ------------------------------------------------------------------------------
> 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
