[kepler-dev] Splash screen and corresponding changes
Kevin Ruland
kruland at ku.edu
Tue Feb 14 09:13:19 PST 2006
This is completely true. However, separate thread can construct new
Swing components, but once they are displayed all interaction with the
component - through display, keyboard or mouse events - must be through
the event handler. The problem with the way the code is written now is,
invokeLater is called with a runnable which takes ~20-30 seconds to
complete. This entire process is executed in the event handler thread
as one uninterruptable unit which causes the UI (in this case, only the
splash screen) to become completely non-responsive to external events
such as mouse clicks or expose events.
I believe the entire VergilApplication() constructor can execute outside
of the Swing event handler thread because none of the swing components
are accessed after they are shown.
VergilApplication._createEmptyConfiguration() calls
Configuration.createPrimaryTableau() - the last call is tableau.show()
which displays the constructed swing componets. From this point on all
interaction with the effigy must be through the Swing event handler.
Indeed _createEmptyConfiguration does not manipulate the effigy.
Once _createEmptyConfiguration() returns to MoMLApplication._parseArgs,
Configuration.showAll() is executed which then shows the intro.html
file. Again, this process does not interact with the underlying effigy
after its display.
I don't have a complete background to the ptolemy code history and I
don't know what bugs were fixed by putting VergilApplication()
constructor in invokeLater(). Perhaps there are some test cases you
have lying about which can validate or invalidate this observation.
Kevin
Edward A. Lee wrote:
>
> Note that the spec for AWT and Swing says that _all_ screen, keyboard,
> and mouse interactions must occur in the Swing thread. If you are not
> doing this splash screen in the event thread, it will never work
> reliably.
>
> When people at Sun first developed AWT, it was to be the first major
> application of Java's multithreading. In the first few alpha releases
> of Java, AWT was multithreaded. But it was so buggy that it couldn't
> be used. Sun gave up and made the UI single threaded. They simply
> couldn't get it to work...
>
> ...I powerful indictment against threads as a programmers' model.
>
> Edward
>
> At 01:28 PM 2/13/2006, Kevin Ruland wrote:
>
>> It seems that the splash works almost not at all right now. On mac's it
>> throws some nasties (indications are a problem with jai_imageio.jar on
>> the mac), Under windows, it doesn't refresh correctly - pull a window
>> to the foreground in front of the splash, then pull the splash to the
>> foreground - see?
>>
>> I suspect the problem is with the way VergilApplication kicks things
>> off. My understanding of invokeLater() is the entire runnable is queued
>> into the event queue and executed by the event queue as one big chunk --
>> at least until the moml is parsed and a swing component (TableauFrame?)
>> is opened. I'm thinking this event is really too big for the event
>> queue and ends up causing the refresh events to queue.
>>
>> My first attempt at making this work was to try to pop up the splash
>> from inside the KeplerInitializer code. This was executed as part of
>> the invokeLater() task. It also didn't work.
>>
>> My current thinking is, the only way to get this to work correctly is to
>> have some fairly extensive support from VergilApplication. I think what
>> needs to be done is to pull the invokeLater() call out of
>> VergilApplication.main() and instead use invokeLater()'s in
>> VergilApplication._createEmptyConfiguration() where the various effigies
>> are created. I saw some comments in
>> Configuration.createPrimaryTableau() which appeared to indicate ptolemy
>> used to be coded along these lines.
>>
>> The first experiment (removing the invokeLater from main()) was
>> promising. Now to coerce VergilApplication._createEmptyConfiguration()
>> to use invokeLater().
>>
>> Kevin
>>
>> Christopher Brooks wrote:
>> > I was thinking that perhaps your dispose() call is running
>> > in a thread other than the Swing event thread.
>> >
>> > I'm not much of a ui guy, but I've had a world of hurt about running
>> > things outside the Swing Event Thread.
>> >
>> > Check out this article:
>> > http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
>> > It is old, but it might still apply.
>> >
>> > I found it via
>> > http://java.sun.com/products/jfc/tsc/articles/index.html
>> > Search for "Thread". There is also some stuff about Timers and Swing.
>> >
>> > In the perfect world, I'd like to see the splash screen changes in
>> > VergilApplication or MoMLApplication so that we can use the splash
>> > screen there. We could use the "Look for an image file adjacent to
>> > the configuration file" hack to avoid needing to read the
>> > configuration first. Since PtExecuteApplication probably does not
>> > want a splash screen, then probably VergilApplication is the right
>> > place.
>> >
>> > However, I certainly understand why having a KeplerMain is a win
>> > for Kepler and am a little surprised that Kepler still uses
>> > VergilApplication.
>> >
>> > Anyway, I think these changes are a basic win. Having a splash
>> > screen helps and having how we start up with a blank empty Graph
>> > Editor is a win.
>> >
>> >
>> > _Christopher
>> >
>> >
>> >
>> >
>> > --------
>> >
>> >
>> > 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.getSystemLookAndFeelClassN
>> > ame());
>> > > 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 runni
>> > ng
>> > > 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 anyth
>> > ing
>> > > so you're not missing out), you will need to change your
>> main from
>> > > VergilApplication to KeplerApplication. I have made the
>> correspondin
>> > g
>> > > changes to build.xml's various targets which used to use
>> VergilApplic
>> > ation.
>> > >
>> > > 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 m
>> > ore
>> > > with command line arguments. For example, we could hard
>> code the
>> > > '-kepler' argument into our main when envoking
>> VergilApplication. Al
>> > so
>> > > we can combine the VergilApplication and
>> PtExecuteApplication startup
>> > s
>> > > 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. Ca
>> > n
>> > > 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
>> > > --------
>> > >
>> > --------
>> >
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
More information about the Kepler-dev
mailing list