[kepler-dev] Splash screen and corresponding changes

[Christopher Brooks]

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
--------