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

Reply via email to