[Walrus-dev] Walrus

[Young Hyun]

On Sat, 20 Apr 2002 metadata@tampabay.rr.com wrote:

> One observation is that there is no way to "zoom" in as close as I would
> like to.
>
> Is there a way to specify minimum link length in order to coerce the graph
> into a larger space? The Champagne graph has better "zoom" properties so
> I assume it is relative to the complexity and number of nodes/links.

The ability to zoom in is a feature I've wanted myself.  The easiest way
of implementing it is by moving the eye backwards and forwards in 3-D
space.  This approach, however, hits against an apparent bug in Java3D
connected with eye movements.  When I move the viewer's eye in any way by
changing the location of the ViewPlatform, it can take Java3D some
arbitrary amount of time before it registers the change.  Sometimes Java3D
doesn't register the change until the user takes action, like navigating
around the graph a couple of hops.  Telling Java3D to refresh the display
doesn't help.  This lag causes problems because my custom-coded picking
routines and the routines for drawing labels on screen must know the
correct location of the eye at all times.

The other way of implementing zooming is by scaling the scene.  As easy as
this may sound, it does lead to complications in picking and other
eye-dependent operations that need to be worked out.  Walrus uses Java3D
in "immediate mode," in which the burden is on the programmer to take care
of a lot of things.  Using Java3D in its better-supported scene graph mode
would lift a lot of the burden, but unfortunately, Walrus has to do things
that can't be done in scene graph mode.

> Suggestions for future consideration are:
> 1. Alter the display of the node attributes to column format as opposed to
> a single string (that runs off the screen)
> 2. Add the ability to define font settings
> 3. Print capability
> 4. Save to image format
> 5. Add a specialized attribute type for URL and add a subroutine to open the
> web browser and navigate to the URL when some activation sequence is detected.
> 6. Add capability to use jdbc as a means of acquiring graph data from
> relational data stores.
> 7. Add a specialized attribute to define node sprite to allow use of small
> icons set to display based upon some defining node attribute.
> 8. Add the capability to add links. This is more work than I expect anyone to
> do anytime soon. It is an interesting idea. This would probably require use of
> the aforementioned database connectivity.

These are good ideas.  It's really only a lack of time that prevents them
from being implemented.  I already have #4 implemented in an unreleased
branch of the code, and I would have released it except that it doesn't
work as well as it could.  It really takes contortions to make a simple
capture of a rendered scene with Java3D, if you're rendering in immediate
mode.  The real sticking point is that the maximum resolution at which a
screen capture can be made depends on the particulars of a user's video
card.  With my video card, I can make 2048x2048 screen captures.  For
others with perhaps less video RAM, it may not be possible to make a
screen capture at a resolution larger than their physical screen size.  If
so, they're just as well off using an external screen capture program.
Caveats like these have made me hesitant to release the code.

Suggestions 5, 6, and 8 could perhaps be best done outside Walrus itself.
They're useful features but specialized, and may only interest a small
number of people.  I suspect some sort of extensible interface would be an
ideal solution for needs like this.  Walrus is already pretty modular in
architecture (there's essentially the GUI frontend and Walrus proper), so
an extensible interface wouldn't be too much of stretch to implement.

Taking data from a JDBC source, in particular, may be relatively easy to
do since Walrus already uses two separate graph data structures, a minimal
one for the rendering core of Walrus and a more extensive one
(what I call the 'backing graph') provided by LibSea.  There would just
need to be some class that creates the minimal graph data structures from
JDBC.

I can imagine an extensible interface whereby users can hook in their own
classes for loading graphs, taking action on node selection, etc.

 --Young