Skip to main content

Lend me a Hand

The last Tweak updates broke our Tweak-based Croquet application, objects did not respond to clicks anymore. I first suspected changes in Croquet, but the latest updates there didn't look suspicious. But neither did the last couple of Tweak updates. Investigating further and sprinkling debug output here and there I discovered that pointer events were offset. Moving the Croquet window to the upper left corner confirmed this, all of a sudden everything worked normally. What was happening?

Well, living in a shared world isn't easy. Morphic, Croquet, and Tweak interact very closely in the TeapotMorph, which bridges between those three worlds. Without Tweak (that is, without calling initializeTweakWorld in your initializeDefaultSpace method), the TeapotMorph uses the regular Morphic event dispatching mechanism which leads to calling the event handling methods keyDown:, mouseDown: etc. which in turn dispatch the events to the activeCamera, that is, into the Croquet world.

When using the Tweak overlay, this does not happen, but all events are translated into Tweak events and dispatched into the Tweak world. The initializeTweakWorld method not only sets up the Tweak world, but also registers event handlers (onKeyDown, onMouseDown etc.) that are called when no Tweak object handles the event itself, like when clicking outside a Tweak window. These event handlers translate the Tweak events back into a Morphic event and call the regular non-Tweak TeapotMorph event handling methods, from where processing continues as before.

Now translating the events back and forth also involves offseting them, because Tweak uses relative coordinates (every Tweak object defines its own coordinate system) whereas Morphs use global coordinates. Translating into Tweak was still working fine, the Tweak objects were acting just as expected. However, the back translation was wrong. In fact, the event we got back already was in Morphic coordinates, so when we applied the offset again it was way off. The problem is that events were not explicitely passed around, but rather we used the active hand's last event.

The Hand in Squeak is the object that injects user interface events into the world. Its visual representation is the mouse pointer, but keyboard events come from the hand, too. Because there can be multiple hands in a world, there's a global variable ActiveHand which is set to each hand while processing events initiated by that hand. Multiple hands, you ask? Yes, there was collaboration even before Croquet in Squeak (so each user in a shared Morphic world had a separate hand), and also multiple mice can be used independently, if that is supported by the VM (I once wrote a plugin for that using the XInput extension under Linux).

Now until last week, Tweak also did set ActiveHand to its current hand while processing an event. This had some odd side effects, for example, when some code expected ActiveHand to be a HandMorph (as is the case in Morphic) or a CHandPlayer (as in Tweak). In particular, when running a Tweak overlay in Croquet, which still largely assumes a Morphic environment, this led to confusion. But we pretty much ironed out all these wrinkles.

Except for the back-translation of events coming from the Tweak world, which happens in a Tweak process, so we fully expected the active hand to be a Tweak hand in this handler. But Andreas removed all references to ActiveHand from Tweak in an otherwise innocuously looking update (comment: "Various preps for upgrading to 3.8") so we did, in fact, by referencing ActiveHand get the original Morphic event instead of the expected Tweak event.

Just removing the offset would not work because you might have or might have not loaded that update. So we need to access the active Tweak hand, but without accessing the ActiveHand global. This is easiest if you are programming in Tweak, because every CPlayer has a field aptly named hand that refers to the active hand. Outside of Tweak you must do it the hard way, which is getting the hand from the active process. I'll talk about Tweak processes in another post, this one is already getting too long.

So, to make a long story short, if you fetch Croquet updates now, everything should be working fine again. There are two new methods in TeapotMorph, morphicHand and tweakHand, that return the right sort of hand (of course, the latter returns nil if Tweak is not running). They are used in the two methods I found where it actually matters, namely bringing up the halo which needs a morphic-hand, and back-translating events, which uses the tweak-hand.

That's all for today. Happy Tweakin'!


Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers running your multiplayer code. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: are hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully control

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Smalltalk Bindings for Minecraft Pi

The Raspberry Pi is a cute little computer. Quite cheap at $35, you plug in USB keyboard+mouse and a TV as monitor. And it is surprisingly capable, even for running 3D games. One particularly interesting game is Minecraft: Pi Edition . As in other Minecraft versions, the main goal is to create a world. But unlike other versions, you can not only use the tools provided by the game, you can make your own tools! That's because it comes with a programming interface. The Minecaft world is made of little cubes, and you normally place or remove these blocks by hand, one after another. This is fun, but for larger structures also quite cumbersome. For example, this rainbow here might take a long time to construct manually: But I did not make the rainbow by hand. I programmed it, using the Smalltalk programming language. It's just these dozen lines of code in the Squeak programming environment: Squeak is already installed on the Raspberry Pi, because Scratch was made in Squeak