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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [mailto:[hidden email]] 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
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 <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sensor class = InputEventSensor true


On Jan 13, 2010, at 5:08 PM, Chris Muller wrote:

> Sensor class = InputEventSensor


_______________________________________________
Pharo-project mailing list
[hidden email]
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

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [mailto:[hidden email]] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Wednesday, January 13, 2010 6:38 PM
To: [hidden email]
Cc: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project