[Pharo-project] EventSensor vs EventInputSensor
I have a question about EventSensor. In Pharo doesn't exists anymore, it was replaced by InputEventSensor that has this class comment: An InputEventSensor is a replacement for the old Morphic EventSensor framework. It updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before. The usage of these funtions is discouraged. I am installing Magma on a Pharo core image and Magma uses EventSensor, by adding some methods to this class. As the class doesn't exist it shows the following message: This package depends on the following classes: EventSensor You must resolve these dependencies before you will be able to load these definitions: EventSensor classSide>>maMaterializeFromGraph:using: EventSensor>>maAsStorageObject EventSensor>>maUsesStandardStorage Select Proceed to continue, or close this window to cancel the operation. If before loading Magma I do Smalltalk at: #EventSensor put: InputEventSensor. Then everything works without warnings. Also the InputEventSensor receives the methods added by Magma. My questions are: Is this valid? Must this (the InputEventSensor in the slot of EventSensor in Smalltalk) be part of the image or will be a regresion to the situation before the deletion of EventSensor? What will be the correct way to handle this, change the Pharo/PharoCore with my hack or to ask Chris Muller, the maintainer of Magma to not use EventSensor but InputEvenSensor in the case of Pharo/PharoCore? Can I be reminded of the reasons to drop EventSensor in favor of InputEvenSensor? Thanks for the answers -- Miguel Cobá http://miguel.leugim.com.mx
I did essentially what you propose early on to get things to shut up as I filed in a lot of my code from Dolphin, and I suffered for it later. What I wish I had done was add classes as subclasses of things already in the image. Of course, if you add EventSensor under InputEventSensor, you will likely find that the system will go right on using InputEventSensor, with the methods added to the (non-instantiated) subclass. I ran into weird behavior that I never fully understood, but undoing my system dictionary games got me out of it. The changes I made ended up being bootstrapping tricks that are better done by using regular expressions and match/replace to edit the SIF files. Back up first, and give it a shot. Good luck! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez Sent: Tuesday, January 12, 2010 7:25 PM To: Pharo Subject: [Pharo-project] EventSensor vs EventInputSensor I have a question about EventSensor. In Pharo doesn't exists anymore, it was replaced by InputEventSensor that has this class comment: An InputEventSensor is a replacement for the old Morphic EventSensor framework. It updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before. The usage of these funtions is discouraged. I am installing Magma on a Pharo core image and Magma uses EventSensor, by adding some methods to this class. As the class doesn't exist it shows the following message: This package depends on the following classes: EventSensor You must resolve these dependencies before you will be able to load these definitions: EventSensor classSide>>maMaterializeFromGraph:using: EventSensor>>maAsStorageObject EventSensor>>maUsesStandardStorage Select Proceed to continue, or close this window to cancel the operation. If before loading Magma I do Smalltalk at: #EventSensor put: InputEventSensor. Then everything works without warnings. Also the InputEventSensor receives the methods added by Magma. My questions are: Is this valid? Must this (the InputEventSensor in the slot of EventSensor in Smalltalk) be part of the image or will be a regresion to the situation before the deletion of EventSensor? What will be the correct way to handle this, change the Pharo/PharoCore with my hack or to ask Chris Muller, the maintainer of Magma to not use EventSensor but InputEvenSensor in the case of Pharo/PharoCore? Can I be reminded of the reasons to drop EventSensor in favor of InputEvenSensor? Thanks for the answers -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Great idea Miguel. I believe this will not only work just fine, but will allow models in Pharo which reference the "Sensor" (something I doubt has ever happened, or ever will) to persist and materialize properly. *Provided*, that, in Pharo: Sensor class = InputEventSensor answers "true", which I'm assuming it does (can't launch a Pharo image at the moment to be sure). - Chris 2010/1/12 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>:
I have a question about EventSensor.
In Pharo doesn't exists anymore, it was replaced by InputEventSensor that has this class comment:
An InputEventSensor is a replacement for the old Morphic EventSensor framework. It updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before. The usage of these funtions is discouraged.
I am installing Magma on a Pharo core image and Magma uses EventSensor, by adding some methods to this class. As the class doesn't exist it shows the following message:
This package depends on the following classes:  EventSensor You must resolve these dependencies before you will be able to load these definitions:  EventSensor classSide>>maMaterializeFromGraph:using:  EventSensor>>maAsStorageObject  EventSensor>>maUsesStandardStorage
Select Proceed to continue, or close this window to cancel the operation.
If before loading Magma I do
Smalltalk at: #EventSensor put: InputEventSensor.
Then everything works without warnings. Also the InputEventSensor receives the methods added by Magma.
My questions are:
Is this valid? Must this (the InputEventSensor in the slot of EventSensor in Smalltalk) be part of the image or will be a regresion to the situation before the deletion of EventSensor? What will be the correct way to handle this, change the Pharo/PharoCore with my hack or to ask Chris Muller, the maintainer of Magma to not use EventSensor but InputEvenSensor in the case of Pharo/PharoCore?
Can I be reminded of the reasons to drop EventSensor in favor of InputEvenSensor?
Thanks for the answers -- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mié, 13-01-2010 a las 17:15 +0100, Fernando olivero escribió:
Sensor class = InputEventSensor true
Now, it only remains to know if this should be a permanent change in the Pharo image or just a preloadDoit of the metacello configuration of Magma. Stef? What do you think? Cheers
On Jan 13, 2010, at 5:08 PM, Chris Muller wrote:
Sensor class = InputEventSensor
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
I do not know what I know is that we should support the new event architecture and deprecate the polling one On Jan 13, 2010, at 5:23 PM, Miguel Enrique Cobá Martinez wrote:
El mié, 13-01-2010 a las 17:15 +0100, Fernando olivero escribió:
Sensor class = InputEventSensor true
Now, it only remains to know if this should be a permanent change in the Pharo image or just a preloadDoit of the metacello configuration of Magma.
Stef? What do you think?
Cheers
On Jan 13, 2010, at 5:08 PM, Chris Muller wrote:
Sensor class = InputEventSensor
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mié, 13-01-2010 a las 22:27 +0100, Stéphane Ducasse escribió:
I do not know what I know is that we should support the new event architecture and deprecate the polling one
Well, I'm doing it as a preload doit in the metacello configuration. The problem is that goes unnoticed by the user. And maybe later could give surprises. Can someone giver their opinion about this? By having it in PharoCore is visible in the change log of Pharo. But what could someday be wrong with having it in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx
Stef, Polling for events is baaaaad. However, is the new mechanism tainted by poor support for weak collections? If so, it might be better to poll until we get the latter right and can get away from #release as a requirement. Unregistering interest in events should always be possible; it should not be required. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez Sent: Wednesday, January 13, 2010 6:38 PM To: Pharo-project@lists.gforge.inria.fr Cc: ma.chris.m@gmail.com Subject: Re: [Pharo-project] EventSensor vs EventInputSensor El mié, 13-01-2010 a las 22:27 +0100, Stéphane Ducasse escribió:
I do not know what I know is that we should support the new event architecture and deprecate the polling one
Well, I'm doing it as a preload doit in the metacello configuration. The problem is that goes unnoticed by the user. And maybe later could give surprises. Can someone giver their opinion about this? By having it in PharoCore is visible in the change log of Pharo. But what could someday be wrong with having it in Pharo? -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Chris Muller -
Fernando olivero -
Miguel Enrique Cobá Martinez -
Schwab,Wilhelm K -
Stéphane Ducasse