[kepler-dev] port parameters

Wed Dec 21 16:50:03 PST 2005

Hi Laura,
Edward is swamped, so I'll take a shot at this.

Laura wrote:
> -Can PortParameters and ParameterPorts also be singular or multiple?

Edward wrote:
> These are intended to always work together.
> There is always an instance of ParameterPort for every PortParameter.
> The UI is meant to see the pair as a unit (which it does with only
> some success).

The constructor for a ParameterPort is by definition not a multiport,
it calls setMuliport(false).

I'm not sure if a multiport ParameterPort makes sense.
A multiport is "A port that can send or receive tokens over more than
one channel." 
If we had a ParameterPort that was a multiport, how would the data 
be represented as a Parameter?  I suppose the Parameter could be an
array or record and each channel could correspond to an element in
the array or record.

I dunno, it seems like a solution looking for a problem so let's just
say that ParameterPorts are always single ports.

> -Is there a specific reason why we would need to somehow distinguish
> them to the user visually?

Yes.  If we have an actor that has a ParameterPort visually
represented, then it would be nice for the user to know they can also 
set it as a parameter.  Otherwise, they might not know they can set
it two ways. 

That being said, the Edit Parameters window does not give an
indication that the parameter is a port.

So, in principle, we need not distinguish them visually, but it might
be helpful.

> -If they really function on the basic level like regular ports do they need
>  a different representation?

A ParameterPort has a superset of the functionality of a Parameter.
So, it would be nice if the UI indicated this, much in the way
it differentiates between single ports and multiports.

> -Would it be creators of workflows as opposed to runners or editors of
>  workflows that need the distinction?

Creators or workflows are the primary users that would need the
distinction.

I agree that grey is not necessarily the best color.  In some ways
though, grey indicates that the ParameterPort need not necessarily be
connected

I agree that a UI can be too cluttered.  
It would be nice to differentiate ParameterPorts from regular ports.

<offtopic>
Another idea is that it would be nice to have the types of ports
really obvious.  In Ptolemy classic, I think either the ports or the
lines connecting the ports were colored depending on the type.
This tends to lead to visually complex diagram, but there sure is
plenty of info there.  Perhaps this could somehow optional.
Edward just checked in some changes that should make it easier
to display strings near the ports.  We could have something that would
display the types if there was a type error?
</offtopic>

_Christopher

--------

    I'm not sure why you would have an error getting to section 5.4.
    What version of Adobe Reader are you using?  7.0 is the latest.
    I was able to view the pdf inside IE under Windows from home using my
    slow DSL connection.

    You could try downloading the pdf by going to
    http://ptolemy.eecs.berkeley.edu/papers/05/ptIIdesign1-intro/
    and right clicking and selecting "Save As" on the pdf.

    I yield to Edward on the port parameter questions.

    _Christopher

    --------

        Thanks Christopher.  I thought I looked there and don't know how I miss
   ed
        it.  For some reason I can access section 3.3.2 but I can't get to Sect
   ion
        5.4 (get a file I/O error of all things).   I've tried several times.

        As to the colors of PortParameters and ParameterPorts, I need to get th
   ese
        straight in my head before really making any kind of informed
        recommendation.  

        >From a purely visual perspective, I will just raise the issue of using
    gra
       y
        as possibly problematic simply because it is often used to indicate som
   e
        disabled state.

        I might be worried that a gray triangle will instead say to the users t
   hat 
       a
        port is disabled for some reason.

        Some of the things I would want to understand before making an informed
        recommendation would be things like:

        -Can PortParameters and ParameterPorts also be singular or multiple?
        -Is there a specific reason why we would need to somehow distinguish th
   em t
       o
        the user visually?
        -If they really function on the basic level like regular ports do they 
   need
        a different representation?
        -Would it be creators of workflows as opposed to runners or editors of
        workflows that need the distinction?

        Etc.

        Visual design can often get too cluttered if we try to differentiate to
   o
        many things, then the coding (colors, symbols, shapes, thick lines, thi
   n
        lines, dotted lines, bolded text, italics and so on) begins to be a bur
   den
        to the user.

        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: cxh at EECS.Berkeley.EDU [mailto:cxh at EECS.Berkeley.EDU] 
        Sent: Tuesday, December 20, 2005 7:04 PM
        To: Laura L. Downey
        Cc: kepler-dev at ecoinformatics.org
        Subject: Re: [kepler-dev] port parameters 

        Hi Laura,
        The best place to look is Volume 1 of the Ptolemy II Design doc:
        http://ptolemy.eecs.berkeley.edu/papers/05/ptIIdesign1-intro/ptIIdesign
   1-in
       t
        ro.pdf

        Section 3.3.2, "Port Parameters" is a good place to start.
        See also 5.4 "Couple Port and Parameter"

        The Javadoc can be found at
        http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/codeDoc/
   ptol
       e
        my/actor/parameters/PortParameter.html

        This brings up a UI question.
        There are PortParameters and ParameterPorts.
        I get confused about which is which.

        ParameterPorts are ports that update a parameter in a container.
        ParameterPorts are:

         A specialized port for use with PortParameter.  This port is created
         by an instance of PortParameter and provides values to a parameter.
         Data should not be read directly from this port.  Instead, the update
         method of the corresponding PortParameter should be invoked.  This
         port is only useful if the container is opaque, however, this is not
         checked.

        When I was updating the relation icons to look like your gif images I
        ran in to ParameterPorts.  Currently non-multiport ParameterPorts are
        darkGray.  I think these should be lightGray so as to be closer to the
        white of regular non-multiports.  (I'm not sure if multiport
        ParameterPorts exist (Edward??).)

        The easiest way to see a ParameterPort is to start up Kepler:
        1) File -> New -> Graph Editor
        2) Search for Sinewave
        3) Drag the Sinewave actor in to a canvas.
        4) Then right click on the Sinewave composite actor and lookinside.

        What do you think, should I change the darkGrey to lightGrey
        to better match the white of single ports?

        _Christopher

        Laura writes:
        --------
            Is there an indepth discussion/description about port parameters
        anywhere?
            I thought I remembered seeing something in an earlier version of Pt
   olem
       y
            documentation but for some reason I can't find it.  Can someone poi
   nt m
       e
        to
            it?

            Thanks.
    --------
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------