[kepler-dev] @author tags in duplicated code.

[Edward A. Lee]

I think that with a reasonably clear idea of what sort of extension
points are desired, it wouldn't be hard to accomplish. Some particular
GUI changes might be harder to implement than others, but I doubt
the extension points would be. The GUI code can, for example, look
for a parameter contained by the director of the current model
that would customize interactions. The challenge is how to handle
the logic when the director is absent, or is deleted, or if there
is more than one director.  All of these things are possible
during editing...

It is already possible to do wholesale substituion of GUIs,
as done for example with the HTML viewer, FSM editor, and
Model editor. These are selected based on a list of editors
provided in the configuration file. Whenever you open
a model or submodel, the editors in the list are consulted
in order until one of them agrees to open the model.
This is why you can open PDF files, text files,
HTML files, and Ptolemy models all through the same
interface.

Edward


On 10/28/10 8:55 PM, Bertram Ludaescher wrote:
> Hi Edward:
>
> I like the idea of extension points, in particular if it allows us to
> make "mode-specific" changes to the GUI.
> By this I mean that for certain MoCs/directors and/or during certain
> *stages* of workflow development the GUI could have different "modes"
> and thus behave differently. For example,  (i) Wf design; (ii) Config
> (e.g. data binding); (iii) "Dry-run"/static analysis; (iv) Execution &
> Runtime-monitoring; (v) Report generation; and (vi) Provenance browsing
> could all be possible distinct stages/modes.
>
> In the simplest case, it might be that a mode is associated with a
> director so that features such as "drop-and-replace-actor" and
> "drop-and-insert-actor" would apply in some MoCs (say COMAD) but not
> others (e.g. FSM).
>
> Or maybe even simpler: When in "Kepler-mode", certain GUI elements and
> features are enabled which may or may not be the same as in
> "Ptolemy-mode" of the GUI.
>
> Is there a (reasonably simple) way to use achieve this for the current
> code-base, e.g., via extension points?
> If yes, then we should explore this. I guess the current approach with
> overrides that Sven used is a bit of a workaround, until we find some
> better alternatives.
>
> Bertram
>
> On Wed, Oct 20, 2010 at 6:10 PM, Edward A. Lee <eal at eecs.berkeley.edu
> <mailto:eal at eecs.berkeley.edu>> wrote:
>
>
>
>     On 10/20/10 2:50 PM, Bertram Ludaescher wrote:
>
>         What is the recommended way to experiment with those GUI changes?
>         Making the changes in the "production code" doesn't seem to be
>         an option.
>         So is branching or code-duplication the way to go?
>
>
>     Ideally, this should be done by subclassing.
>     Unfortunately, with OO design, often one discovers that the base classes
>     don't have the extension points you need. It's better to add extension
>     points that facilitate your variant than to duplicate code...
>
>
>         I think there needs to be an easy way to make code changes,
>         extensions,
>         etc in an "experimentation area" of the repository. Sometimes it
>         will
>         make sense to fold those changes back into the general code.
>         In this particular case, I'm not sure. For example replacing one
>         COMAD
>         actor with another one is easy since the single input, single output
>         structure of actors, together with scope parameters makes this
>         replacement meaningful / conceptually easy. This might not be
>         the case
>         for general models / workflows.
>
>
>     The problem is that it's very rare for people to go back and turn
>     "experimental" code into "production" code. If you build experimental
>     code, you will always have experimental code...
>
>     Edward
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 330 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20101030/425ebc1e/attachment.vcf>