[kepler-dev] Splash screen and corresponding changes
Matthew Brooke
brooke at nceas.ucsb.edu
Tue May 2 08:01:18 PDT 2006
Hi Christopher -
Sorry I'm just seeing this now - spent yesterday in travel hell :-)
Sounds fine to me, regarding removing the "dismiss on click" functionality.
Just wanted to add that I'd anticipated the new "Top" method (that
Edward and I were discussing) being useful for determining when the
splash screen should be hidden - it returns true as soon as the first
frame's pack() method has finished. The only complication is giving the
splash screen a reference to the first frame. The method is:
public synchronized boolean isMenuPopulated()
cheers
m
---------------------------------------------
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA 93106-6150
ph: (805) 893-7108 fx: 805-893-8062
brooke at nceas.ucsb.edu
---------------------------------------------
Christopher Brooks wrote:
> 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
> --------
> _______________________________________________
> 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