[kepler-dev] Kepler build errors

Matthew Brooke brooke at nceas.ucsb.edu
Wed Apr 19 09:26:15 PDT 2006


Edward -

 > Can you use this instead of isPackThreadFinished().
 > I've deprecated that latter method, but once you clear it of Kepler,
 > I would prefer to remove it.

that sounds good - thanks for your time

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:
> 
> OK, this clarifies things quite a bit.
> 
> The "right" fix is to make Top more flexible so that Kepler can substitute
> its own menu populating code. However, this is more than I can handle right
> now, so instead, I've got a better implementation of your strategy.
> 
> It turns out that Top already had a private field _menuPopulated that 
> contains
> the information you really want.  So I've created a method:
> 
>     /** Return true if the menu of this window has been populated.
>      *  The menu is populated as a side effect of the first invocation to
>      *  the pack() method.
>      *  @return True if the menu bar has been populated.
>      */
>     public synchronized boolean isMenuPopulated() {
>         return _menuPopulated;
>     }
> 
> This at least has a very simple name and doc that tells exactly what
> it means.  Can you use this instead of isPackThreadFinished().
> I've deprecated that latter method, but once you clear it of Kepler,
> I would prefer to remove it.
> 
> Edward
> 
> At 05:55 PM 4/15/2006, Matthew Brooke wrote:
> 
>> 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
> 
> ------------
> 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