YES!,the current VM was devised on 90's, maybe its time to alter it a bit now..
Esteban, in your opinion would this be feasible, in decent amount of time? Moving Display to a separate plugin. Yet remains a question, how would the "UI-pluggable VM" talk with the headless vm. I will implement a proof of concept, using some kind of IPC (for the MAc), so we can measure the responsiveness of such scheme. Fernando On Tue, Dec 20, 2011 at 1:58 PM, Igor Stasenko <[email protected]> wrote: > I wanting the same long time :) > > Having a VM which handling a platform-specific nuances and providing a > uniform interface > to language side is a great advantage. > But of course it not comes without drawbacks: you have a minimal > common functionality, > provided over all supported platforms. > > It would be cool to change the situation. > A first step would be to make a Display/events primitives optional > (move them into a separate plugin, > outside of core VM). > Like that a "default" VM without such plugin will be headless without > obligation to support graphical user interface. > The next step is, like you said, think about how to encode events > without losing flexibility and pass them to language side. > > On 20 December 2011 13:12, Fernando Olivero <[email protected]> wrote: >> Ok, i'm in favor of having everything in smalltalk too. >> >> The problem i have is the following: i want to change "how" the VM >> should announce events "were" the vm should draw >> >> Regarding the "were", currently the VM has a primitive from which you >> can specify which Form will act as the Display. But what if i want to >> render to something else than a form? >> Esteban: how does the COCOA VM draw the Display? Does it create a >> NSWindow, with a custom view, which copies the bits from the Display >> Form, into a drawing context (Quartz? OpenGL?). >> >> If we are moving towards a vectorial framework( AthensCanvas rendering >> to OpenGL or Cairo), we dont need to hardcode a "Display" a primitive >> in the vm. there's no need for such primitive. >> We just need access to the drawing context of the Pharo window, and >> render whatever we want there. >> >> We need the following: (using COCOA as an example) >> an OS window =>NSWindow >> with a custom view ==> subclass of NSView >> that creates a Cairo surface to a quartz backend, from which in the >> image side i can tell the AthensCanvas to draw into. >> >> For the event part, i should directly change the platform specific >> code for the Cocoa VM's? >> Cocoa provides higher level events and the VM is encoding them into >> Arrays, that in the image are decoded back into high level events ( >> see HandMorph>>generateEvt:from:). Which makes it hard to add new kind >> of events, specifically those originated from the trackpad (pinch, >> swipe, etc). (another BIG problem is that currently, all the VMs >> arent encoding EXACTLY the same OS events into the VM Arrays of >> events). I would like to play with the OS event encoding/decoding, to >> not loose so much in the translation. >> >> Please let me know wether i explained myself clearly, i'm still in the >> process of understanding how to detach the VM from the Bitmapped >> forms. >> >> Fernando >> >> >> On Tue, Dec 20, 2011 at 12:45 PM, Esteban Lorenzano <[email protected]> >> wrote: >>> >>> El 20/12/2011, a las 7:30a.m., Igor Stasenko escribió: >>>> >>>> I think what would be easier is to make a language side to handle >>>> everything. >>>> Unfortunately in practice this means moving substantial parts implemented >>>> in C >>>> and putting in smalltalk. >>> >>> +1 >>> It takes time... but in the long way is the best approach, I think. >>> >>>> I also don't see how separating it into 2 processes make things easier. >>>> I think it will complicate things even more, because now you will need to >>>> invent own communication schemes , which is also platform specific. >>>> And possibly it will work slower because of IPC overhead. >>> >>> They are not easier... but can be better for applications. That's the >>> "default" behavior for mac and that's the reason why you usually don't have >>> UI freezes while doing stuff (of course, not all applications -nor our vm, >>> I changed it to single process- works that way... because is harder to >>> maintain) >>> >>> best, >>> Esteban >>> >> > > > > -- > Best regards, > Igor Stasenko.
