Croquet & CITRIS

CroqueTweak: Connecting fields

2005-05-12T10:59:00.000-07:00

Bert explains the proper tweak way to wire up two fields. Very useful.

CroqueTweak: Connecting fields

Tweak gotcha..

2005-05-05T16:19:00.000-07:00

This one took hour or two to down. I wonder if I am abusing an idiom.

I wanted to create a dialog with custom behaviors so I did the following.

d := CFileSaveDialog new.
d costume: CCFileSaveDialogCostumeCITRIS new.
d openLabel: 'Test Custom Dialog'.

then in CCFileSaveDialogCostumeCITRIS>>initialize I added changed around parameters:

directoryList costume: CTreeWidgetCostumeCitris new. "works"
player sorter primarySort: #compareType:with:. "does NOT work"

The problem is the timing. initialize gets called at the end of the new, and before the costume: call, so player in initialize has not been set to d. Instead CPlayer has silently stuck in a default CFileDialog that gets modified and then immediately discarded.

If I move the player modifying line into onPlayerChanged, it is all good.

Tweak values & players

2005-04-29T12:02:00.000-07:00

Ok, I think I am getting a hang of the tweak way of thinking.
Lets say I have a CColorPicker & I want to use it in a dialog & do something with it. There are a couple of ways of doing this.
The color selected by the user updates the colorPicker's value. So I can:

In the dialog's initialize, call self startScript: #doSomething when: { colorPicker. #valueChanged}
in the doSomething method (which should prob be called onColorChanged), put . I think that just tells tweak to magically add the line above to the init for me.
I can call colorPicker player: ( self fieldNamed: #someField ) which puts a CFieldReference into the colorPicker as it's value. So the field in the dialog is updated in sync with the colorPicker's value. This has something to do with Tweak's virtual field mechanism, which I don't fully understand, but it seems very cool.

Tweak - good first impressions

2005-04-26T11:07:00.000-07:00

I have been converting our morphic popup menu's over to Tweak. Our needs have all been simple so far, so not a deep test, but so far so good. The code has been pretty clean and does what I would expect it to do. And I have been enjoying the "do something wrong, get an error message, fix it and keep going" experience that I have been told is the really excitement about squeak, but has never really worked for me in Croquet, where it has been more like "do something wrong, restart the image, search the recent changes log to recover your code, make a small change & repeat". But I am now seeing the fun.

We are working with Tweak 1.0, in the Jasmine image, which, I think, puts us two versions behind. The mailing list says they are now working on 1.2 for Squeak 3.8. Hopefully we will see grand unification sometime this summer, with a 3.8 version of Croquet bringing us into the Tweak mainstream.

Other big news around the office here is that I set up the Mantis bug tracker on our server for the digital gallery project. It's much easier to use that the wiki arrangement we were using before. And best of all, it makes Orion happy.

Citris Gallery Builder in the News

2005-04-19T12:25:00.000-07:00

http://www.uchri.org/newsletter/HASTAC/Issue1/VirtualMuseum.html

(If only they were not using a screen shot from the obsolete Torque based version)

Tweak to the rescue?

2005-04-15T17:02:00.000-07:00

Our basic problem is that our target user base is people who are not excited about computers. So we need an interface that is not just usable, but is actively seductive. And Morphic is not it. So what about Tweak?
Andreas says he thinks they are close to being stable enough for "outside consumption". And pointed me at their brand new documentation project. Honestly, I am probably getting to old to be a programmer, as the thought of a bleeding edge UI toolkit just fills me with dread. But, DAS says it is the future, so effort put into trying to get nice Morphic behaviors would just be wasted. And I just had a good talk with Howard Stearns (in Julian's group at U of Wisc) about their interface work. (Note to self: keep up with his blog. Too bad I can't get a clean RSS stream for it). Seems they have been having pretty good luck getting tweak to do what they want, although only by attaching it to the Morph. They haven't gotten it into the world yet. Fortunately, that is all we need.
Unfortunately, Andreas does not have Windows look & feel on the todo list. So if we want if, we'll have to do it ourselves...At least for the moment.
Well, enough gathering external information, nothing for it but to jump into the whirring blades of death & see what I find.

Update: the tweak tutorial does not work with the version in Croquet. Drat.

Meeting with Croqueteer

2005-04-14T17:46:00.001-07:00

Orion & I had a great meeting with David A Smith this afternoon. Croquet always seems so much more real when David is in the room.

Big Stuff Coming

David Reed has extracted TeaTime from Croquet core. He will continue to work on TeaTime and David Smith will be responsible for integrating it in to Croquet as a discrete module. Supposedly TeaTime is working inside it's test environment. I cannot wait for this! It is so painful learning about meta & all its subtleties knowing that it is soon to be replaced.
New Interface approach. DAS is moving all the nutty pointer & event code out of the camera & render loop and putting it into special interface portals, called Filters. This could make the UI work much simpler. He gave us his prototype to poke around in. Very exciting. Especially nice is the idea that the filters can be in the world, or attached to your screen. There is something really sexy about UI's & custom views that you can tear off and drop into the world. And David demo'd ghosts, objects that appear to be in the world but really belong to the filter & can only be seen through it. Could be great for annotations.
Tweak - don't know that much more about tweek than before David came, but it is definitely going to replace Morphic as Croquet's 2D UI & scripting language. We are not so interested in scripting, but we desperately need a 2D UI toolkit that can impersonate windows. Our target users don't want a double click to be exactly what they expect it to be, or they are prepared to walk away. Unfortunately Tweak is not stable yet & David cannot recommend us jumping on it yet. Much pain here. He recommend talking to Andreas about Tweak in general (good luck to us) and Julian & Marc b/c they also have users who need to not be surprised. David thinks a Window's mimicking toolkit is fine, as long as he doesn't have to use it (which is to say, Croquet must be flexable enough to work with other toolkits). This is going to continue to cause us trouble, I think. A clean UI toolkit is an entire project in itself. I wonder if this is something we could through a couple of undergraduates at?
Farther out & very interesting is moving Croquet to a JIT backend. Squeak becomes just one of the platforms that Croquet speaks, including C & Python and maybe more. Huge potential speed increases, which we would love, especially loading big/complex 3D objects.
Nearer term - Croquet will move to Squeak 3.8 (or just possibly 3.7). So it looks like David is going to wrap #1, #2 & #5 up into a new release - Croquet 0.2? Ah but when, that is the question!

Smaller stuff

Probably the best thing we found out in the conversation is that DAS is using feedback from us to help guide Croquet's evolution. Sometimes we feel like we are shouting into the void here. It is very good for morale to know that the void is listening.
Avatar switching - it has worked at some point. FOLLOW UP
WorldBase & file streaming - he has no idea where this is, but thinks we could probably weld on the file streaming without too much trouble if we need it sooner that the whole WorldBase package.
High Res Object - we are having trouble with 10K vertex objects. DAS said to up the depth of the bounding spheres & check out the buffer limit in openGL.
Level of Detail on high-res meshes - DAS has great C++ code to do this, based on paper by Hughes & Hoppe - and would be just tickled if we wanted to take it on.
Lot's o' Text - ditto for dynamic texture management. Maybe once the JIT is in place, he will just be able to use all his old C code?

Lots of info for a short meeting. The really fun thing with DAS - Orion & I are constantly saying to each other "why in the world does it do that?" and then just shrugging. David knows.

Also, David will not be at the May 18th Croquet Consortium, but thinks we should be, if only to get to know the other players.

We're got competition!

2005-04-08T10:22:00.000-07:00

http://www.arco-web.org/TextVersion/Description/Description1.html

ARCO - Augmented Representation of Cultural Objects.
"ARCO is a research project, funded by the European Union, aimed at developing technology for museums to create 3D Virtual Exhibitions on the Web."

Lot's of documents, especially on XML based object representations.
Nothing since 2003. Probably another dead project.

Links to a spin-off http://www.arco-web.org/vmesite/index.htm
VME - Virtual Museums Exhibition; put that site barely exists.

Portals Good, Crashing Bad

2005-04-04T15:01:00.000-07:00

The portal generation all turned out to be very easy to work with. I ended up sticking with morphic for UI. Couple of fun brain twisters once we go collaborative. Got to remember that my currentSpace might not be that same as yours. Any meta'ed calls that effect the currentSpace need to have that space handed into them.

On the downside, Croquet continues to be massively unreliable. We had a public demo today & that damn VM crash is like a plague. We narrowed down our features to only the most reliable & it still crashed twice durning the demo. And we had to abort showing even the basic collabortation at the last minute. It all worked fine friday, but this morning, with the exact same set up, no go. One image or the other froze up on connection every time. Ugh.

Creating Portals to new galleries & Croquet UI

2005-03-24T13:25:00.000-08:00

Ok, I am back working on the gallery builder (after an extended detour back to the java web apps I was working on last year).
First feature on the todo list is adding an interface to create portals to link gallery with different themes. The immediate question is what kind of GUI tools to use. There is morphic (the current squeak toolkit, which is nice, but we've been warned that it will be unsupported has Croquet moves forward), tweak (maybe the next generation, still in active development with little docs or examples), or building something out of TObjects. Also there is David Smith's intriguing declaration of a completely new UI & huge changeset coming down the pike. Prob the best bet is to use Morphic until I can't & see what has baked up by then.

CITRIS Digital Gallery Builder Summary

2005-02-02T13:03:00.000-08:00

The CITRIS Digital Gallery Builder is a collaborative virtual gallery system for the humanities.
The main idea is that it allows users to easily build 3-dimensional virtual galleries which contain various types of media, and which can then be viewed and modified collaboratively by multiple people at once over the internet. This allows both for the creation of group curated spaces and for the viewers to actively engage the source material.

"Digital Galleries" are fairly simple structures emulating real-life exhibitions and collections. Visitors find themselves in a virtual space composed of various rooms, with 2-dimensional and 3-dimensional artifacts presented in the space. The user is represented by an avatar which they can navigate through the 3D space.

The CITRIS software is built on top of the Croquet system, which allows for group collaboration and interaction within the space. That is, several people may have avatars present in the space at one time, can interact with each other, and further can interact with the gallery itself. Examples of interaction include discussion, annotation of artifacts, adding hyperlinks to artifacts, as well as introducing new items into the gallery and modifying the layout of the gallery and contents.

Currently supported media types are:
Images (JPG, PNG, BMP)
Video (MPG)
Audio (MP3)
3D Objects (ASE)

Support for additional media types, especially 3D file formats, is planned.

While the alpha version is not yet publicly available for download, CITRIS is looking
for interested users who may want to provide feedback on the initial prototype.

Documentation and screenshots are at http://www.citris-uc.org/hosted/projects/ith/gallery,
and links to the user group, Croquet, etc are at http://www.citris-uc.org/hosted/projects/ith/gallery/#Feedback.

Picking in overlays now working.

2005-01-21T13:56:00.000-08:00

David Smith just made my life my easier by modifying TSpace & TUserCamera so picking in an overlay just falls out naturally from building an overlay with a TUserCamera. It's a little frustration that David can solve a problem that has been plaguing me for weeks with a couple of deep tweeks...and now pretty much any mistake with an overlay results in the image freezing...but such is life on the cutting edge.

Having a working top-down overlay in the corner of the screen makes me want to be able to toggle the two views: have the top-down view be the dominant image and the front facing view be in the corner. This could get confusing - there is one TUserCamera that managers the other TUserCameras as overlays. It seems like TUserCamera was originally a kind of catch all for all the things they didn't want to put into the TeapotMorph & I bet it was intented to be a singleton. The main TUserCamera (activeCamera of the TeapotMorph) is resistant to tampering, but what about creating an additional overlay with the front view in it?

Yay, that works. I wonder if David would consider killing the main Camera render and just render it as an overlay. very flexable.

Pointer Enter & Poiner Leave

2005-01-14T13:31:00.000-08:00

More event passways. The last entry discribed how a pointerDown event makes it to a componant that the mouse is over. This path is the same for pointerUp and pointerMove, but pointerEnter & pointerLeave have their own thing going on.

Those events are generated in TRay >> resetSelected, which is called for the activeCamera's pointer in TUserCamera preRender. Remeber that any TRay in a scene will select an object that it is pointing at in the render loop. resetSelected examins the ray's current selectedObject and it's lastSelection object to generated appropriate calls to pointerEnter, pointerLeave & oh yeah, pointerOver (which is called continuously on the selected object for as long as the TRay points at it).

Notes:
1) The TRay only generates the pointerX events if it's doSelect is true, so the camera's downRay does not trigger events.
2) The TRay is handed to the componant with the event, so you could have an object that responds differently to being selected by different pointers.
3) I wondered why these events were render based & not based on mouse event until Orion reminded me that objects in the scene can move themselves in front of the pointer. The render bases select can succesfully select those moving obejcts.

More Event Processing

2005-01-07T13:15:00.000-08:00

I am still working to get a complete mental image of the event flow. Lets follow a left mouse down event from Morph to TObject in the world.

TeapotMorph >> handlesMouseDown is true, so TeapotMorph >> mouseDown is called, which calls activeCamera mouseDown.
TUserCamera >> mouseDown determines that it is a left (red) button, and calls
avatar selection: pointer selection pointerDown: evt.

"pointer selection" returns the TObject picked by the activeCamera's TPointer the last time the TPointer was rendered, which is happening constantly, whenever the TSpace is rendered.

TAvatar >> selection:pointerDown is where it gets fuzzy for me. The TAvatar belonging to the activeCamera has it's own distinct TCamera and TPointer. The class comments say that the TPointer is a replicated copy of the pointer in the activeCamera, but the only replication I have found refers to positioning the avatar's TLaser. It is also unclear what purpose the avatar's camera serves - the comments refer to it as a pseudo-camera.

Anyway, TAvatar >> selection:pointerDown first sets the avatar's camera's localtransform to that of the selected TObject, then sets the avatar's pointer's selected TObject, and then calls pointerDown on the avatar's pointer. Note: TAvatar has a selection:x: message for each possible event and they all do the same thing.

TPointer >> pointerDown then examines the pointer's selected TObject, and if it returns true for isComponant and handlesPointerDown, it's handlePointer message is sent. Thus the mouse click has made it from the morph to the TObject.

More TPointer

2004-12-10T17:04:00.000-08:00

More important things about TPointers.

* They operate automatically (as do all TRays). Put one in the scene graph and it picks every render cycle.

* Once TPointer has selected an object, it will not test any other items unless they are closer that the currently selected object.

* There is something special about the TPointer attached to the TAvatar that allows it to actually interact with objects in the scene. This has to do with replicated vs non-replicated picking....need to know more about this.

TPointer & Event Processing...

2004-12-10T09:55:00.000-08:00

I have been learning about the Croquet event processing loop, in my attempt to get a pickable overhead view.

1) It all starts with Squeak and Morphic. The TeapotMorph is just another morph as far as Squeak is concerned. By default it registers itself for the full compliment of mouse and keyboard events.

2) I haven't fully groked Squeaks focus handling. Sometimes it uses mouse-over, sometimes it is click-to-focus. Unfortunately, click-to-focus does not seem to work on the TeaportMorph and keystrokes continue to go to the last selected morph. You can force it by putting this in a mouse event:
ActiveHand keyboardFocus: teaportMorph.

3) The TeapotMorph's default behavior is to route all it's events to it's activeCamera, which is a TUserCamera. The interesting call for me is camera >> pointerXY: evt position. This takes the viewpoint coordinates of the mouse and updates the TPointer that is attached to the userCamera.

TMPEGDisplay

2004-12-07T10:19:00.000-08:00

We now have a working simple MPEG movie player in our Croquet Gallery. It would have been very easy to just embed one of the the two morphic players in a TMorphMonitor, but we have decided to go 100% Moph-free wheneven possible. The winning stratagy was to have the player be a subclass of TRectangle with a texture, and the MPEGFile object's videoReadFrameInto on that texture's form.

Interesting/Weird Stuff:
1) The default TMaterial causes my player to be completely invisible. Setting the material's ambiant alpha to 1.0 is a must.

2) The MPEGDisplayMorph has code that looks like it is sync'ing the video with the soundtrack, but it is not. It's just making an estimate based on when the soundtrack started playing & how much time has passed, which is why it does not handle pause. I keep my own starttime & reset it on pause.

3) Squeaks mpeg player seems to choke on some of our mpegs. Chopping them up into smaller segments makes it happier. But chopping involved re-encoding, so who knows.

4) I experimented with rendering the video on render vs step. Putting it in render does get more video frames on the screen (on my computer I average every 3rd frame in step and every 2nd frame in render), but the video is very jittery when done in render, which surprises me. Why would one render cycle take a different amount of time than the next?

Unsafe at any speed?

2004-11-30T10:02:00.000-08:00

Things have been puttering along at CITRIS world headquarters, as our Croquet-only gallery builder demo nears completion, things continue up and down. Up, because crafting using interactions & UI elements is so much easier in Croquet that it was in Torque; Down, because Croquet remains amazingly unstable. Not a day of development goes by without a couple of VM crashes or image freezes, and some days get well into the double digits, especially with my recent venture into Video. The really frustrating bit is that most of the VM crashes seem to be either unreproducible, or reproducible only in one particular saved image.
My current hunch is that our system is particularly vunerable because it is a hybrid of 2D Morphic and 3D Croquet & that this combinantion has not been tested much. So our current plan is to phase out the Morphic code as soon as we can & keep our fingers crossed.

Onward

2004-10-22T17:08:00.000-07:00

I managed to force Scott's Gallery Builder into the Jasmine image. It's a little bit crippled by my pattented "hack off any code that generates an error" approach, but it is still functional. Yay! Now to get it talking to Croquet. I had this working back in August, with Solar, so it should go pretty quick...but not probably not quick enough for our Citris Corporate Sponsors Day presentation on Tuesday. Ah well, one last chance to show off the cute Citris Alien from the Torque engine.

Squeak Change Sets

2004-10-22T13:32:00.000-07:00

Scott has explaned to me why his change set could not be filed-out and then filed back in. Turns out there are timing issues with his change set & he had to hand edit his .cs file before it could be filed-in. I guess B1llG must be right about my naivette, because I find this new bit of information horrifying.

Scott also gave me an overview of the steps that would be needed to get Jasmine working in the 3.7 image, and it is pretty hairy, and not even possible unless I get currently unpublished bits from the Croquet dev team. So it looks like I need to continue hacking pieces out of the Gallery Builder until it will work under 3.6. Scott gave me another clue there too: the 3.7 image automatically calls initialize on objects when they are new'd...which Morphs do in 3.6, but non-Morphs do not.

Merging headaches

2004-10-21T17:59:00.000-07:00

Looks like I was asking the wrong question last week when I asked about running Jasmine under the 3.7 VM. As everyone said, that is no problem, the Jasmine image runs just fine with the 3.7 VM. But Scott's code relies on infrastructure in the 3.7 image, not the VM. Infrastructure which does not exist in the Jasmine image. Oops. So, I spent today alternating between:

Failing to get Scott's code running in the Jasmine image. I was able to chop out most of the references to horizontal scrollbars, but ran into an unknown message that I cannot track down.
Failing to get Jasmine to run in Scott's 3.7 image. I thought doing a file out on all the Croquet catagories might work, but the Croquet image has changed some of the basic Squeak syntax rules to allow calls like gl glVertex(0.0, 0.0, 0.0), and I don't know how to get those changes into the 3.7 image. So I just get lots and lots of syntax errors.
Being really really surprised when I did the following: file-in one of Scott's .cs files, immediately file-out it, then close Squeak w/out saving, reopen Squeak, file-in my new .cs file and presto - a stream of errors. I don't know if this is a bug in Squeak, something really weird with Scott's change set, or, more likely, my mental model of how change sets work is completely wrong.

We're going for it

2004-10-19T10:46:00.000-07:00

Not yet fully blessed by the powers-that-be, but it looks like we are going to push ahead with using Croquet as the technology behind our IT & Humanities project. It's been a tough choice (and one I know I still might live to regret), but Croquet wins out by: being open sources; having a vision that is closely aligned with ours; and seeming to be on the road to developing a vibrant user community. Fingers crossed.

First step is to get Orion up to speed on Squeak. The cursing you hear in the background is him learing the new keyboard combinations. Not that I am much farther along the learing curve than he is. Scott spent the summer teaching me to become one with Squeak, but my instincts are still java/perl/c++ based. Right now I am tweaking Scott's UI on the Gallery Builder to suit my more Window's flavored preferences.

The goal is to replace Torque in our demo by the end of the month, in time for our next meeting with the Stanford Humanity Labs folk.

Interesting things to try:

File-out'ing the Jasmine code and running it in the 3.7 image, with the Gallery Builder.
Putting the Gallery Builder into a project and openning it inside of Jasmine. This will be amazingly cool if it works.
Writing some SUnit tests.

Community Developements

Julian has a blog. Yay!
The Squeak guys at Georgia Tech have set up a Croquet wiki. I suspect this will become the defacto offical one.

Reminders & torrent

2004-10-14T01:19:00.000-07:00

Need to remember to talk to David S about his blog post: Walkthrough in Croquet - this seems very closely related to what we are trying to do with our Gallery Builder.

Also, need to figure out how to persist changes to a world. SolarCroquet could save images with a running Croquet window, TeaTime could not...according to the wiki, Jasmine is like TeaTime in this regard, but I need to confirm for myself. Also examine the export & import functions...I believe they are used for caching models, but maybe that can also save an entire space.

People are definately interested in Croquet. In 48 hours my torrent has uploaded 35 copies worth of data to other downloaders.

Blogs

2004-10-13T21:28:00.000-07:00

My last post mentioned Takashi Yamamiya's blog Squeak Everyday, which served as the final bit of motivation to get me to start blogging my Croquet experiences (which I wish I had been doing over the summer - I think if I had been expressing my problems a bit more publicly we would have resolved the communication issues much faster). Anyway, more important than inspiring me, Takashi's blog also inspired David Smith, Croquet's project lead, to start his blog Croqueteer. I think this is great way to communicate. It helps build up a sense of community, and I know that it is a real comfort to those of us building projects on top of Croquet, to have an idea of what the dev team is thinking about.

I found out about David's Blog on the page of Croquet links Julian Lombardi (U of Wisc) is putting together here. I have asked him to put a link to this blog up there too...which makes me nervous, but I figure if I expose my ignorance to the world I will learn the truth faster.

Day2

2004-10-13T20:01:00.000-07:00

Well, my day two impressions are mixed. Jasmine has lots & lots of bugs. Seems like I cannot go for more than minute without doing something that pops up one of those cute debug dialogs. But, they are doing an amazing job of responding to bug reports and fixing things ("They" being David Smith, Andreas Raab & Mark McCahill). They fixed one of my bug reports within 12 hours. This is exactly why it was so important to me (and them too, I am sure), that they get out a public release. A small group just keeps repeating the same tests.

They could use some automated tests to help avoid regression thou. Takashi Yamamiya mentions in his blog entry that he got a Croquet Unit Test runner working with TeaTime (which then changed breaking his code) and that he has started porting all his work over to Jasmine. Very exciting.

I am told that Takashi (a core squeak developer) is working on a Croquet game project, Chain Reaction, with Yoshiki Ohshima (ditto re: squeak, out of U of Kyoto) & 3DSolve (a North Carolina simulation and learning software company). I should find out more about this project.

Jasmine under Squeak 3.7

2004-10-12T13:54:00.000-07:00

Good news from the mailing list. Jasmine should work under Squeak 3.7. That is good for my project, because over the summer we had a squeak contractor (Scott Wallace, one of the original Squeak developers, and all-around good guy) build a great 2D gallery construction tool, which uses some 3.7 specific tools.

This is potentially doubly good, since the reported lack of upward-compatability has been a concern of mine about squeak in general. I suspect I have not fully grokked the relationship between an particular VM and a particular image.

Jasmine: First Look

2004-10-12T11:26:00.000-07:00

This blog will be about my experiences evaluating the Jasmine release of OpenCroquet (ie: The Croquet Project) for the CITRIS IT & Humanities Project. I am just relating my impressions & observations, in no way to I speak for the Croquet development team.

I first attempted to evaluate a pre-release version of TeaTime 4 or 5 months ago & found it unacceptably fragile. I then spent some time with SolarCroquet, which had been used for creating all the demos that the Croquet team has been showing for the last year. I found solar a little rough, but basically stable, and a joy to use compared to TeaTime. Unfortunately work on Solar had stopped in preference to TeaTime, so the odds of ever getting the bugs that were in Solar fixed seemed slim. I decided to evaluate other approaches.

Fast Forward to now. The Croquet team has wisely decided to split their efforts: TeaTime has become MadHatter, and continues as a research branch; SolarCroquet has been brought back from the dead, gotten all the TeaTime advances that can be safely backported to it, polished considerably and just released to the public yesterday as Croquet0.1 aka Jasmine. Very exciting. The plan seems to be to ripen the advanced networking features in MadHatter, and move them into Jasmine once they are stable, while attempting to maintain upwards-compatibility.

Honestly, the most exciting change I have seen so far is that a week ago the dev team started using a bug tracking system. This shows that they are serious and it is a great way for the rest of us to see what they are working on, their rate of progress, etc. The U of Wisc guys have also set up a Croquet wiki (croquet/any0ne to access (0=zero)), which is a great idea, but so far no one is using it.