Removing the old pre-event-driven input polling input primitives

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing the old pre-event-driven input polling input primitives

Eliot Miranda-2
Hi all,

    I'm just checking.  It seems to me that primitives 90, 107, & 108, oldPrimMousePt, oldPrimMouseButtons, & oldPrimKbdNext, have been obsolete for a very long time.  Am I correct? Is there any possibility these could be relevant to a Cog VM, that is any image from 4.0 on?  WOuld removing the support for these primitives form the VM potentially impact porting old Etoys projects?  Any other potential impacts?

I'd like to nuke the code to ease extending the VM to support modern mice, which have many more buttons available, because it makes things unnecessarily complicated.
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Removing the old pre-event-driven input polling input primitives

marcel.taeumel
Hi Eliot.

+1

Yes, I think that we do not need those primitives anymore. We re-implemented that event-peeking interface through primitive 94 so that MVC keeps on working. Since Etoys builds on top of Morphic, which is not affected at all, we should be fine. Even OLPCVirtualSensor should keep on working. Take a look at all those #peek* methods in EventSensor. Most of them are already an extension for *ST80 :-)

Go nuke those primitives. :-) Yet, we would not have any fallback code in #primGetNextEvent: anymore, which is kind of impossible anyway, right?

I can help you with adapting higher-level event code for mice with many buttons.

Best,
Marcel

Am 05.03.2021 04:01:23 schrieb Eliot Miranda <[hidden email]>:

Hi all,

    I'm just checking.  It seems to me that primitives 90, 107, & 108, oldPrimMousePt, oldPrimMouseButtons, & oldPrimKbdNext, have been obsolete for a very long time.  Am I correct? Is there any possibility these could be relevant to a Cog VM, that is any image from 4.0 on?  WOuld removing the support for these primitives form the VM potentially impact porting old Etoys projects?  Any other potential impacts?

I'd like to nuke the code to ease extending the VM to support modern mice, which have many more buttons available, because it makes things unnecessarily complicated.
_,,,^..^,,,_
best, Eliot