Igor Stasenko wrote:
>> Yeah. I just don't like the whole subsystem all that much and having more
>> InputSensor subclasses looks to me as if it may be making things worse. BTW,
>> where is that code?
> 
> AFAIK, it wasn't published anywhere, try searching Pharo list
> archives, it should be in attachments.

Can you put this up on Mantis? File an issue, set it to fixed in "3.11" 
and the status to "testing". If I understand the mechanism correctly 
this should allow us to pick this up automatically for 3.11.

Cheers,
   - Andreas

> The refactoring was targeted to support multiple event handlers
> instead of just single Sensor.
> Currently i developing a new model, based on this but a little different.
> - initially there will be a single event polling loop running,
> governed by a EventListener class.
> - an EventListener installs the polling loop and fetching events from VM
> - once received, event buffer is converted to an instance of
> corresponding KernelXXXEvent and then passed to event handler (kept as
> inst var).
> 
> The EventListener is intentionally made as simple as possible, to
> minimise the probability of changing it unless something changed in
> VM. Its name speaks for itself, it listens for events from some
> source, and in our case source is VM.
> 
> You are free to set a listener handle to anything you like, just make
> sure it responds to #handleEvent: message.
> 
> Now, the most fun begins with implementation of handler.
> First, i want to implement a handler, which will behave similarily to
> what current Sensor does.
> Next, when multiple host windows machinery will be ready, i will
> replace it with dispatching handler, which will dispatch events based
> on window id.
> So, instead of chain:
> VM -> listener -> Sensor -> hand
> we will have something like:
> VM -> listener -> window -> Sensor -> hand
> 
> of course, such replacement is not possible until we will get rid of
> Display/World/Sensor globals in most critical places to make at least
> most functionality work for multiple host windows.
> 
>>>>> Now, if you will fix signaling the input semaphore, we need some way
>>>>> to determine what method of event polling is most appropriate -  to
>>>>> install a best event polling mechanism.
>>>>> Any ideas how this can be determined by image side?
>>>> Easy. Run the poller until the first event comes in. Check whether the
>>>> semaphore is signaled. Switch to non-polling if so. Alternatively, use
>>>> #waitTimeoutMSecs: - it means you're still occasionally polling but that
>>>> is
>>>> probably acceptable.
>>>>
>>> Sure it is easy. I'm just feel uncomfortable when we need to introduce
>>> more complex logic in places where its not necessary.
>>> That's why i made two subclasses by factoring out #waitForInput logic
>>> to avoid putting too much if's into a single method.
>>> Again, when in future we will no longer need to care about backward
>>> compatibility, you'll need a minimal change - simply stop using the
>>> subclass instead of analyzing the complex code to remove obsolete
>>> cruft.
>> Yes. Although it seems that you don't get to avoid whatever complexity is
>> required to decided which version to use. This is partly why I'm thinking it
>> may actually be simpler to have this in the same place, along the lines of:
>>
>> processEvents
>>  self waitForInputPolling.
>>  haveSema := inputSemaphore isSignaled.
>>  [true] whileTrue:[
>>    haveSema
>>        ifTrue:[inputSemaphore wait]
>>        ifFalse:[self waitForInputPolling].
>>    self processNextEvent.
>>  ].
>>
>> Really not much complexity here.
> 
> I agree.. you convinced me to put everything into a single method :)
> lets stop wasting our breath on this subtle detail :)
> 
> 
>>>>> And any other value returned should mean, that image should keep using
>>>>> old manual event polling mechanism and do not rely on input semaphore.
>>>> How much backwards compatibility do you need? Wouldn't it be easier to
>>>> fix
>>>> it and then switch?
>>>>
>>> I want it to be backward compatible, but i prefer a clear ways to
>>> determine VM's behavior instead of impirically guessing it (as with
>>> checking if semaphore is signaled).
>> What could be clearer than actually checking? ;-) Seriously, I find this the
>> most straightforward way to figure out whether we can rely on the VM to
>> signal the semaphore or not if you really want to be have that level of
>> backwards compatibility. Alternatively, just require VMs that signal the
>> damn semaphore! ;-)
>>
>> Cheers,
>>  - Andreas
>>
>>
> 
> 
>