[kepler-dev] More usability improvements from Cape Code: Preferences

Edward A. Lee eal at eecs.berkeley.edu
Fri Aug 5 07:43:49 PDT 2005

I've checked in a suite of changes with the objective of making
diagrams more customizable and suitable for use in publications.

The major change is a preferences manager.  I also created some
preferences that I needed in order to make diagrams suitable for publication.
In the Edit menu, there is a new item, "Edit Preferences".
Preferences are stored as ordinary parameters, and are accessible
from the expression language.

For example, for a paper we were writing, I created the attached pdf file
by printing to Acrobat Distiller, and then using Acrobat to crop
away the white space.  This file can be directly used with
pdflatex. Notice that the connectors are not rounded in this
figure and that the relations are not shown.  This is set via

The crux of the preferences manager is the class 
An instance of this class is specified in the configuration.  Other 
(like Kepler) could subclass this class and specify the subclass in the
configuration, which will result in an augmented set of preferences.
In the default Ptolemy II configuration, the preferences class is specified
in the file ptolemy/configs/basicUtilities.xml.

Preferences are stored persistently in a file called VergilPreferences.xml
in the same directory as the user library (on Windows, this is typically
in Documents and Setting\userName\.ptolemyII).

Preferences can be overridden locally in any model.  In particular,
The Utilities library now has an attribute called LocalPreferences
that can be dragged into a model or composite actor to
locally override the global preferences values.  So for example,
if you want a particular model to have squared rather than rounded
corners on wires, then you can drag one of these into the model
and override the "_linkBendRadius" value.

Actually, the preferences are entirely linked into the expression
scoping mechanism. So you can also simply define a parameter in the
model called "_linkBendRadius" and this will specify the bend radius
for that model.  This can be done at any level of the hierarchy,
and it will follow the scoping rules for variables in expressions
(all submodels will get the overridden value).

Preferences that I've implemented so far:

    Set this to 0.0 to get squared off bends in the links in Vergil.
    See the attached file.
    Set this to 0.0 to not show relations at all.
    See the attached file.
    This replaces the previous mechanism that I had sent email about
    to show parameter values in the Vergil diagram.  Now, this is
    determined by a preference.  The possible values are "None"
    (the default), "Overridden parameters only", and "All";

I'm open to suggestions for additional preferences, but I do want some
restraint.  In particular, I don't want to fall victim to the X-windows
trap, where instead of doing good design, everything was made user

Comments are welcome.


Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compositionWithCausalityLoop.pdf
Type: application/pdf
Size: 26053 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20050805/87aa1665/compositionWithCausalityLoop-0001.pdf

More information about the Kepler-dev mailing list