[Pharo-project] new mac menu code :)
Begin forwarded message:
From: John M McIntosh <johnmci@smalltalkconsulting.com> Date: January 25, 2010 7:18:45 PM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2 Reply-To: johnmci@smalltalkconsulting.com
File in Michael's change first, then mine
On 2010-01-25, at 1:13 AM, Stéphane Ducasse wrote:
Ok, I had spend a couple of hours with Michael Rueger on the mac menu bug. But I'm not sure if he got around to sending out any changes before he took some time off.
If someone can test this I can offer up some change sets for review. I've never been able to recreate this here so someone else has to try.
please send. We removed the mac menu for 1.0 but we would like to have it in 1.1
Stef
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
I already noticed John, but they didn't work for me :( 2010/1/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
Begin forwarded message:
From: John M McIntosh <johnmci@smalltalkconsulting.com> Date: January 25, 2010 7:18:45 PM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2 Reply-To: johnmci@smalltalkconsulting.com
File in Michael's change first, then mine
On 2010-01-25, at 1:13 AM, Stéphane Ducasse wrote:
Ok, I had spend a couple of hours with Michael Rueger on the mac menu
bug. But I'm not sure if he
got around to sending out any changes before he took some time off.
If someone can test this I can offer up some change sets for review. I've never been able to recreate this here so someone else has to try.
please send. We removed the mac menu for 1.0 but we would like to have it in 1.1
Stef
--
===========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email. The problem is related to what InputEventSensor>>processEvent: does. Normally the expectation is that this method takes the existing event and does some type of post processing. to set state or twiddle the event data, then return the modified event. However the EventTypeMenu is different and doesn't follow expectations. Instead generates three synthetic keyboard events which are pushed to the queue and returns nil. Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of synthetic keystrokes. The fix is to alter peekEvent so that we ignore for EventTypeMenu peekEvent "Look ahead at the next event." | nextEvent | nextEvent := eventQueue peek. ^((nextEvent isNil not) and: [(nextEvent at: 1) ~= EventTypeMenu]) ifTrue: [self processEvent: nextEvent] As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years. On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Great! I updated http://code.google.com/p/pharo/issues/detail?id=1323 Adrian On Jan 26, 2010, at 00:26 , John M McIntosh wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email.
The problem is related to what InputEventSensor>>processEvent: does.
Normally the expectation is that this method takes the existing event and does some type of post processing. to set state or twiddle the event data, then return the modified event.
However the EventTypeMenu is different and doesn't follow expectations. Instead generates three synthetic keyboard events which are pushed to the queue and returns nil.
Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of synthetic keystrokes.
The fix is to alter peekEvent so that we ignore for EventTypeMenu
peekEvent "Look ahead at the next event." | nextEvent | nextEvent := eventQueue peek. ^((nextEvent isNil not) and: [(nextEvent at: 1) ~= EventTypeMenu]) ifTrue: [self processEvent: nextEvent]
As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Jan 26, 2010 at 12:26 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email.
wiiiiiiiiiiiiiiii !!!! At the end you made it!!! It worked :):):):):):):):):):):):):):):):):):):):):):):):):):) I also sent you in private what you ask me.
As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
So...we need to integrate those two changes (michael one first, then your) and finally this changeset in peeckEvent ? Can me integrate this in 1.0 or only 1.1 ?
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think really it should go only into 1.1 if you mean the core. We do a quicker 1.1 cycle and get it released and stable. Perhaps it could be loadable as a package on top of the core anyway? Cheers mike On Tuesday, January 26, 2010, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Jan 26, 2010 at 12:26 AM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email.
wiiiiiiiiiiiiiiii !!!! At the end you made it!!! It worked :):):):):):):):):):):):):):):):):):):):):):):):):):)
I also sent you in private what you ask me.
As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
So...we need to integrate those two changes (michael one first, then your) and finally this changeset in peeckEvent ?
Can me integrate this in 1.0 or only 1.1Â ?
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Â Twitter: Â squeaker68882 Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think we should apply the patch to 1.0, but not add the host menu support again. Like this, if somebody really wants to use the menus, he can load them into 1.0. And I very much like the idea of making the host menu package *not* being part of the core but load it into the Pharo image! We just need a Metacello configuration and we load it into the dev image. Cheers, Adrian On Jan 26, 2010, at 09:30 , Michael Roberts wrote:
I think really it should go only into 1.1 if you mean the core. We do a quicker 1.1 cycle and get it released and stable. Perhaps it could be loadable as a package on top of the core anyway?
Cheers mike
On Tuesday, January 26, 2010, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Jan 26, 2010 at 12:26 AM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email.
wiiiiiiiiiiiiiiii !!!! At the end you made it!!! It worked :):):):):):):):):):):):):):):):):):):):):):):):):):)
I also sent you in private what you ask me.
As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
So...we need to integrate those two changes (michael one first, then your) and finally this changeset in peeckEvent ?
Can me integrate this in 1.0 or only 1.1 ?
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
And I very much like the idea of making the host menu package *not* being part of the core but load it into the Pharo image! We just need a Metacello configuration and we load it into the dev image.
+10 Lukas
Cheers, Adrian
On Jan 26, 2010, at 09:30 , Michael Roberts wrote:
I think really it should go only into 1.1 if you mean the core. We do a quicker 1.1 cycle and get it released and stable. Perhaps it could be loadable as a package on top of the core anyway?
Cheers mike
On Tuesday, January 26, 2010, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Jan 26, 2010 at 12:26 AM, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email.
wiiiiiiiiiiiiiiii !!!! Â At the end you made it!!! Â It worked :):):):):):):):):):):):):):):):):):):):):):):):):):)
I also sent you in private what you ask me.
As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
So...we need to integrate those two changes (michael one first, then your) and finally this changeset in peeckEvent ?
Can me integrate this in 1.0 or only 1.1 Â ?
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Â Twitter: Â squeaker68882 Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
On Tue, Jan 26, 2010 at 9:43 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
I think we should apply the patch to 1.0, but not add the host menu support again. Like this, if somebody really wants to use the menus, he can load them into 1.0.
And I very much like the idea of making the host menu package *not* being part of the core but load it into the Pharo image! We just need a Metacello configuration and we load it into the dev image.
+1 Not only because it is only mac, but also because it is not something REALLY needed in a core. I always imagine core like a runtime you use to deploy, and that may not be needed. So... +1 to have a core as smaller as possible. I opened the issue with milestone 1.1 http://code.google.com/p/pharo/issues/detail?id=1879
Cheers, Adrian
On Jan 26, 2010, at 09:30 , Michael Roberts wrote:
I think really it should go only into 1.1 if you mean the core. We do a quicker 1.1 cycle and get it released and stable. Perhaps it could be loadable as a package on top of the core anyway?
Cheers mike
On Tuesday, January 26, 2010, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Jan 26, 2010 at 12:26 AM, John M McIntosh <
johnmci@smalltalkconsulting.com> wrote:
Ok, I figured it out, well I think I did.. Mariano is confirming... But
I'll post the expected fix in this email.
wiiiiiiiiiiiiiiii !!!! At the end you made it!!! It worked
:):):):):):):):):):):):):):):):):):):):):):):):):):)
I also sent you in private what you ask me.
As for the changes earlier posted, we should run with those. Michael
altered them to make the logic cleaner, and
I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years.
So...we need to integrate those two changes (michael one first, then your) and finally this changeset in peeckEvent ?
Can me integrate this in 1.0 or only 1.1 ?
On 2010-01-25, at 12:14 PM, Stéphane Ducasse wrote:
File in Michael's change first, then mine
--
===========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 1/26/2010 12:26 AM, John M McIntosh wrote:
Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of synthetic keystrokes.
Good one! I would have never thought about that possibility... Thanks :-) Michael
mindsharing is a plus :) On Jan 26, 2010, at 9:13 PM, Michael Rueger wrote:
On 1/26/2010 12:26 AM, John M McIntosh wrote:
Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of synthetic keystrokes.
Good one!
I would have never thought about that possibility...
Thanks :-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Adrian Lienhard -
John M McIntosh -
Lukas Renggli -
Mariano Martinez Peck -
Michael Roberts -
Michael Rueger -
Stéphane Ducasse