[kepler-dev] Splash screen and corresponding changes

Mon May 1 13:45:30 PDT 2006

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 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
--------
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev