So today, after 3 attempts I finally finished the user interface event subsystem. Thanks to elists I was capable to create a small scheduler for event handlers and a template based system similar to the signal and slots system of trolltech’s Qt framework.
I am not quite sure if this event model is finally usable for client applications, but some new concepts involved are feeling very handy compared to other event systems:
For example, event distribution is 1:n and deferred, meaning, that users don’t need to care much about object construction and destruction: they may delete objects at their will at any time. Users create event based user interface transactions, which are not interrupted, neither by any uploads to the server nor by any events these transactions may trigger indirectly.
All caused events are scheduled and the states of the objects associated are synchronised on the client (receiver) side to keep states in sync with the events (every observer may experience a different state, depending on how many events it has processed). The transactions and the subsequest event based invocations (deferred transactions) are scheduled after completion.
The user interface can be seen as a separate model, receiving input events from the server and generating output streams to the server.
One run of the user interface scheduler invokes all transactions as long as there are no more transactions (caused by events) scheduled. Between the runs, the system is frozen and all changes are sent to the server. Notifications from the server are now received and delivered to the lowest level object abstraction. After that, the scheduler gets invoked again.
It feels a little bit like a virtual machine, but without a performance drawback.
My first test was the sensor widget: a low-level basically 2D polygon placed somewhere in 3D space, which can be used to capture all relevant mouse events to create 3D buttons or other user interface widgets. The sensors work like expected and a small test program using the described machinery above is also stable.
Now, the next step is to create some 3D layouting engine to support the space organisation of 3D objects. I am not sure where to start, but perhaps it is best to port some of the layout management ideas from some of the current user interfaces down to one dimension to be able to orthogonally extend layout management to three dimensions. The layouting mechanism should be based on the event mechanism, so that contents and/or dialog/interaction extents are adjustable in realtime.
Imagine a number of dialog components in a cube, and the cube can be resized in all dimensions by clicking on sensor areas placed at its edges. All widgets should be moved/resized like one would expect when resizing a 2D user interface window. Well, most microsoft dialogs don’t resize today. But this is what users expect, and I don’t want to disappoint them.
supersize in 3d!!!