Re: [Pharo-project] decoupling the vm: UI and interpretation
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 <siguctua@gmail.com> 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 <fernando.olivero@usi.ch> 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 <estebanlm@gmail.com> 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.
On 21 December 2011 08:45, Fernando Olivero <fernando.olivero@usi.ch> wrote:
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.
.. and probably while inventing this new wheel, you can read about X server design, which having such architecture for years. :) But we need that wheel for sure, even if we need to reinvent it :) -- Best regards, Igor Stasenko.
On 21 December 2011 10:58, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 December 2011 08:45, Fernando Olivero <fernando.olivero@usi.ch> wrote:
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.
.. and probably while inventing this new wheel, you can read about X server design, which having such architecture for years. :) But we need that wheel for sure, even if we need to reinvent it :)
If this is going to end up re-inventing X, why not just use X? And I don't mean re-implementing X either, but using someone else's hard work. frank
On 21/12/11 9:10 AM, Frank Shearar wrote:
If this is going to end up re-inventing X, why not just use X? And I don't mean re-implementing X either, but using someone else's hard work.
Doesn't RFB/VNC implement something close to X Protocol?
participants (4)
-
Fernando Olivero -
Frank Shearar -
Igor Stasenko -
Yanni Chiu