replicator.org ... continuous garbage collection

Zombie objects and the event-system are finished. The event-system is preliminary, but it is now possible to work with multiple applications while switching through them using the Focusmanager. Yep! Again, one point less on my todo list. But the next is near:

Currently, when a new application is started, it is placed in a slot (so I call the 3D equavilent of a window). A slot is an oriented cubic extent, where applications may show their 3D appearance and interact with the user. The slot management in its current state is not sufficient to continue development and is one of the more aesthetically relevant modules that needs special attention.

For example, a slot manager could organise new applications in a grid, or on the sides of a cube (for 2D applications) or on a cylindrical surface, where the user can operate inside the cylinder. Slots and slot spaces (the space a slotmanager creates and is responsible for) should be configurable, and there may be even slot spaces lying inside other slots. This is similar to a hierarchical windowing system (on Windows for example, buttons are subwindows, too).

A few thoughts and requirements:

• applications must be able to be moved from one slot to another (probably to a different slot space).
• There may be persistent slots, these are slots tied to a particular application instance. So, when an application starts up it must be possible to receive the same slot of a previous session. This is very important for the user to find applications in space (and to make use of the user’s spatial memory).
• slot spaces may provide additional 3D objects (decoration) for each slot and client. It needs to be possible for the user to interact with these objects, independent of the client. One example would be a relocation button or keyboard commands for a slot.
• it would be nice to see where a new slot appears if a new application is started, the focusmanager should not immediately focus the new one.

• Slot managers must be extendable, but probably should reside in the server. Even a specialised slot manager for a client may be supported (it would be nice for an application developer to embed its own slotmanagers within the client).

I can think of a client/server protocol design for a slotmanager, to support an implementation inside the server and optionally in clients. There are a number of issues: zombie objects, event delivery and subspace management may all be difficult to solve. Perhaps in future versions, a scripting language could be used to support uploading of slotmanagers.

All in all, this topic is much more complex than I have expected. Let’s start.

It’s all about organising space, prepare for it!