Results:

• A remote object storage system, with a focus on easy and fast versioning.
• A preliminary user interface for a laboratory notebook.

Unfinished:

• Integration of object system and user interface, the user interface currently uses a local mockup.
• Experimentation with governors, herein control of physical equipment.
• Object inspection.

Experiences:

• Hofstadter’s law applied to our project as well.
• Gained insights in designing systems using VIGO.
• Experiences with creating “native” looking VIGO applications.

All in all the week was extremely fruitful. While we didn’t implement as much as we had hoped to, working together intensely for a week, with only a single focus paid off. We came up with a lot of ideas and gained a lot of insights into how we could continue build VIGO based systems in the future.

We intend to use of couple of days to finish up some of the things we didn’t complete in the past week.
First of all the integration of the object system and the user interface – but furthermore do some experiments with governors.

The goal for today (and hence the final goal of the week) is to get the object system properly integrated with the client. Currently the objects rendered on the screen is represented in a client side mock-up of the system – this will hopefully change soon.

On the client side a few kinks in the window handling has been worked out and we have implemented the first governor. A simple governor which annotates a page with timestamps as seen below.

The final design of the governor interface and how they are connected to the object system has yet to be done. However we are pretty certain that there will be a range of different types of governors. 

The governor implemented for timestamps are one of the simplest types of governors. When it is enabled it just reacts to changes on a given object or objects. However if one is to implement a governor to support e.g. alignment of graphical objects, the instrument on the client will have to be able to communicate with the governor to get e.g. suggested positions. Furthermore a governor for a board-game as discussed in the CHI paper, will need to be able to validate whether a given modification of an object is valid. This could be the position of a piece on a game board.

We have worked on implementing basic text-editing on a page. A page simply consists of a range of lines for text and a canvas for (yet to be implemented) free-hand drawing and placement of graphical objects. The text-edit instrument we implemented will let the user place the cursor at any position on any of the lines – meaning that it is easy to write anywhere on a page as it is often the custom to do in a lab book.

I got the object storage up and running and did some benchmarks on the performance of sending objects back and forth between the client and server. The benchmark I did was timing the following sequence of tasks:

• marshaling request in python
• transferring request from client to server
• unmarshaling  request in java
• fetching requested object from storage
• marshallng object
• transferring back
• unmarshaling object in python

With small objects (with expected average size) and the server running on a local machine this takes between 1 and 2 ms to complete. This is great results and fast enough for the user interface to be really snappy.

Kasper has experienced similar setbacks because of redesigns in the object storage.

On the drag and drop: 
Previously objects were moved by an instrument that continuously updated the select elements position given mouse events. This however clutters the system (and in the future the network) with updates. A new technique for intermediately drawing selected objects in an borderless and transparent window that moves with the mouse has been implemented. The change in the actual object is not performed until the drag operation is finished. Hence speeding up the interaction, and making it much more pleasant. Furthermore it uses Cocoa’s sexy drop shadows.

Although we spend a bit too much time on removing bugs in the object system mockup today, it definitely feels like we’re moving in the right direction. I’m pretty sure we’ll see some cool results tomorrow.

I have worked on the graphical stuff today; begun to implement visualisation of objects in Cocoa.
Typically when implementing GUIs you, as a programmer, is blessed with a range of widgets and standard libraries for getting something on the screen. However these modern libraries are all based on Model-View-Controller, but we are taking a different path with the VIGO architecture. This has the downside that when we want a textbox, we have to code it mostly ourselves – e.g. text-wrapping which is a pain.

Kasper has continued his work on the object system, but he has spend some time working on various measures for easing our debugging as well.

All in all it seems that we are a bit ahead of schedule, but things might change when we get a bit deeper into things.

If you create a new NSWindow in python you must keep a reference somewhere in your python code or it’ll be garbage collected before get a change to see it.

When creating new python  threads that will directly or indirectly instanciate ObjectiveC objects you must create a NSAutoreleasePool or you’ll be leaking objects like crazy.

Other than that we’ve had a pleasant experience with only a few bad surprises so far. We’ll be back soon with a report of the progress so far.

-Kasper