[Pharo-project] The roadmap aka fight plan to make image control host window
eliot.miranda at gmail.com
Tue Sep 25 13:35:35 EDT 2012
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.
This code has been used for years in the Newspeak system which has a full
native GUI on Windows.
Going your own way creates an unnecessary fork.
> Then we need to implement a module which will manage host windows,
> and once image tells it to create a window,
> it can change the function pointer to ioProcessEvents to own function.
> This change, would allow us to temporary disable any external event
> processing (like in case of callbacks).
> Second, we should move all event-related stuff to new plugin (for
> instance, all definitions in sq.h
> like sqInputEvent , ioSetInputSemaphore() ioGetNextEvent() etc).
> For all UI-related stuff the image should communicate with a new
> plugin, while VM should get rid of all knowledge of any existence of
> UI events,
> like input semaphores, primitives for fetching them etc.
> Third, of course, all screen update/refresh primitives should be
> deprecated, and image should use new primitives to update the contents
> of host window(s).
> Best regards,
> Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev