[kepler-dev] Splash screen and corresponding changes
Laura L. Downey
ldowney at lternet.edu
Mon May 1 15:18:45 PDT 2006
That sounds like a good solution to me. I agree that it is nice to have the
splash screen since it "hides" the slow start up time.
So just to be clear, you are saying you can remove the mouse sensitivity to
help solve a code issue, and Kepler will keep using its current splash
screen - the one that Kevin did based on the mockup I did.
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: cxh at EECS.Berkeley.EDU [mailto:cxh at EECS.Berkeley.EDU]
Sent: Monday, May 01, 2006 3:52 PM
To: Laura L. Downey
Cc: 'Kepler-Dev'
Subject: Re: [kepler-dev] Splash screen and corresponding changes
I suspect other applications have splash screens that are mouse
sensitive as well, though I can't actually name one :-)
The splash screen I downloaded and the current splash screen both
have this functionality. It could be that current splash screen
is based on the splash screen I downloaded
If we don't need the mouse sensitivity, then I can remove
the Kepler specific version of VergilApplication and we can stick
with the current splash screen.
I think this is the right thing to do. The splash screen works
around a bug (slow startup) and we should avoid adding another bug
(gui in wrong thread).
_Christopher
--------
Ah okay. Thanks for clearing that up. I didn't realize the splash
screen
was mouse sensitive and would close if you just simply clicked on it.
That's not anything I spec'd or asked for from a usability perspective.
Is there some reason we need that? Would it be easier if it wasn't
mouse
sensitive?
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: cxh at EECS.Berkeley.EDU [mailto:cxh at EECS.Berkeley.EDU]
Sent: Monday, May 01, 2006 2:51 PM
To: Laura L. Downey
Cc: 'Kepler-Dev'
Subject: Re: [kepler-dev] Splash screen and corresponding changes
Hi Laura,
The situatino is a tad confusing. I mean the splash screen -
the screen that comes up before the welcomne window
The current default splash screen is mouse sensitive. If you click
anywhere on it, it will close. The current default splash screen
has no close button, it is just mouse sensitive. The current default
splash screen also exits at the right time - right around when
the welcome window opens up.
The problem is that to retain this mouse sensitivity for the
splash screen we need to be tricky about threads. This causes
buggy behaviour.
_Christopher
--------
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
bac
k
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
th
e
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
rathe
r
> 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
befor
e
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
muc
h
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
deepe
r
>> 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
hel
p
me
out
.
>>
>> Kevin
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-de
v
--------
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-de
v
--------
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------
More information about the Kepler-dev
mailing list