[kepler-dev] Splash screen and corresponding changes

Christopher Brooks cxh at eecs.berkeley.edu
Mon May 1 14:51:57 PDT 2006


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 screen
    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 perspective.    
    
    Is there some reason we need that?  Would it be easier if it wasn't mouse
    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 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 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 parse 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._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 befor
   e
    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 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/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