[kepler-dev] Splash screen and corresponding changes

[Christopher Brooks]

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