[kepler-dev] Splash screen and corresponding changes

[Christopher Brooks]

Hi Matt,
Thanks, I must have missed the announcement.
 
I'll take a shot at this.  Kevin made some good points about using
invokeLater at a finer granularity of VergilApplication, but I suspect
that since the splash screen is now started in KeplerApplication, that
we might be able to revert to the monolithic VergilApplication.

_Christopher

--------

    Christopher,
    
    Kevin is no longer with SEEK -- he took another job.  We'll have to 
    piece together his rationale for these changes from his emails on the 
    subject (see the kepler-dev archive), cvs logs, and code. Sorry.
    
    Matt
    
    Christopher Brooks wrote:
    > 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 rather 
    >>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 much 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 deeper
    >>>   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-dev
    
    -- 
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Matt Jones                                   Ph: 907-789-0496
    jones at nceas.ucsb.edu                    SIP #: 1-747-626-7082
    National Center for Ecological Analysis and Synthesis (NCEAS)
    UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------