Monday 7/15

There has been some clarification today. The scene generator sends Lisp commands to the server, which does 2 things: stores the commands in a file that serves as a scene description, and saves an image to a specific URL. Then the scene generator retrieves the image from that URL and displays it. What I'm going to do is, at the level of the scene generator, add an Java applet interface that can be accessed from Emily and the FM browser.

More specifics will be discussed at the meeting on Tuesday. For Tuesday meeting:

1. Demonstrate the two programs
2. GUI observations
   - Bruce's is complicated, and you probably don't want to physically build the GUI each time you use it.
   - Elizabeth's is user-friendly, but missing functions (like save, load, add, delete, highlight) that are in Bruce's.
   - What about undo/redo? Might be essentially included in current functions.
   - Clicking on a part could tell you what it is, and/or show a parts list of a greater structure, and/or highlight.
   - Either way, some sort of parts list would be very helpful to the user.
   - If it's similar to a graphical editor, people will be comfortable with it.
   - Having one class per operation makes sense, which Bruce's program does (although I don't think it's totally working).

To do:

1. Read papers.
2. Install Kevin's DSG (onto Linux) with instructions on Local Documentation and get it working locally. (If there are Linux problems using SSH, get Chris to install BNC on this machine.)
3. Get Bruce's code on Linux and point it to Kevin's server, and get it working.

---

Tuesday 7/16

I read all the papers, and got the DSG working on my directory, and Bruce's applet as well, using just SSH. I pointed Bruce's applet to quad.biostr.washington.edu:63070, which is where the DSG points. Its behavior doesn't seem to have changed at all, which is a little strange, since I thought it was pointing to the wrong place. But his copy, which apparently points to 21072, and mine, which goes to 63070, both appear to function about the same. Anyway, they're both very buggy and unpredictable. I think I remember the classes being very quickly done, so maybe there are lots of errors in them that I can fix.

Professor Shapiro's basic idea:

• From Emily or FMB, select terms that you've reached somehow.
• Click a '3D image' button, which pulls up a dialog box with choices: the term(s) selected, the color(?), the hierarchy, etc. (all of which have default values chosen).
• Click a 'display' button in the box to replace the box with a new window that has the scene, along with buttons to rotate it, zoom it, and reset.
• Close the window when you're done.

Notes from meeting:

• Start by entering the term manually from the first window, and doing only one term at a time.
• If there isn't a model for a term, something should say so.
• Later: one part in the middle of nowhere isn't very helpful; needs context. How to choose what other things to display for the best context?
  1) User chooses
  2) Base choice on the query that led to the term
  3) intelligence
  
• Later: could continuously build a scene, based on successive queries.
• As an applet, this could be used by the FMB, but Emily has to turn into an applet before it can use it, we think.
• Can use Bruce's code base, once it actually communicates with the server, and make the appearance closer to Elizabeth's.

To do:

1. Get my version of Bruce's applet to talk to the server correctly, the way the DSG does. Not sure how to do this, so it'll take some work. The best thing would be to get it totally working, so I can use its code confidently. Bruce can help starting the week of the 29th, but that's two weeks away, and I'd actually like to have this part done by then.
2. Start writing Java to do Professor Shapiro's basic idea, and use Bruce's code when it's ready.

---

Wednesday 7/17

I went through my version of Bruce's code and changed all the directories so that they pointed to my account, not to ema. I also made sure the port was 63070. The results:

• It didn't call up the image of the heart that I've been getting, which means it is definitely an existing image that it's just re-using.
• It connects to the server now, because the java console has success messages.
• In fact, the buttons only allow it to call up existing scenes, instead of making new ones like the DSG does.

Another interesting thing is that it only works when I run it from a browser. It compiles in jbuilder, but does nothing. Maybe because it has to communicate with URLs? Even when I compile it with jbuilder and just use the html file, it doesn't load up the files that it's supposed to read from a URL.

So I've started making my own code, using his, bit by bit to make sure things are working along the way. So far, an applet comes up with a SkandhaBox in it that works as a canvas, and it connects to the server.

I think what I need to do next is make some buttons that do basic things that the DSG does, and get them to work one by one. I need to use Bruce's code as much as possible, and definitely using his toolkit classes, but I can check it against the DSG perl code.

Buttons to create: (in a graphical-editor way)

• New structure
• Add structure
• Hide structure
• Dissect structure
• Highlight structure
• Zoom in/out
• Rotate all 6 ways
• Reset camera
• Save/load

To do:

1. Find an FTP program.
2. Start adding buttons.

---

Thursday 7/18

Today I tried to flesh out my test code, and got somewhere, although not very far. Here are the classes so far:

• Starter: An Applet that calls up a SkandhaBox and a New Structure button, and will have a bunch of other buttons. When you click on a button, it calls that button's makeCall() method.
• SkandhaBox: A Canvas that makes calls through the server connection and contains a SkandhaOutput object.
• if_termserv: the server connection.
• SkandhaOutput: A Component that has an image, which starts as "No Scene Loaded" and can be updated to one generated and put somewhere by the graphics server.
• SkandhaButton: A Button template for all the different buttons. Each one will be a kind of operation, and have its own class, and make its own skandha call, like Bruce's code.
• NewStructure: The first kind of button, meant to put a new structure in the box.

All of this works so far, except that the skandha calls that NewStructure makes aren't putting an image where they're supposed to. By checking against a known image, I verified that SkandhaOutput is updating its image correctly, but the URL where the new image is supposed to be doesn't exist. From looking at the builder_viewer code from the DSG, I thought that a "cgi-action" and a "xsks-snapshot" call would do it, but either they aren't rendering the image or they aren't putting it in the right place.

To do:

1. Modify the DSG code so it prints into a file whenever it makes a skandha call, and prints exactly what that call is. Then use the DSG to make a new scene and check the calls to see what I'm missing, and fix the NewStructure button.
2. Make it able to take user entries for the structure and hierarchy (in a pop-up frame, maybe?)

---

Friday 7/19

Important progress today. :) The main difficulty is solved- it can pull up an image created by the server from my commands.

Changed NewStructure to AddStructure, since that's what it turns out it does. This would be more useful in the context of the program anyway, so I may not even need a NewStructure.

When you press the AddStructure button, you get a frame (although ugly) that lets you enter structure and hierarchy, and when you hit 'Display', the frame goes away and it displays the image. You can do this multiple times and it'll keep adding images. It saves the images in my dsg/results directory under the name of the latest structure added, with spaces replaced by underscores.

To do:

1. Decide on the initial design- make it as nice as possible before creating any more classes.
2. Fix package, protection, and inheritance issues.
3. Make some more buttons.