[Vm-dev] Re: [Pharo-project] The roadmap aka fight plan to make
image control host window
Igor Stasenko
siguctua at gmail.com
Tue Sep 25 22:13:09 UTC 2012
On 25 September 2012 19:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> On Sat, Sep 22, 2012 at 11:22 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> First, we need to make one thing:
>>
>> Change the VM to not call ioProcessEvents function directly, but
>> rather use a variable which will hold a function pointer.
>> Initially, when VM starts, that function pointer is NULL, and so,
>> "process events" is NOP.
>
>
> Please don't reinvent the wheel. The Cog source has a variable inIOProcessEvents that controls this. If negative it disables inIOProcessEvents. If non-negative it prevents reentrancy, essential if one is receiving events from the OS. There's a primitive, primitiveEventProcessingControl, to flip it between the enabled and disabled states.
>
Yes i seen that.
But apparently, i don't want to just disable it by putting NULL, but
also i want to replace it (or wrap it) with own io handler (see
NativeBoost ;). For that, i need the function pointer.
> This code has been used for years in the Newspeak system which has a full native GUI on Windows.
>
Does that means that implementation is completely on language side? If
so, then why you need the rotten window management code in VM?
Lately, i seen Mars running native GUI (browser window) using Cocoa on
macs and GTK on linux.
(but you still have VM window hanging around, and you cannot get rid of it).
> Going your own way creates an unnecessary fork.
>
I would love to not reinvent it, but the user input handling is one of
the weakest spots in current VM implementaion.
I don't like many things there:
- VM is in control whether to create window or not
- VM in control what attributes window has
- VM in control how to translate OS (native) events to
"squeak-compatible" events, often losing important bits and making
everything crawl like hell
- VM in control when to update/refresh a window
- VM decides whether it run headless or not
- VM decides when to handle input events
list can be continued..
Personally, i don't like that image assuming that VM has to provide a
single "default" window
for it. It is image, which should manage that (if it wants to), but not VM.
--
Best regards,
Igor Stasenko.
More information about the Vm-dev
mailing list