thanks for the info igor. maybe we could plug customized UI handlers for different devices, with different "raw" events. It would make coding and managing each of them, a lot simpler than now. Fernando On Wed, Sep 26, 2012 at 2:14 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 26 September 2012 13:12, Fernando Olivero <fernando.olivero@usi.ch> wrote:

...

Igor, i agree 100% percent with you!

VM shouldn't have all the responsibility of handling a "single UI window".

I've tried in the past to look at VM code, which handles this responsibility and change it, (no UI handling in the VM) ..but it proved to be a difficult task! We need a simpler, cleaner VM, pluggable UI handling would be awesome!.

Do we need the pointer or Null at all in the VM? Cant the io handling be done completely separate from the VM? A native app for each platform, or something built using NB.

This is highly platform-specific. The ioProcessEvents called by VM during interrupt , so, platform-specific code can use it to signal any pending external events. Interrupts is also used by scheduler to switch to another process when something happens (like socket has new data to read, semaphore signaled etc). So, if VM won't support interrupts it will be highly problematic to support green threading execution model. And, of course, an interrupt is naturally a well-defined safe point in VM execution. So it is logical to have an entry point there, where plugin(s) can hook-in and add own custom event handling procedure, without need for patching a single global ioProcessEvents() function over and over again.

If at some point you'll have two independent modules (plugins) in VM which want to put own custom handling code there, you can always do it like following pseudocode:

(during plugin initialization) oldHandler := ioProcessEvents. ioProcessEvents := &myHandler.

(during call ) myHandler self doMyHandling. call oldHandler

Now, of course it is a question, how often you may need that: a module which adds own custom handler for VM interrupt. Maybe we don't need that much flexibility? But do others see other way of freeing VM from assumptions and tight coupling with different parts of system?

-- Best regards, Igor Stasenko.