Going direct on the Mac (or everywhere) desktop app, not applet

[Jacob Anawalt]

Hi,

I'm appreciating the flexibility and simplicity of the  Getdown update code but I am starting to wonder if I need it to be more integrated instead of running it stand-alone.

I'm working on packaging what has so far been a Java Web Start deployed app for Mac OS X and I've made some good progress. Things look well as I launch the application and it downloads updates during the splash screen, but then when JavaAppLauncher launches my application in a new JVM and exits the Dock switches from showing my bundled app to showing the Java coffee cup and if I try to Keep in Dock then the icon switches to a terminal exec window and clicking it launches the java command in a new terminal.

It seemed like the quick solution to this was to use the undocumented direct property (-Ddirect=true), but when I try that I get a NPE stack trace:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at javax.swing.MultiUIDefaults.getUIError(MultiUIDefaults.java:130)
at javax.swing.UIDefaults.getUI(UIDefaults.java:760)
at javax.swing.UIManager.getUI(UIManager.java:1016)
at javax.swing.JPanel.updateUI(JPanel.java:126)
at javax.swing.JPanel.<init>(JPanel.java:86)
at javax.swing.JPanel.<init>(JPanel.java:109)
at javax.swing.JPanel.<init>(JPanel.java:117)
at javax.swing.JRootPane.createGlassPane(JRootPane.java:546)
at javax.swing.JRootPane.<init>(JRootPane.java:366)
at javax.swing.JFrame.createRootPane(JFrame.java:286)
at javax.swing.JFrame.frameInit(JFrame.java:267)
at javax.swing.JFrame.<init>(JFrame.java:234)
at com.threerings.getdown.launcher.k.createContainer(Unknown Source)
at com.threerings.getdown.launcher.e.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Is using direct on a non-applet context a workable solution? Maybe this has been written up somewhere that I could read and learn more. Unfortunately most Google searches for Getdown plus other terms seem to focus on the other terms.

Thank you,

-- 

Jacob

[Michael Bayne]

On Thu, Dec 17, 2015 at 1:24 PM, Jacob Anawalt <jlan...@gmail.com> wrote:

Things look well as I launch the application and it downloads updates during the splash screen, but then when JavaAppLauncher launches my application in a new JVM and exits the Dock switches from showing my bundled app to showing the Java coffee cup and if I try to Keep in Dock then the icon switches to a terminal exec window and clicking it launches the java command in a new terminal.

I think we've used:

    -Xdock:name=<application name>"

                      override default application name displayed in dock

    -Xdock:icon=<path to icon file>

                      override default icon displayed in dock

in the past to make this work. These would be in your getdown.txt.

I'll try to address your other questions as soon as I can, but I'm knee deep in other stuff.

-- m...@samskivert.com

[Michael Bayne]

On Thu, Dec 17, 2015 at 2:33 PM, Michael Bayne <m...@samskivert.com> wrote:

I think we've used:

    -Xdock:name=<application name>"

                      override default application name displayed in dock

    -Xdock:icon=<path to icon file>

                      override default icon displayed in dock

in the past to make this work. These would be in your getdown.txt.

But even this is kind of a hack. As you say, it would probably be better if we could use the JavaApplicationStub to make this work. It would be nice if there was a way to use the same JavaApplicationStub and just configure it to use an Info.plist that ran Getdown versus an Info.plist that ran your app.

But -Ddirect=true should also solve these problems, so I'm not sure why you're running into trouble there. That should work.

-- m...@samskivert.com

[Michael Bayne]

On Thu, Dec 17, 2015 at 2:40 PM, Michael Bayne <m...@samskivert.com> wrote:

But -Ddirect=true should also solve these problems, so I'm not sure why you're running into trouble there. That should work.

I made a simple test app that runs a JavaFX app, and tried that with -Ddirect=true and it pretty much works (I had to fix some bugs, but none that should have been causing the problem you had).

In any case, maybe give that test app a whirl and see if that works for you and if it sheds any light on the errors you're seeing with -Ddirect=true:

https://github.com/threerings/getdown-testapp

-- m...@samskivert.com

[Jacob Anawalt]

On Friday, December 18, 2015 at 12:41:44 PM UTC-7, Michael Bayne wrote:

I made a simple test app that runs a JavaFX app, and tried that with -Ddirect=true and it pretty much works (I had to fix some bugs, but none that should have been causing the problem you had).

In any case, maybe give that test app a whirl and see if that works for you and if it sheds any light on the errors you're seeing with -Ddirect=true:

Thank you for the quick response and test project. I was in the middle of getting it out the door and am not a Mac (I'm on OS X El Capitan 10.11.2) or Maven pro so it took a bit to get back to you on this.

I ran into a snag building getdown-testapp that took me some guessing to work around.

[WARNING] The POM for com.threerings:getdown:jar:1.6-SNAPSHOT is missing, no dependency information available

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 6.382 s

[INFO] Finished at: 2016-01-12T14:26:16-07:00

[INFO] Final Memory: 12M/115M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal on project testapp: Could not resolve dependencies for project com.threerings.testapp:testapp:jar:1.0-SNAPSHOT: Could not find artifact com.threerings:getdown:jar:1.6-SNAPSHOT -> [Help 1]

After looking around trying to sort that out on a whim and using targets I had read about I cloned getdown and did mvn install from there then returned back and the mvn project target worked. Executing the java -jar command worked:

java -jar target/testapp/getdown-new.jar target/testapp

Running this I see the default java icon from the java command, then I see the icon and such from Getdown Test App and then the Java icon disappears. This is similar to, yet in reverse order of, what I see with my JavaAppLauncher based program and the reasons for that make sense to me. As you say if I worked on setting the dock name and icon it would be less noticeable when my app runs. (Except, I think, for the case where the app is kept on the dock.)

Then I launched again with the direct flag.

java -Ddirect=true -jar target/testapp/getdown-new.jar target/testapp

Again I see the Getdown Test App and no crash so I should study the code and see what I missed that causes mine to crash. The Getdown splash screen does not go away though. It's been sitting at 99% complete with "Launching ..." animation the whole time I've been composing this message. Does that happen for you?

Thank you again for your input and the test program to review,

-- 

Jacob

[Michael Bayne]

On Tue, Jan 12, 2016 at 1:56 PM, Jacob Anawalt <jlan...@gmail.com> wrote:

Again I see the Getdown Test App and no crash so I should study the code and see what I missed that causes mine to crash. The Getdown splash screen does not go away though. It's been sitting at 99% complete with "Launching ..." animation the whole time I've been composing this message. Does that happen for you?

That doesn't happen for me, but it could be a race condition, because Getdown doesn't open the download window if the download happens fast enough.

Someone just sent a pull request that forces the download window to be closed when running in -Ddirect=true mode, so that should probably fix that problem.

-- m...@samskivert.com

[Marius Merkevičius]

I can definitely confirm that there is a race condition when "allow_offline = true", and using "direct=true". 

The bug seems to persist even in 1.6-SNAPSHOT as i've compiled the library myself. 

Even though i did not look into deep how to manage threading, i've fixed up myself a workaround the problem by inserting "Thread.sleep(1000)" just before https://github.com/threerings/getdown/blob/master/src/main/java/com/threerings/getdown/launcher/Getdown.java#L484, to make sure launch would happen after the update process. 

I can't make a pull request out of this, as this does not solve a problem, but just a hacky way to workaround the problem, maybe someone might find it useful (as this served my process  of finding out a problem).