Sources for giny / phoebe library
Abel Daniel
Are the sources for the giny and the phoebe library (.jars) available
somewhere? I tried
http://csbi.sourceforge.net/
but the sources checked out from that cvs repository
(anon...@csbi.cvs.sourceforge.net:/cvsroot/csbi/ , module giny)
doesn't build.
(one compile error for example:
phoebe.util.P3DNode is not abstract and does not override abstract
method getNodeLabelAnchor() in giny.view.NodeView )
I'm asking this because I'm trying to make use custom Stroke-s in
custom LineTypes for rendering edges. If I use a java.awt.BasicStroke
with a custom width setting, it works, but if I use a custom class
that implements java.awt.Stroke (but does not subclass BasicStroke)
then nothing happens (i.e. my custom Stroke gets ignored, and the edge
is drawn with the default style.) Any idea what might cause such a
thing?
Thanks in advance,
Abel Daniel
Mike Smoot
We are indeed using the gimy code from http://csbi.sourceforge.net/ however we're only using the interfaces, not any of the implementation. Within the giny module, there are several subprojects (luna, phoebe, giny, coltginy), but the only one we're using is the giny subproject. So rather than trying to build at the top-level directory, go into the giny directory and try building there.
That said, it is on my todo list to merge the giny sources into our corelibs project. That should hopefully happen sometime this week.
As for your question about strokes, I wonder if you're trying to set the stroke in the proper place? Unless you're using an old ( i.e. version 2.2) version of Cytoscape, we no longer use phoebe, we have our own rendering engine. Naturally, our rendering engine (available in corelibs) doesn't provide a method to access the line stroke, but if you wanted to hack the code, it would be possible. Let me know and I can provide further details.
thanks,
Mike
____________________________________________________________
Michael Smoot, Ph.D. Bioengineering Department
tel: 858-822-4756 University of California San Diego
Abel Daniel
found it now.
> As for your question about strokes, I wonder if you're trying to set the
> stroke in the proper place? Unless you're using an old (i.e. version 2.2)
> version of Cytoscape, we no longer use phoebe, we have our own rendering
> engine. Naturally, our rendering engine (available in corelibs) doesn't
> provide a method to access the line stroke, but if you wanted to hack the
> code, it would be possible. Let me know and I can provide further details.
My original plan was to create a custom LineType.
cytoscape.visual.LineType is basically simply a java.awt.Stroke and a
String name. I made a cytoscape.visual.mappings.ObjectMapping subclass
that creates instances of this custom
LineType. The problem is that the backend code can only handle
BasicStroke subclasses.
ding.view.DEdgeView.setStroke() explicitly ignores non-BasicStroke
subclass Strokes. Basically
the BasicStroke instance is only used to store the parameters of the
edge (width and dashArray)
_not_ for doing the drawing. This looks quite stupid to me: First a
Stroke is created (when
initializing LineType) that is passed to the framework. At one point
the framework extracts
some parameters from it, then recreates basically the same thing (in
render.immed.GraphGraphics).
Shouldn't this be refactored so that the same Stroke that is passed in
is used for the painting?
Is there any good reason to leave it the way it is?
For example, in GraphGraphics there is the following comment:
// Unfortunately, BasicStroke is not mutable. So we have to
construct
// lots of new strokes if they constantly change.
But that wouldn't be needed if the Strokes weren't recreated! If the
LineType's Stroke would be
used, it wouldn't have to be created all the time. (If only the
Strokes defined in LineType are
used, then _all_ edges would be drawn with the _same_ Stroke. No
unnecessary object creation
_at_ _all_.)
Mike Smoot
Yeah, it's kind of ugly. However, most things are done the way they are for a reason. Unfortunately, the developer who wrote this code no longer works on the project, but I'll try and explain what I can.
I believe that BasicStrokes are used rather than Stroke objects so that we can take advantage of line end caps and joins which become particularly important when using alpha blending (something the libs support, but Cytoscape does not [yet]) and the various arrow shapes we support.
I'm not certain why we save the BasicStroke parameters rather than saving BasicStrokes, but I'm guessing this is because BasicStroke isn't mutable.
The motivation for saving parameters at all has to do with the level of graph detail. The cytoscape.render.stateful.GraphRenderer class draws things based on level of detail, which is determined by properties and the size of the network in question (see the manual for more detail on the properties). So GraphRenderer isn't just considering the stroke, it's considering the level of detail as well. Depending on the level of detail, it may use the stroke definition it's got or use a low-level of detail stroke ( e.g. not drawing dashes, not drawing curves, etc.). Achieving high performance rendering is the reason for doing it this way.
So, there are a few good reasons to leave things as they are. That said, we've been toying with the idea of expanding the types of lines allowed. We're currently thinking that this would primarily mean different dash lengths and styles.
Can you explain the type of effect you're trying achieve?
thanks,
Mike
Abel Daniel
> I'm not certain why we save the BasicStroke parameters rather than saving
> BasicStrokes, but I'm guessing this is because BasicStroke isn't mutable.
> The motivation for saving parameters at all has to do with the level of
> graph detail.
Oh. yes, that makes sense. However, there is a fixed number of detail
levels,
so wouldn't "pushing detail definition up the api stack a bit" be a
better idea?.
I.e. make LineType have lowDetailStroke, highDetailStroke etc.
members. and
use the appropriate one for drawing. Having different detail levels
doesn't rule out
using the supplied Stroke object for the actual drawing.
Such a solution would be much more natural, and much easier to extend
with different line styles.
> So, there are a few good reasons to leave things as they are. That said,
> we've been toying with the idea of expanding the types of lines allowed.
> We're currently thinking that this would primarily mean different dash
> lengths and styles.
>
> Can you explain the type of effect you're trying achieve?
The user request I'm trying to implement is to show multiplicity of
edges by drawing parallel edges.
An A->B edge wich has a 'multiplicity' attribute with the value 3, for
example, would be shown as
three lines between those nodes. I am trying to do this by using a
Stroke that draws three lines
instead of one.
(I think implementing this by using a custom Stroke is the easiest
thing to do. I could create two
'fake edges' but that would foul other things up. I could hack in some
sort of multiplicity into
the backend code, but that would be ugly. For some examples of what
can be done with custom Stroke
classes, see http://www.java2s.com/Code/Java/2D-Graphics-GUI/CustomStrokes.htm
the DoubleStroke
is sort of what I am planning to do.)
--
Abel Daniel
Mike Smoot
Oh. yes, that makes sense. However, there is a fixed number of detail
levels,
so wouldn't "pushing detail definition up the api stack a bit" be a
better idea?.
Actually, probably not because Cytoscape really doesn't have a notion of level of detail. That is currently encapsulated in the rendering libs which Cytoscape tries to use as a black box.
The user request I'm trying to implement is to show multiplicity of
edges by drawing parallel edges.
An A->B edge wich has a 'multiplicity' attribute with the value 3, for
example, would be shown as
three lines between those nodes. I am trying to do this by using a
Stroke that draws three lines
instead of one.
(I think implementing this by using a custom Stroke is the easiest
thing to do. I could create two
'fake edges' but that would foul other things up. I could hack in some
sort of multiplicity into
the backend code, but that would be ugly. For some examples of what
can be done with custom Stroke
classes, see http://www.java2s.com/Code/Java/2D-Graphics-GUI/CustomStrokes.htm
the DoubleStroke
is sort of what I am planning to do.)
I understand what you're trying to accomplish. As things stand now, I don't think there is an easy (or even reasonable) way to get what you want.
I think that your easiest approach would be to persuade the user that multiplicity is best captured using edge width rather than parallel lines. I say this not entirely because it is easier for Cytoscape this way, but because parallel lines might confuse the semantics of what an edge is. Do three parallel lines represent one edge or three? Is this obvious to someone seeing the graph? Anyway, that is just my gut reaction, I'm sure your user has his or her reasons, so feel free to ignore this advice!!! :)
That said, if you were interested in writing a patch that would allow EdgeDetails to store edge parameters (i.e. dash length, width, etc.) as a mutable extension of BasicStroke (not just a Stroke), refactor everything else, and thus (hopefully) allow for customized strokes to be set at the cytoscape level, then I'd be happy to advise. However, this is a big change that will touch some really important parts of Cytoscape's core, which means there would be a high standard for making changes.
It is very, very unlikely that any current developer would be able make this sort of change in the 2.5 timeframe.
thanks,
Mike
Abel Daniel
>
> I think that your easiest approach would be to persuade the user that
> multiplicity is best captured using edge width rather than parallel lines.
> I say this not entirely because it is easier for Cytoscape this way, but
> because parallel lines might confuse the semantics of what an edge is. Do
> three parallel lines represent one edge or three? Is this obvious to
> someone seeing the graph? Anyway, that is just my gut reaction, I'm sure
> your user has his or her reasons, so feel free to ignore this advice!!! :)
>
defense of multiply stroked edges: if value of multiplicity is a small
integer, then I think paralell edges show it better. Is the difference
between an edge of width 3 and an edge of width 4 obvious at first
sight, and the value of the width easy to tell? Counting paralell
edges just by looking at them is much easier.
> That said, if you were interested in writing a patch that would allow
> EdgeDetails to store edge parameters (i.e. dash length, width, etc.) as a
> mutable extension of BasicStroke (not just a Stroke), refactor everything
> else, and thus (hopefully) allow for customized strokes to be set at the
> cytoscape level, then I'd be happy to advise. However, this is a big change
> that will touch some really important parts of Cytoscape's core, which means
> there would be a high standard for making changes.
I implemented the changes I suggested. I think that even if easy
implementation of custom strokes is not an issue, not recreating
Strokes all the time makes the code cleaner and easier to understand.
The zipped patch is at http://abeld.web.elte.hu/use_stroke_patch.zip
The contents of the zip file:
cytoscape_diff: output of 'svn diff' (i.e. diff against
http://chianti.ucsd.edu/svn/cytoscape/trunk, r9703)
corelibs_diff: output of 'svn diff' (i.e. diff against
http://chianti.ucsd.edu/svn/corelibs/trunk, r9703)
double_1.jpg: file to be placed in cytoscape/src/cytoscape/visual/ui/
images/
curved_edges.xgmml: testcase that has one edge set to DOUBLE_1
LineType
To test, simply apply the diffs, copy double_1.jpg in the right place,
compile, start cytoscape then load curved_edges.xgmml. One of the
edges should be a double-edge. The ends of that double edge is ugly,
but that is a limitation of DoubleStroke, which can be fixed. Note
that selecting the double edge is quite natural. (For selection
purposes,
it is simply a really thick (single) edge.)
Summary of changes:
- Add a thickness member to LineType.
(this is needed because the low-level code uses edge thickness to
calculate some things, for example arrow sizes (as far as I could
tell), and for handling selection)
- in ding and render.stateful and render.immed: use the Stroke
supplied by the LineType, don't extract width and dash parameters
from it.
- To make demo work: add a DOUBLE_1 LineType. This is only for showing
that custom strokes work, an improved implementation would be needed
(for triple-edges, and for better handling of edge ends, for
example).
Note that this patch is not a "make cytoscape have multiply stroked
edges" kind of patch, but a "refactor cytoscape innards to not mangle
the Stroke object of LineType", and the inclusion of the DoubleStroke
part (which means most of the changes in cytoscape_diff) is simply to
show that the thing works.
I didn't fix the javadoc comments, and I assume reindenting would be
needed, too (if the patch is accepted.)
If accepted, graph import / export might need to be fixed (for
example, XGMMLWriter casts to BasicStroke, too.)
In GraphGraphics.drawEdgeFull(), I removed some tests based on
dashLength. As far as I understood the code, those tests where needed
to handle dashed edges, but I didn't see any changes after removing
them. What where those doing?
In one or two cases the decision to draw an edge dashed was based on
the level-of-detail setting. These might be changed to drawing with
GraphGraphics.drawEdgeLow().
I would be interested in your opinion about the patch.
--
Abel Daniel
Mike Smoot
Thanks for the patch! In general I think this looks good. It certainly appears to simplify some things. However, I'm going to need to test things, which may take me a week or two. My only immediate concern is the relationship of stoke end caps to dash style. I'm not entirely clear how this ties in with level of detail and what the effect on alpha-blending might be, but this is what I'll look into. I'll keep you posted.
thanks,
Mike
cytoscape_diff: output of 'svn diff' ( i.e. diff against