<br><br><div class="gmail_quote">On Tue, Sep 25, 2012 at 3:13 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 25 September 2012 19:35, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> On Sat, Sep 22, 2012 at 11:22 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>> First, we need to make one thing:<br>
>><br>
>> Change the VM to not call ioProcessEvents function directly, but<br>
>> rather use a variable which will hold a function pointer.<br>
>> Initially, when VM starts, that function pointer is NULL, and so,<br>
>> "process events" is NOP.<br>
><br>
><br>
> 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.<br>
><br>
</div>Yes i seen that.<br>
But apparently, i don't want to just disable it by putting NULL, but<br>
also i want to replace it (or wrap it) with own io handler (see<br>
NativeBoost ;). For that, i need the function pointer.<br></blockquote><div><br></div><div>Unlikely. Better to call the relevant function through the FFI. If you're implementing a native gui you don't need the VM involved in deciding when to poll for events.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> This code has been used for years in the Newspeak system which has a full native GUI on Windows.<br>
><br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>Does that means that implementation is completely on language side? If<br>
so, then why you need the rotten window management code in VM?<br></blockquote><div><br></div><div>One doesn't need it. It's there and lies unused.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lately, i seen Mars running native GUI (browser window) using Cocoa on<br>
macs and GTK on linux.<br>
(but you still have VM window hanging around, and you cannot get rid of it).<br>
<div class="im"><br>
> Going your own way creates an unnecessary fork.<br>
><br>
</div>I would love to not reinvent it, but the user input handling is one of<br>
the weakest spots in current VM implementaion.<br>
I don't like many things there:<br>
- VM is in control whether to create window or not<br>
- VM in control what attributes window has<br>
- VM in control how to translate OS (native) events to<br>
"squeak-compatible" events, often losing important bits and making<br>
everything crawl like hell<br>
- VM in control when to update/refresh a window<br>
- VM decides whether it run headless or not<br>
- VM decides when to handle input events<br>
list can be continued..<br>
<br>
Personally, i don't like that image assuming that VM has to provide a<br>
single "default" window<br>
for it. It is image, which should manage that (if it wants to), but not VM.</blockquote><div><br></div><div>You don't. But you don't need two VMs either. The existing VM windowing code can coexist with the native GUI code. In fact one can use the old code to debug the new code, and if you're Vassili you can switch an open window from Squeak window to native window and back :) </div>
</div>-- <br>best,<div>Eliot</div><br>