fiat lux

In-between the problem of structuring your GUI application at higher order has caught my attention. The glaring problem of multi-core multithreading is trapping us developers. We are bound to the limitations of modern graphics system design–to our amazement window systems are themselves very complicated beasts. But while our computation and heavy-lifting parts are migrating to the multithreaded world (hey even network connections are in that area already too), GUI code is still confined to either main thread or the thread that created the component/widget in question. You don’t, can’t, dare not, ought not, may not pass them back and forth between different threads. How quaint.

In other news C++0x shows its promise with all its new syntactic constructs (many of them condensed form of popular idioms, esp. template metaprogramming) and its inherent support of modern threading control objects. And talk about lambda and better type inference. Hey but a working compiler is still years ahead. And will we be still using gcc?

(But I guess I’ll still have problem doing GUI stuff with such a strongly-typed language.)

The real challenge is how to formulate, in my opinion, GUI event and graphics model as trasnactionable operations. Animation frameworks like CoreAnimation show the way, but it doesn’t seem to have become that much generalized yet. GUI programming is in a desperate need of new models that can catch up with the already more advanced, more sophiticated way of (esp. networked) data modeling and manipulation. It’s such a scandal that database operations can be thought as series of rollbackable transactions but GUI ops cannot.

I’ll be happy to see the death of the decade-old event-loop model and its rebirth as a higher order construct. Although that seems a call for declarative UI design but perhaps we’re still far away from that.

lukhnos :: Nov.14.2008 :: tekhnologia :: No Comments »