[kepler-dev] Splash screen and corresponding changes

Christopher Brooks cxh at eecs.berkeley.edu
Tue May 2 08:48:00 PDT 2006


Hi Matthew,
I decided to go with the SplashWindow class instead of SplashScreen.
SplashWindow seems more robust, it always comes up and displays
the image.  SplashScreen seemed to not always display.

The image remains the same though, so the user should not notice
any changes.

SplashWindow plays some tricks with invokeAndWait to get
the splash window to close.

KeplerApplication looks like:
    public static void main(final String[] args) {
        try {

            try {
                // FIXME: Config requires org.ecoinformatics.util
                // which introduces a problematic package dependency.
                String splashname = Config.getValue("//splash/image");
                final URL splashURL = ClassLoader.getSystemClassLoader()
                    .getResource(splashname);
                SwingUtilities.invokeAndWait(new Runnable() {
                        public void run() {
                            SplashWindow.splash(splashURL);
                        }
                    });
            } catch (Exception ex) {
                System.err.println("Failed to find splash screen image."
                        + "Ignoring, use the Java coffee cup");
                ex.printStackTrace();
            }            
            SplashWindow.invokeMain("ptolemy.vergil.VergilApplication", args);
            SplashWindow.disposeSplash();
        } catch (Throwable throwable) {
            System.err.println("Unable to start application.");
            throwable.printStackTrace();
        } finally {
            // Not sure if this is necessary.
            SplashWindow.disposeSplash();
        }
    }
}

SplashWindow.invokeMain() uses reflection to find VergilApplication
and calls invokeAndWait() on it so it runs in the Event Thread.
Then SplashWindow.disposeSplash is called and closes the splash.
I'm not totally sure why this works, but it does.

_Christopher

--------

    
    Hi Christopher -
    
    Sorry I'm just seeing this now - spent yesterday in travel hell :-)
    
    Sounds fine to me, regarding removing the "dismiss on click" functionality.
    
    Just wanted to add that I'd anticipated the new "Top" method (that 
    Edward and I were discussing) being useful for determining when the 
    splash screen should be hidden - it returns true as soon as the first 
    frame's pack() method has finished. The only complication is giving the 
    splash screen a reference to the first frame. The method is:
    
       public synchronized boolean isMenuPopulated()
    
    cheers
    
    m
    
    
    
    
    
    
    ---------------------------------------------
    Matthew Brooke, Ph.D.
    Marine Sciences Research Building, Room #3407
    University of California
    Santa Barbara, CA  93106-6150
    ph: (805) 893-7108   fx: 805-893-8062
    brooke at nceas.ucsb.edu
    ---------------------------------------------
    
    Christopher Brooks wrote:
    > I suspect other applications have splash screens that are mouse
    > sensitive as well, though I can't actually name one :-)
    > 
    > The splash screen I downloaded and the current splash screen both
    > have this functionality.  It could be that current splash screen
    > is based on the splash screen I downloaded
    > 
    > If we don't need the mouse sensitivity, then I can remove
    > the Kepler specific version of VergilApplication and we can stick
    > with the current splash screen.
    > 
    > I think this is the right thing to do.  The splash screen works
    > around a bug (slow startup) and we should avoid adding another bug
    > (gui in wrong thread). 
    > 
    > _Christopher
    > 
    > --------
    > 
    >     Ah okay.  Thanks for clearing that up.  I didn't realize the splash s
   creen
    >     was mouse sensitive and would close if you just simply clicked on it.
    >     That's not anything I spec'd or asked for from a usability perspectiv
   e.    
    >     
    >     Is there some reason we need that?  Would it be easier if it wasn't m
   ouse
    >     sensitive?
    >     
    >     Laura L. Downey
    >     Senior Usability Engineer
    >     LTER Network Office
    >     Department of Biology, MSC03 2020
    >     1 University of New Mexico
    >     Albuquerque, NM  87131-0001
    >     505.277.3157 office
    >     505.610.9657 mobile
    >     505.277-2541 fax
    >     ldowney at lternet.edu
    >      
    >     
    >     -----Original Message-----
    >     From: cxh at EECS.Berkeley.EDU [mailto:cxh at EECS.Berkeley.EDU] 
    >     Sent: Monday, May 01, 2006 2:51 PM
    >     To: Laura L. Downey
    >     Cc: 'Kepler-Dev'
    >     Subject: Re: [kepler-dev] Splash screen and corresponding changes 
    >     
    >     Hi Laura,
    >     The situatino is a tad confusing.  I mean the splash screen -
    >     the screen that comes up before the welcomne window
    >     
    >     The current default splash screen is mouse sensitive.  If you click
    >     anywhere on it, it will close.  The current default splash screen
    >     has no close button, it is just mouse sensitive.  The current default
    >     splash screen also exits at the right time - right around when
    >     the welcome window opens up.
    >     
    >     The problem is that to retain this mouse sensitivity for the 
    >     splash screen we need to be tricky about threads.  This causes
    >     buggy behaviour.
    >     
    >     
    >     _Christopher
    >     
    >     --------
    >     
    >         Hi Christopher, 
    >         
    >         I'm a little confused.  Do you mean the splash screen or the welc
   ome
    >     screen
    >        ?
    >         
    >         The splash screen should appear as soon as Kepler is launched and
    stays
    >         there until the first Kepler window and the welcome window appear
   .  At
    >     that
    >         point the splash screen should disappear on its own. There is no 
   "close
    >    "
    >         on the splash screen.  There is a "close" on the welcome screen. 
    >         
    >         
    >         Laura L. Downey
    >         Senior Usability Engineer
    >         LTER Network Office
    >         Department of Biology, MSC03 2020
    >         1 University of New Mexico
    >         Albuquerque, NM  87131-0001
    >         505.277.3157 office
    >         505.610.9657 mobile
    >         505.277-2541 fax
    >         ldowney at lternet.edu
    >          
    >         
    >         -----Original Message-----
    >         From: kepler-dev-bounces at ecoinformatics.org
    >         [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Chris
   topher
    >         Brooks
    >         Sent: Monday, May 01, 2006 2:26 PM
    >         To: Kepler-Dev
    >         Subject: Re: [kepler-dev] Splash screen and corresponding changes
    >         
    >         I took another run at the Splash Screen and the Kepler specific
    >         version of VergilApplication.
    >         
    >         The problem is that Kepler has a bug: it takes too long to start 
   up
    >         because it is pulling in all the actors.  The splash screen is an
    >         attempt at covering up that bug.  The problem is that to make the
    >         splash screen so that it will close on a mouse click, we have to 
   run
    >         parts of Kepler in the main thread and parts in the Swing Event
    >         thread.  This can cause no end of trouble. 
    >         
    >         I tried out another Splash Screen which I downloaded from
    >         http://www.randelshofer.ch/oop/javasplash/javasplash.html
    >         If you do a cvs update and
    >         then run
    >           rm src/exp/ptolemy/vergil/VergilApplication.java
    >           ant clean
    >           ant run-splash
    >         then maybe the new splash screen will work for you.
    >         The one problem is that the splash window will not close
    >         if you click on it.  One advantage of this splash screen is
    >         that it closes when the first window comes up.  Also, it
    >         does not have a Kepler specific version of VergilApplication
    >         and everything runs in the event thread.
    >         
    >         I see the following possible solutions:
    >         1) Stick with Kevin's splash screen.
    >         This uses a custom VergilApplication, which has the bugs
    >         I mention below.  Also, I think this splash closes before
    >         the app starts up.  However, this splash is mouse
    >         sensitive.
    >         
    >         2) Fix the start up problems.  This will not happen
    >         before the release.  Maybe we can call Thread.yield()
    >         every time?  I looked at KSWLibraryBuilder and the
    >         problem is that VergilApplication calls KSWLibraryBuilder
    >         and needs the return value from KSWLibraryBuilder
    >         to proceed.  This is presumably one of the reasons
    >         Kevin modified VergilApplication so that parts
    >         of it run in the Swing event thread and parts do not.
    >         
    >         3) Go with the new start up, which is not mouse 
    >         sensitive, but does not have the custom VergilApplication
    >         and the potential bugs of not running in the Swing
    >         Event thread.
    >         
    >         Personally, since the splash screen is there to cover up
    >         a bug (long startup), I'd rather go with #3 and just
    >         deal with the splash screen not being mouse sensitive.
    >         
    >         I'm not comfortable folding the Kepler version of VergilApplicati
   on
    >         in to the Ptolemy tree - I think it is buggy because not
    >         everything is running in the Swing event thread
    >         
    >         BTW - once we decide what to do, we should pull one
    >         or the other of the splash screens
    >         
    >         Comments?
    >         
    >         _Christopher
    >         
    >         
    >         --------
    >         
    >             Hi Kevin,
    >             I'm trying to merge the Kepler exp version of VergilApplicati
   on bac
    >    k
    >             in to the Ptolemy tree.
    >             
    >             The thread is long and convoluted, but the summary is the the
    >     Ptolemy
    >             version call invokeLater() in VergilApplication.main().  Your
    >     version
    >             calls invokeLater in a couple of places instead of main().
    >             
    >             What was the precise bug that you were seeing that was fixed 
   by
    >             changing VergilApplication?  The splash screen seems fairly
    >     responsive
    >             if I use the Ptolemy version of VergilApplication.  I want
    >             to be sure I see the bug before I do anything.
    >             
    >             One issue I'm seeing in the Kepler version is that when we pa
   rse th
    >    e
    >             welcome URL:
    >                         _parser.parse(welcomeURL, welcomeURL);
    >             We may need to put that inside invokeLater because it ends up
    >     bringing
    >             up the welcome URL.  We would need to do this in two places.
    >             
    >             One issue I'm facing is that when I was experimenting setting
    the
    >             Windows icon, the icon was not fully rendering.  This points 
   to
    >             a thread problem.  Indeed, the TableauFrame._getDefaultIconIm
   age()
    >             method was getting called outside the Swing event thread.  Ho
   wever,
    >             putting it inside the event thread has no yet solved it for m
   e.
    >             It could be operator error on my part, but it makes me suspic
   ious.
    >             
    >             Nandita suggested using this as a workaround:
    >               setIconImage(new BufferedImage(1, 1,
    >     BufferedImage.TYPE_INT_ARGB));
    >             
    >             
    >             _Christopher
    >             
    >             On Tue, 14 Feb 2006 19:52:16 -0600, Kevin wrote:
    >             > 
    >             > 
    >             > I've certainly seen many poorly written ui's with redraw bu
   gs.
    >         Without 
    >             > the source code, we can only rely on the documentation.   I
   t is
    >     rathe
    >        r
    >         
    >             > unfortunate that Sun recommends creating the entire UI in t
   he
    >     event 
    >             > handler thread (note the big red footnote in 
    >             > http://java.sun.com/docs/books/tutorial/uiswing/misc/thread
   s.html
    >    )
    >         Such 
    >             > a requirement completely eliminates the possibility of doin
   g
    >     things
    >         like 
    >             > a splash screen.  I do hope that they cleaned this up for M
   ustang
    >         since 
    >             > they are releasing splash code in that release.
    >             > 
    >             > BTW - after I removed invokeLater completely from 
    >             > VergilApplication.main() the application rendered all three
    >     initial 
    >             > windows (splash, empty graph tableau, and welcome html)
    >     flawlessly.  
    >             > Perhaps the issues you've had were with previous releases o
   f
    >         awt/swing.
    >             > 
    >             > Kevin
    >             > 
    >             > Edward A. Lee wrote:
    >             > > At 09:13 AM 2/14/2006, Kevin Ruland wrote:
    >             > >>  However, separate thread can construct new Swing compon
   ents,
    >     but 
    >             > >> once they are displayed all interaction with the compone
   nt -
    >         through 
    >             > >> display, keyboard or mouse events - must be through the 
   event
    >         handler.
    >             > >
    >             > > I don't think this is true...
    >             > > I have seen rendering artifacts when swing components are
    >             > > constructed in other threads...
    >             > >
    >             > > Edward
    >             
    >             
    >             
    >             > Christopher Brooks wrote:
    >             > 
    >             >> Hi Kevin
    >             >> Sorry, we don't have particular test cases.
    >             >>
    >             >> You could try running the demo in $PTII/demo, which starts
    up
    >         multiple
    >             >> vergil processes.
    >             >>
    >             >> I'm afraid I don't have the time to do a detailed analysis
    befor
    >    e
    >     I
    >             >> go.  Sorry.  This is sort of lame on my part, but other ta
   sks
    >     call.
    >             >>
    >             >> _Christopher
    >             >>
    >             >> --------
    >             >>
    >             >>    Christopher,
    >             >>    
    >             >>    These changes are perhaps quite a bit safer since they 
   indeed
    >     put
    >         the
    >             >>    gui parts in invokeLater.  The two calls I refer to are
    the
    >         display o
    >            f
    >             >>    the documentation effigy and the createPrimaryTableau()
    calls
    >    .
    >         Both 
    >            of
    >             >>    these methods are pretty heavy and do cause the Splash 
   to
    >     become
    >             >>    non-responsive.
    >             >>    
    >             >>    Without great analysis of where pack(), or show() or
    >         setVisible(true)
    >             is
    >             >>    first called in the various tableau classes, I don't kn
   ow how
    >     muc
    >        h
    >         fi
    >            ner
    >             >>    grained we can get.  My gut feeling is
    >             >>    Configuration.createPrimaryTableau() should really call
    >         Tableau.show(
    >            )
    >             >>    only in the event handler thread.  But that would be a 
   much
    >     deepe
    >        r
    >             >>    change than I am comfortable with.
    >             >>    
    >             >>    Do you have any bug reports or test cases which were fi
   xed by
    >         placing
    >             >>    VergilApplication(String[]) in invokeLater()?  That wou
   ld hel
    >    p
    >     me
    >         out
    >            .
    >             >>    
    >             >>    Kevin
    >             _______________________________________________
    >             Kepler-dev mailing list
    >             Kepler-dev at ecoinformatics.org
    >      
    >     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-
   de
    >        v
    >         --------
    >         _______________________________________________
    >         Kepler-dev mailing list
    >         Kepler-dev at ecoinformatics.org
    >         http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kep
   ler-de
    >    v
    >     --------
    >     
    >     _______________________________________________
    >     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
--------


More information about the Kepler-dev mailing list