Re: [Pharo-project] [Vm-dev] Re: The roadmap aka fight plan to make image control host window
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. Fernando On Wed, Sep 26, 2012 at 2:57 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Remember, Andreas added a nice new feature into (at least) windows VMs, where upon startup it showing a splash image? By reading a .bmp file and delaying rest of process by couple seconds. That maybe useful. But what if tomorrow, my customer will want to keep showing it, till user click on it? What you will do? Right! Go and hack VM. And what if he will want to show splash and progress bar while loading/initializing stuff? Another shitloads of code into VM? And something fantastic, what if customer would like to use different image format for splash screen, png, jpeg? And what if we would like to automatically download the splash image from web site before showing it?
So, where is the end of this? When you will finally say "enough", we need proper window management in image?
-- Best regards, Igor Stasenko.
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.
participants (2)
-
Fernando Olivero -
Igor Stasenko