Hi all, i started to look at the Sensor stuff. I have two questions : - there is two classes : EventSensor and InputSensor. The first one seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ? - there is an EventSensorConstants shared pool with several constants used only by the EventSensor class. Is this class realy needed or we could move the constants as class variables in the EventSensor class ?
What are your opinions about this ?
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first one
seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Merging the two into one class would really lead to more obscure behavior. It actually *is* well factored ;-)
- there is an EventSensorConstants shared pool with several
constants used only by the EventSensor class. Is this class realy needed or we could move the constants as class variables in the EventSensor class ?
Why do you think they are unused? In my image I see these users:
EventSensorConstants "is a global variable. It is a pool which is used by the following classes (CHandPlayer CHandCostume EventSensor CUnknownEvent UserInputEvent KeyboardInputInterpreter TextConverter MorphicUnknownEvent CUserInputEvent HandMorph)"
- Bert -
On 13-Nov-05, at 2:30 PM, Bert Freudenberg wrote:
Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first
one seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Sadly this isn't how it works any longer. If you look deep into the code (which of course allows the code to look deep into you) you will see that the 'old' input sensor code cannot get to run. Once upon a time entering an MVC project would awaken a simple InputSensor for example. I did make some suggestions for a cleaner input handler a while ago but no one seemed to care enough to even want to discuss it. There's a related email at http://lists.squeakfoundation.org/ pipermail/squeak-dev/2004-February/073583.html
There isn't really anything simpler about the old polling prims than the newer sort-of event prims so we don't really have any good reason to keep them. I was planning on cutting them out sometime soon along with lots of other extraneous junk.
tim
In the current revision the EventSensor stuff is not event driven, well not that it was even, although I had an old change set that attempted that since on the mac, with the carbon VM, events are async and the event semaphore is used, however that was obsoleted by changes last year.
Rather Morphic as part of it's 1/50 of a second processing looks for any events on the event queue, if not found it asks the VM for events off the VM event queue. If EventSensor sees the event semaphore was fired then it notes the VM could be event semaphore driven. EventSensor also has a tickler poll of 1/2 a second that pulls any pending events from the VM event queue so that cmd-'.' processing can occur if Morphic looses it's mind, so it's more of Morphic driving things, versus the EventSensor logic driving things.
The interesting thing is how events coming, get mucked with, then passed into Morphic which does lots of work with them and I suspect results in 90% of the cycles devoted to decoding what should happen, that process is much more interesting to follow for optimization issues.
On 13-Nov-05, at 9:09 PM, tim Rowledge wrote:
On 13-Nov-05, at 2:30 PM, Bert Freudenberg wrote:
Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first
one seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Sadly this isn't how it works any longer. If you look deep into the code (which of course allows the code to look deep into you) you will see that the 'old' input sensor code cannot get to run. Once upon a time entering an MVC project would awaken a simple InputSensor for example. I did make some suggestions for a cleaner input handler a while ago but no one seemed to care enough to even want to discuss it. There's a related email at http:// lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/ 073583.html
There isn't really anything simpler about the old polling prims than the newer sort-of event prims so we don't really have any good reason to keep them. I was planning on cutting them out sometime soon along with lots of other extraneous junk.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi guys
I remember that john talked to me about that at ESUG in 2004 :). It would be good if you would propose something and that we cut and clean the situation (even stepwise). But I'm not sure that this is possible with morphic.
Stef
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first
one seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Sadly this isn't how it works any longer. If you look deep into the code (which of course allows the code to look deep into you) you will see that the 'old' input sensor code cannot get to run. Once upon a time entering an MVC project would awaken a simple InputSensor for example. I did make some suggestions for a cleaner input handler a while ago but no one seemed to care enough to even want to discuss it. There's a related email at http:// lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/ 073583.html
There isn't really anything simpler about the old polling prims than the newer sort-of event prims so we don't really have any good reason to keep them. I was planning on cutting them out sometime soon along with lots of other extraneous junk.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows. How keystrokes are recognized is different between Morphic and Tweak. How mouse move/double click/click/up/down event could be different between mac/windows (witness crusty code in morphic to *fix* mac mouse events) Certain how dead keys and multiple keystroke characters result in key up/down keychar events would be interesting to understand between platforms. Where and what is the Mac Roman key code, the virtual keycode, and the unicode keycode come from and when?
On 14-Nov-05, at 12:43 AM, stéphane ducasse wrote:
Hi guys
I remember that john talked to me about that at ESUG in 2004 :). It would be good if you would propose something and that we cut and clean the situation (even stepwise). But I'm not sure that this is possible with morphic.
Stef
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first
one seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Sadly this isn't how it works any longer. If you look deep into the code (which of course allows the code to look deep into you) you will see that the 'old' input sensor code cannot get to run. Once upon a time entering an MVC project would awaken a simple InputSensor for example. I did make some suggestions for a cleaner input handler a while ago but no one seemed to care enough to even want to discuss it. There's a related email at http:// lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/ 073583.html
There isn't really anything simpler about the old polling prims than the newer sort-of event prims so we don't really have any good reason to keep them. I was planning on cutting them out sometime soon along with lots of other extraneous junk.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh wrote:
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows.
As of which VM version? Could you describe this, please?
Thanks, Josh
3.8.7b2 sqUIEvents.c changed keyUp/keyDown to supply mac virtual keycode versus unicode, added new parm to keyChar to supply UTF-32 Unicode. As per Andreas request for Tweak.
On 3-Dec-05, at 8:33 AM, Joshua Gargus wrote:
John M McIntosh wrote:
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows.
As of which VM version? Could you describe this, please?
Thanks, Josh
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
3.8.7b2 sqUIEvents.c changed keyUp/keyDown to supply mac virtual keycode versus unicode, added new parm to keyChar to supply UTF-32 Unicode. As per Andreas request for Tweak.
On 3-Dec-05, at 8:33 AM, Joshua Gargus wrote:
John M McIntosh wrote:
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows.
As of which VM version? Could you describe this, please?
Thanks, Josh
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
3.8.7b2 sqUIEvents.c changed keyUp/keyDown to supply mac virtual keycode versus unicode, added new parm to keyChar to supply UTF-32 Unicode. As per Andreas request for Tweak.
On 3-Dec-05, at 8:33 AM, Joshua Gargus wrote:
John M McIntosh wrote:
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows.
As of which VM version? Could you describe this, please?
Thanks, Josh
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Oops I should mention this is the carbon VM, the unix VM has different results.
On 3-Dec-05, at 8:33 AM, Joshua Gargus wrote:
John M McIntosh wrote:
One of the other fun things in here would be to nail down the UI behavior between platforms. The UI premise for key up/down/repeat has lately change on the mac to more closely match Windows.
As of which VM version? Could you describe this, please?
Thanks, Josh
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
tim Rowledge a écrit :
On 13-Nov-05, at 2:30 PM, Bert Freudenberg wrote:
Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
Hi all, i started to look at the Sensor stuff. I have two questions :
- there is two classes : EventSensor and InputSensor. The first one
seems to be a replacement of the last one. Do we really need two classes or could we try to merge both ?
IMHO there's nothing wrong with having both classes. In a minimal image / VM the old polling InputSensor should actually still work. Which is good for getting new ports started. If the VM implements the event primitives, the EventSensor will take over.
Sadly this isn't how it works any longer. If you look deep into the code (which of course allows the code to look deep into you) you will see that the 'old' input sensor code cannot get to run. Once upon a time entering an MVC project would awaken a simple InputSensor for example. I did make some suggestions for a cleaner input handler a while ago but no one seemed to care enough to even want to discuss it. There's a related email at http://lists.squeakfoundation.org/ pipermail/squeak-dev/2004-February/073583.html
There isn't really anything simpler about the old polling prims than the newer sort-of event prims so we don't really have any good reason to keep them. I was planning on cutting them out sometime soon along with lots of other extraneous junk.
Ok, i stop looking at it at the moment if you plan to do refactorings here.
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
John M McIntosh -
Joshua Gargus -
Serge Stinckwich -
stéphane ducasse -
tim Rowledge