[kepler-dev] Splash screen and corresponding changes

Christopher Brooks cxh at eecs.berkeley.edu
Mon May 1 13:51:07 PDT 2006


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 welcome 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 Christopher
    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 VergilApplication
    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 VergilApplication back
        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 parse the
        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._getDefaultIconImage()
        method was getting called outside the Swing event thread.  However,
        putting it inside the event thread has no yet solved it for me.
        It could be operator error on my part, but it makes me suspicious.
        
        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 bugs.
    Without 
        > the source code, we can only rely on the documentation.   It is rathe
   r
    
        > unfortunate that Sun recommends creating the entire UI in the event 
        > handler thread (note the big red footnote in 
        > http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html)
    Such 
        > a requirement completely eliminates the possibility of doing things
    like 
        > a splash screen.  I do hope that they cleaned this up for Mustang
    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 of
    awt/swing.
        > 
        > Kevin
        > 
        > Edward A. Lee wrote:
        > > At 09:13 AM 2/14/2006, Kevin Ruland wrote:
        > >>  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.
        > >
        > > 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 before I
        >> go.  Sorry.  This is sort of lame on my part, but other tasks 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 know 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 fixed by
    placing
        >>    VergilApplication(String[]) in invokeLater()?  That would help 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/kepler-dev
--------


More information about the Kepler-dev mailing list