[kepler-dev] Splash screen and corresponding changes

[Matt Jones]

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 of
>>>   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 finer
>>>   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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~