Post mortem (almost)

The crunch week is over (and has been so for a couple of days) and it is time to reflect.

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.

Day 6 & 7: Nearing the end of the crunch week

We are on the final day of our week of code crunching. 
Kasper has during the last couple of days rewritten the object storage a couple of times, but have now decided on a (so far) final design.

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.

Second screenshot

Day 5: First screen shot

Today we decided to try to imitate a classical laboratory notebook in the prototype user interface. Meaning that the interface is build up of a lot of pages resembling the pages of a paper notebook.

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.

Day 4: Back on track

Clemens did further work on the move/drag-n-drop instrument which can now modify the underlying structure of the data model. This enables to drag-n-drop objects from one open document to another. Furthermore he did some code cleanup and created a GUI component for selecting an active instrument.

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.

Day 3: Light on new contributions

This day has been characterised by us revisiting a lot of design considerations – meaning that a lot of code had to be rewritten. I had to rewrite some (nearly working) code for doing nice drag and drop, to work under some new conditions breaking it completely. This has taken most of the day – and it is still not working perfectly. 

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.

Day 2: Move instrument and basic network communication

While Clemens finished the select and move instruments today I worked on getting the socket connection between the python client and the java backend up and running. After I got basic communication working I decided to use google protocol buffers for marshaling. I also got the design for the object storage and protocol down today.

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.

Day 1: Status

Besides that I have been hung up some parts of the day on family related stuff, and friends needing help moving we have actually made some progress.

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.

The PyObjC/Cocoa experience so far

We decided to write the client GUI in Python using PyObjC and Cocoa. Although I have extremely low millage on any of those three technologies the experience has been great so far. Except from small problems understanding exactly how Cocoa Bindings works and battling a little bit with interface builder the only real challenges so far, has been regarding garbage collection. So far we made the following two lessons:

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

Some background material added

I have added a page with some background material, including a link to the to-be-presented CHI paper on VIGO.