To solve trac #3062, Ian added VM support for a close window event. Now we need image code for this.
The original support code is here:
ftp://smalltalkconsulting.com/experimental/Ffenestri/Ffenestri-b-4- Events-Morphic.1.cs
it basically adds a windowIndex field to each MorphicEvent plus a new event class (WindowEvent). The window index would be used to distinguish mouse events in different windows (so it is constant for us, we only have one OS window). The new WindowEvent would be what we are interested in, as we get this when the etoys activity is closed.
Does anybody see a downside to including that changeset verbatim? I haven't compared it to the current code in the image in detail yet. It does a bit more than we need right now, sow we could strip it down, OTOH, I suspect this will land in the the squeak.org version sooner or later so having it should not be bad.
Opinions?
- Bert -
Bert,
To solve trac #3062, Ian added VM support for a close window event. Now we need image code for this.
The original support code is here:
ftp://smalltalkconsulting.com/experimental/Ffenestri/Ffenestri-b-4- Events-Morphic.1.cs
it basically adds a windowIndex field to each MorphicEvent plus a new event class (WindowEvent). The window index would be used to distinguish mouse events in different windows (so it is constant for us, we only have one OS window). The new WindowEvent would be what we are interested in, as we get this when the etoys activity is closed.
Does anybody see a downside to including that changeset verbatim? I haven't compared it to the current code in the image in detail yet. It does a bit more than we need right now, sow we could strip it down, OTOH, I suspect this will land in the the squeak.org version sooner or later so having it should not be bad.
When Etoys is in the background (not in the foreground) and receives the event, (any of) Etoys screen or dialog from Etoys wouldn't appear on screen but Etoys would silently save the current project, right? In this line of thought, the need for distinguishing two windows does sound overkill.
The other stuff is that the implication of -lazy and this one. Of course, even if we use -lazy option for the VM, the VM can just "wake up" the image when the VM receives some urgent event like this,..
-- Yoshiki
Hi Bert,
I think it is not bad that we include multiple screen support now if we will need it sometime. But this change set doesn't work in etoys image. Maybe more support codes are needed. Try Alt (Command) + ..
Cheers, - Takashi
The original support code is here:
ftp://smalltalkconsulting.com/experimental/Ffenestri/Ffenestri-b-4-Events-Morphic.1.cs
Does anybody see a downside to including that changeset verbatim? I haven't compared it to the current code in the image in detail yet. It does a bit more than we need right now, sow we could strip it down, OTOH, I suspect this will land in the the squeak.org version sooner or later so having it should not be bad.
When Etoys is in the background (not in the foreground) and receives the event, (any of) Etoys screen or dialog from Etoys wouldn't appear on screen but Etoys would silently save the current project, right? In this line of thought, the need for distinguishing two windows does sound overkill.
The other stuff is that the implication of -lazy and this one. Of course, even if we use -lazy option for the VM, the VM can just "wake up" the image when the VM receives some urgent event like this,..
Thanks ... I think I'll trim the change set down to include only what we need for now. We still can push the whole lot later if needed.
- Bert -
On Aug 30, 2007, at 10:24 , Takashi Yamamiya wrote:
Hi Bert,
I think it is not bad that we include multiple screen support now if we will need it sometime. But this change set doesn't work in etoys image. Maybe more support codes are needed. Try Alt (Command) + ..
Cheers,
- Takashi
The original support code is here:
ftp://smalltalkconsulting.com/experimental/Ffenestri/Ffenestri- b-4-Events-Morphic.1.cs
Does anybody see a downside to including that changeset verbatim? I haven't compared it to the current code in the image in detail yet. It does a bit more than we need right now, sow we could strip it down, OTOH, I suspect this will land in the the squeak.org version sooner or later so having it should not be bad.
When Etoys is in the background (not in the foreground) and receives the event, (any of) Etoys screen or dialog from Etoys wouldn't appear on screen but Etoys would silently save the current project, right? In this line of thought, the need for distinguishing two windows does sound overkill.
The other stuff is that the implication of -lazy and this one. Of course, even if we use -lazy option for the VM, the VM can just "wake up" the image when the VM receives some urgent event like this,..
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Takashi Yamamiya -
Yoshiki Ohshima