How are timing and updates handle in a gui app like an editor? These apps tend be event driven with multiple widgets containing 3d sub views, which may animate and at the very least will probably need a camera moving through it. The camera should probably be taking time into account to get smooth movement instead of jumping some fixed amount when an input event is triggered.
Whats a good way to structure the timing and updates of 3D views in this environment. If updates are done whenever input is received, then there is no traditional "game loop" running with accurate time info available, I cant figure where any continuous movement at all would reside when windows are going in and out of focus randomly, so if you plug an engine in, where does the traditional loop/timing get handled for such things?

I use a seperate thread for rendering in directX. The reason for this is that certain calls in the message loop are blocking so the usual PeekMessage() implementation that people use in games do not work properly for window based editors.
Since I'm using threads to overcome a limitation and not for performance reasons, I have my render loop acquire a mutex every frame, and my editor functions running off the message loop acquire the mutex when they need to make changes to objects the renderer uses. This definitely isn't the optimal way of doing this.

The render loop manages 4 different viewports, which are all child windows/directX render targets. I have a seperate timer for each viewport and run the typical render/update cycle on each. I also decided to handle certain input events on the render thread, such as when the camera is moved. When the render thread moves the camera, it inserts WM_MOUSEMOVE messages into the message queue, which greatly simplifies tasks such as allowing the user to manipulate objects while simutaneously moving the camera around.