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

Reply via email to