[kepler-dev] Kepler build errors
Edward A. Lee
eal at eecs.berkeley.edu
Wed Apr 19 08:39:53 PDT 2006
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