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

Laura L. Downey ldowney at lternet.edu
Tue Aug 9 08:38:31 PDT 2005


Good stuff Edward - and right on track with what our uses have been asking
about and that is a way to format workflow models, inputs, results etc for
publications.

Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM  87131-0001
505.277.3157 phone
505.277-2541 fax
ldowney at lternet.edu
 

-----Original Message-----
From: kepler-dev-bounces at ecoinformatics.org
[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Edward A. Lee
Sent: Friday, August 05, 2005 8:44 AM
To: ptresearch at maury.eecs.berkeley.edu; Kepler-Dev
Subject: [kepler-dev] More usability improvements from Cape Code:
Preferences


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
preferences.

The crux of the preferences manager is the class 
ptolemy.vergil.VergilPreferences.
An instance of this class is specified in the configuration.  Other 
applications
(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:

  _linkBendRadius:
    Set this to 0.0 to get squared off bends in the links in Vergil.
    See the attached file.
  _relationSize
    Set this to 0.0 to not show relations at all.
    See the attached file.
  _showParameters:
    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
configurable.

Comments are welcome.

Edward


------------
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  



More information about the Kepler-dev mailing list