Hi Andre,
The plan is definitely to link up with Sarala's work - we'll
hand-create the svg diagrams only until the output of Sarala's work can
generate these directly from the CellML model.
Cheers,
Peter
David Nickerson wrote:
Hi Andrew,
I'm wondering how (if?) this fits in with the visualisation work that
Sarala is doing?
While I'm not sure how standard it is, I know inkscape allows you to add
links to any object in an SVG diagram where you can set xlink properties
like: href, type, role, arcrole, title, show, and actuate. I would
imagine that these are plenty to be able to link SVG objects to other
resources (assuming this is standard SVG, which it seems to be looking
at plain SVG diagrams exported from inkscape).
In the diagrams I have been creating with Sarala's help I have
envisioned that these links would be used to link to associated
graphs/math/etc provided in a "reference description" of the model. I
guess for an interactive tool like PCEnv you'd probably link to some
PCEnv specific resource telling the GUI what to do. Maybe you'd simply
link directly to a graph trace and PCEnv would be able to interpret such
a request and show the appropriate trace, but that might get a bit
restrictive.
Andre.
Andrew Miller wrote:
Hi all,
Peter Hunter has proposed that it be possible to create SVG diagrams
which interact with PCEnv so that you can click on parts of the SVG
diagram and have PCEnv update the styles of traces being displayed on a
graph.
For example, someone might click on a sodium channel in the SVG diagram,
and have a trace showing sodium concentrations come up on their graph.
There are several possible ways to implement this, and I am looking for
feedback from potential users on which way they would find the most useful:
1) Create a generic language which describes the relationship between
elements in an SVG diagram and trace resources in the graph metadata.
This relationship could describe what happens when the SVG diagram is
clicked. This would probably be the most useful for tools other than
PCEnv to process, although it is not clear whether this would actually
be useful to such tools.
2) Provide an API which _javascript_ in SVG diagrams can use to
manipulate PCEnv traces, perhaps by giving the resource URI.
If we choose to use this _javascript_ API, there are several choices as to
how we could construct the API:
a) Provide an API which allows trace properties to be directly changed, e.g.
var tc = new TraceController();
tc.setTraceStyle(graphURI, traceURI, "invisible");
tc.setTraceColour(graphURI, traceURI, "#ff00ff");
The problem with this approach is that _javascript_ code will often want
to highlight variables, but if this is done through hiding traces and/or
changing colours, code would have to keep track of what changes are
made, and store enough information to be able to reverse the changes.
b) Use the above API style, but provide additional API functions to save
all trace styles / colours on a graph and restore them again, by name.
The only problem here is that the use might have changed something, and
then their change will get reverted.
c) Make some sort of transactional system, where temporary changes can
be made in transactions, and the transaction can be rolled back. The
user will see changes, but if they modify the same variable, their
change will be committed so will not be rolled back.
The problem with option c is that it is very complex both to implement
and to learn how to use, which means it might end up never being used
anyway.
d) Create a highly specialised API allowing the 'highlighted variable'
to be set, such that only one highlighted variable can be set at a time.
If the user changes the variable, it gets unhighlighted automatically.
This is more similar to option 1.
Option 1 and 2d would probably the simplest to use, with there being a
realistic possibility that option 1 could one day be edited in something
other than a text editor. However, they do not give the same flexibility
as the other options would.
I welcome any opinions on what approach would be best.
Best regards,
Andrew Miller
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
begin:vcard
fn:Peter Hunter FRS
n:Hunter;Peter
org:University of Auckland;Auckland Bioengineering Institute (ABI)
email;internet:[EMAIL PROTECTED]
title:Director
tel;work:+649 3737599 x88395
tel;fax:+649 367 7157
version:2.1
end:vcard
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
