I am not very familiar with Python.  But I have worked with Sean Luke on
getting the inspectors working.

In general, the display asks the portrayal to hand in inspectors for
whatever objects might have been clicked/selected.  Portrayals usually
look for the objects, than hand them to a SimpleInspector to create the
entire inspector.  One alternative may be to use some custom portrayals
that override the getInspector method by actually creating the
visualizer/editor you want for each object.

Would that be a viable solution?


On Mon, 17 May 2004, Norman Josephy wrote:

> Hello:
> I apologize for the length of this e-mail.
> I would like to communicate with anyone interested
> in using Python/Jython to build/control mason models.
> I would like to share the learning experience of
> using mason from a Python platform.
> I am not a Java programmer. I am a Python programmer.
> I am new to the mason library.
> To learn more about mason, I have begun to convert
> the tutorials into Python and run under the Jython
> interpreter. So far, I have converted the first
> five tutorials. For the most part, they run fine.
> I have not tried to checkpoint the models. That is last
> on my list of capabilities important to me at this stage
> of my learning.
> I have not tried to syncronize code. There are some
> e-mails on the Jython users list indicating how to
> accomplish in Python the Java syncronized() {code}
> template. The tutorial # 4 runs fine with the
> Roll The Dice button unsyncronized. I realize that
> I will need to address the issue eventually, but it
> is also low on my priority list.
> The most significant problem is the failure of Jython classes
> to act like a Java Bean. This means that none of the get/set
> bean property accessing mechanisms will work. This seems
> to be important only (at least for as far as I have
> gone in the mason language) for getting/setting parameters in
> the inspection panel of the controller. The grid locations
> appear with the value text window when a grid cell is double-
> clicked. When the BigParticle in tutorial 4 is double-clicked,
> the Roll-The-Dice button appears and its action works.
> When an agent is double-clicked, its location appears in the inspector.
> But none of the get/set parameters appear.
> There was an e-mail by one of the developers of RePast to the
> Jython users list a few years ago addressing this same question:
> inability to use Jython instance attributes as bean properties.
> I am wondering if either of the following are two possible work-arounds.
> I don't program in Java. So this might be stupid. But, in looking
> at the code, is it true that the use of
> get/set for accessing instance properties is limited to the
> generateProperties method. If so, can the SimpleInspector
> class be subclassed with a Python-based generateProperties
> method shadowing the Java method so that the required
> properties can be accesses using Python accessing? I have
> played with this a little, but I am in the dark concerning
> the actual workings of the SimpleInspector class.
> Or, can someone provide the simplest Java code that would
> put a label and text in the inspection area. In essence,
> replace set/get with a widget that asks for the property
> value, rather than using the property name and trying to
> call getProperty. I could then use Python code to
> access the property. Similarly for the other direction:
> a widget on the inspector page that returns a user-supplied
> value. Then Python code could update the state of the agent
> involved.
> I would be glad to share my Python code with anyone. I am
> particularly interested in beginning to develop a Python
> style for model-building using the mason library, and
> would be grateful for constructive (or even sarcastic)
> critism of the Python code. For example, I have exposed
> all of the Java inner classes as classes on the same
> level as the model and agent classes.
> The development process, with having both the Jython interpreter
> open to test individual statements, and my Python editor (SciTe)
> for writing and running model code, is making model development
> a pleasure.
> I again apologize for the length of this message.
> Norm