[kepler-dev] Splash screen and corresponding changes
cxh at eecs.berkeley.edu
Tue Apr 18 18:04:12 PDT 2006
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.
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.
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));
> 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
>>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.
>>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...
>>Christopher Brooks wrote:
>>>Sorry, we don't have particular test cases.
>>>You could try running the demo in $PTII/demo, which starts up multiple
>>>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.
>>> 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
>>> the documentation effigy and the createPrimaryTableau() calls. Both
>>> these methods are pretty heavy and do cause the Splash to become
>>> Without great analysis of where pack(), or show() or setVisible(true)
>>> first called in the various tableau classes, I don't know how much fi
>>> 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
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
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
More information about the Kepler-dev