[kepler-dev] Splash screen and corresponding changes

[Kevin Ruland]

I wasn't completely clear, but KeplerApplication is not a class as much 
as a main() container.  KeplerApplication has no functionality unto 
itself.  It possesses a single main() method which kicks off the Splash, 
then forwards all the arguments on to VergilApplication.

Off hand, I don't know if subclassing MoMLApplication (or any of the 
others) is really necessary.  For the added functionality I eluded to 
down below, I was only thinking of manipulating the args and passing on 
to the main() in the proper MoMLApplication implementation.

One big benefit I have found of having KeplerApplication control the 
splash display is the splash is not displayed when running ptexecute.  
So the mechanism we were using to execute in batch mode does not 
necessarily clutter the display with a bunch of windows.  If I could 
magically get the splash to work in KeplerInitializer, then it would be 
displayed in both PtExecuteApplication and VergilApplication (and any 
other MoMLApplication derived startup).

Kevin

Christopher Brooks wrote:
> Hi Kevin,
>
> VergilApplication probably invokes invokeLater to avoid problems
> with running Swing code in the main thread.  We've had this problem
> in the past and putting Swing code in invokeLater() has helped.
>
> For example, if we have a model that invokes VergilApplication over
> and over for separate models then we need to be sure that we invoke
> the Swing code in the right thread.
>
> So, I suspect that if the splash is not operating properly
> when within the invokeLater block, then there are other problems.
>
> We could put the splash code inside VergilApplication,  though I
> have two concerns:
> 1) How do we specify which splash screen (if any) to use?
> If we specify it in the configuration, then there could be
> a delay while we initialize all the classes.
>
> To solve this, we could just look for a specific file next to the
> configuration and if it is present show it.
>
> 2) We need a way to not display the splash screen.  For example,
> if we are running lots of demos by starting Vergil from a model,
> like we do in the Chess kiosk by running the demo in ptII/demo,
> then we probably don't want the splash screen each time.
>
> So, we should probably have a -nosplash argument.  -q
> is taken by $PTII/bin/ptinvoke to not display the command
> line args, so we can't use -q unless we decide to add
> it to the base classes (MoMLApplication?)
>
>
> Subclassing VergilApplication for Kepler has its appeal, since
> it means you can run without the -kepler option.  The one
> disadvantage is that it is yet another class to maintain.
> Also, it means that VergilApplication does not have the
> ability to have a splash screen or other Kepler specific
> changes.  I'd like to see VergilApplication updated to
> meet Kepler's needs, since presumably other projects
> (HyVisual, VisualSense, Viptos) could use extensions like
> splash screens.
>
> I think that instead of using PtExcecuteApplication, you
> might want to be using MoMLSimpleApplication more.  The reason
> is that MoMLSimpleApplication does not invoke any Swing classes
> so it does not require an X11 display.  In grid computing,
> I suspect that not requiring X11 could be a big win.
> PtExecuteApplication requires a gui because it extends
> MoMLApplication with invokes
>             UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> in the constructor.
>
> I'm not sure if you can successfully have KeplerApplication
> have a switch between VergilApplication and MoMLSimpleApplication.
> It might work, or it might invoke Swing. They way to check
> is to run with $DISPLAY not set.  
>
> Anyway, I'm not opposed to having a KeplerApplication class,
> I've been toying with the idea of having one, but have
> had some hesitation because of the above.  I think
> having a separate KeplerApplication class could be important
> for branding purposes, but the sponsors (people who
> control $$) would probably never realize or understand
> the difference between having KeplerApplication and
> not having it.
>
>
> BTW - How we handle this in Ptolemy is that in $PTII/bin
> we create a link to the ptinvoke script and the use a switch
> statement that checks $0.  So, $PTII/bin/viptos is a symbolic
> link to $PTII/bin/ptinvoke.  ptinvoke checks $0 and invokes
> the appropriate arguments.  This requires use of shell,
> so it only works for Cygwin and Linux users.  Eclipse
> users have to invoke the VergilApplication with the right
> args.  
>
>
> _Christopher
>
>
>
>
> --------
>
>     Hi all.
>     
>     The only way for me to get the splash screen to work correctly was to 
>     build our own main loop which builds the splash screen prior to running 
>     VergilApplication.main.  I think the reason for this is 
>     VergilApplication runs everything using Swing.invokeLater which seems to 
>     do something weird with the thread priorities and ends up making the 
>     splash behave very badly.  So I created the 
>     org.kepler.gui.KeplerApplication so do just that.
>     
>     I'm writing this note to inform people that if they are running under 
>     eclipse and want to see the splash screen (It doesn't really do anything 
>     so you're not missing out), you will need to change your main from 
>     VergilApplication to KeplerApplication.  I have made the corresponding 
>     changes to build.xml's various targets which used to use VergilApplication.
>     
>     One thing to think about in the future, since we need to have our own 
>     main for this purpose, this provides us with a place to do a little more 
>     with command line arguments.  For example, we could hard code the 
>     '-kepler' argument into our main when envoking VergilApplication.  Also 
>     we can combine the VergilApplication and PtExecuteApplication startups 
>     and provide another switch to run "head-less" or "batch" mode.  What I 
>     mean is we could interpret an argument like "-batch" as an indication to 
>     run PtExecuteApplication instead of VergilApplication.
>     
>     I was able to test the auto_kepler.bat and ptexecute.bat files here, but 
>     for some reason auto_kepler.sh doesn't seem to work under cygwin.  Can 
>     somebody please check that script?
>     
>     Kevin
>     _______________________________________________
>     Kepler-dev mailing list
>     Kepler-dev at ecoinformatics.org
>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------
>