[kepler-dev] Kepler build errors
Matthew Brooke
brooke at nceas.ucsb.edu
Sat Apr 15 17:55:49 PDT 2006
Hi Edward -
> Can you explain what you are using this for? It makes me nervous to
> have such a method, since it really seems to have very limited utility
> (since it will only work on the first invocation of pack()).
At runtime, the Kepler menu code waits for PTII to finish building and
rendering its menus, then Kepler enumerates the PTII menu items and uses
them to build a new Kepler menubar, which then replaces the PTII version.
The PTII menus are built and displayed within a thread created in the
pack() method in ptolemy.gui.Top. Therefore, Kepler has to be sure that
the first pack() thread has finished execution (i.e. the menus are built
and displayed) before it commences with its own menu customization. I
originally wrote code that did this without changing Top; however, since
then, two other Kepler UI issues have arisen, both of which also need to
know when the frame has finished being built and rendered - (i) the
splash screen needs to disappear when the first kepler window appears
(although potentially, we might be able to solve this one using Java awt
listeners), and (ii) a kepler-specific dialog (the Query Builder) that
is a subclass of Top, needs to know when the first pack has finished so
it can change the text on the title-bar (which is otherwise always
overridden by Top's pack() thread). We also tried using built-in Java
listeners for the latter, but could not get this to work reliably with
the threading.
It therefore seemed prudent to have a (seemingly-innocuous :-) global
flag or method that could be used to discover when the Top frame had
finished its pack() for the first time. Subsequent pack() threads are
not important to the kepler code - it's only the first we need to know
about.
> At a minimum, if it is used only in subclasses, can we make it
> protected? The name would have to change to _isPackFinished().
I made it public because it is also used in other classes - notably:
ptolemy.vergil.basic.MenuMapper
(currently in kepler/exp/ptolemy.vergil.basic.MenuMapper)
and (proposing to add to) org.kepler.gui.SplashScreen
> setPackFinished() [..] a one-line private method that is
> only used once does not need to be there. So I removed it.
The reason I added this method was to provide a synchronized way of
setting the flag, since potentially, multiple pack() threads could be
trying to modify the flag at any given time. However, if none of them
will be trying to switch it from true back to false, this may be a moot
point - it's only the first call that matters.
>
> it seems like a listener pattern would be a more robust design...
Agreed - this is what I was originally going to do, until I realized
that each observer would need to register its listener before the first
pack() thread finishes; otherwise, it will never receive a callback.
Given the proposed variety of usages within Kepler, I concluded that we
could not always be certain that this condition will be met, so went
with the accessor method instead.
In conclusion, I think this would be a very useful method that would
enable current and future Kepler code to "decorate" PTII UI components,
without needing to modify PTII code more than is necessary.
As I mentioned in my previous email, I think a change of name might make
the functionality less ambiguous (maybe isFrameFullyRendered(), or
something equally descriptive that doesn't mention "pack()"?)
Finally - I must apologize for not following the PTII code conventions.
I understand how annoying that is, and will be more fastidious in future.
Regards
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
---------------------------------------------
Edward A. Lee wrote:
>
> Would any of the listeners in the base class Window do the job?
> E.g., Window (and hence Top) have methods
>
> addPropertyChangeListener, addPropertyChangeListener,
> addWindowFocusListener, addWindowListener,
> addWindowStateListener,
>
> Typical of Java, these are not very well documented, but perhaps
> by experimentation you could determine which one might do the job...
>
> In any case, it seems like a listener pattern would be a more
> robust design...
>
> Edward
>
> At 09:49 PM 4/14/2006, Matthew Brooke wrote:
>
>> Edward -
>>
>> The method is used by the Kepler menu system - and in future by the
>> splash screen - both of which only need to know when the frame has
>> finished being "built" and displayed for the first time; subsequent
>> calls to pack are inconsequential to these observers, and are ignored.
>>
>> Having said that, I do understand your point, and I think the method
>> name is currently misleading. Maybe it would be better named
>> isFrameDoneRendering() or something similar?
>>
>> 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
>> ---------------------------------------------
>>
>> Edward A. Lee wrote:
>>> The change to Top looks suspicious to me...
>>> The pack() method gets invoked multiple times, e.g. if
>>> you resize a window. However, it looks like _isPackThreadFinished
>>> is never set to false after being set to true.
>>> So, whatever you are needing this for will probably
>>> not work when the window is resized...
>>> Edward
>>> At 12:27 PM 4/14/2006, Matthew Brooke wrote:
>>>
>>>> Hi all -
>>>>
>>>> just a heads-up - I changed some code in Kepler *and* in ptii this
>>>> morning - so you'll need to update ptii (or at least the source for
>>>> ptolemy/gui/Top.java) in order to build kepler
>>>>
>>>> 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
>>>> ---------------------------------------------
>>>> _______________________________________________
>>>> Kepler-dev mailing list
>>>> Kepler-dev at ecoinformatics.org
>>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>>
>>> ------------
>>> Edward A. Lee
>>> Professor, Chair of the EE Division, Associate Chair of EECS
>>> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
>>> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
>>> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
More information about the Kepler-dev
mailing list