- Pharo-dev - lists.pharo.org

Re: [Pharo-project] New sensor code

by Michael Rueger

Igor Stasenko wrote: > A next stage, would be to refactor MorphicEvent & subclasses > and move them into category Kernel-Events > and then change EventSensor to convert raw events into nice XXXEvent > instances, so the rest of image wouldn't have to deal with raw event > buffers anymore. Yes, although a thought would be to add a separate API on the new sensor for fetching the "real" events and migrate the system over step by step. And for those events we might want to use the new event hierarchy from Miro and ySqueak, they turned out to be almost identical :-) Michael

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

I read it correctly :) Stef On Nov 22, 2008, at 7:46 PM, Michael Rueger wrote: > Michael Rueger wrote: > >> So one of the next things I will try to do is get Miro loaded into >> Morphic and also my ySqueak (formerly iSqueak) framework. But the >> latter > > into Pharo of course > > Need...more...caffeine.... > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

Indeed > >>>> I was wondering what kind of patterns the code to change was >>>> looking like. > > The big question is whether we really want to clean up Morphic as it > is or start putting in a new UI framework. The new input event > architecture allows us to plug in in other UI and event systems > without the need to touch Morphic. > So one of the next things I will try to do is get Miro loaded into > Morphic and also my ySqueak (formerly iSqueak) framework. But the > latter relies on a lot more system changes than Miro IIRC, so it > might take some time. Ok I know that alain was looking for a layout engine. Stef

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

2008/11/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> StÃ©phane Ducasse wrote: >>> >>> so how do we proceed? >>> We try to load it, play with it then? >>> integrate it into pharo and you continue hacking and fixing? >> >> this version is really meant to be smoke tested, it needs some work on the >> comments and on the user interrupt handling. > > Ok I will test it >> >> >> So please load it into your images, make sure you always have backups and >> see how it holds up. If it turns out to be reasonably stable we can push it. >> >> >>> 1- Here I have a question >>> =================== >>> in this comment EventSensor = InputEventSensor? >> >> the comment is only a copy from EventSensor, needs to be rewritten. >> If somebody has a better suggestion for naming this class I'm open to >> suggestions. >> >>> 2- I saw a method defined on Controller >>> But there are no reference to this class in pharo. So we could remove >>> Controller I imagine >> >> It is superclass of other classes, so I'm not sure. > > I will check. > >> >> >>> 3- could you tell me >>> what kind of code we would have to change? >> >> Not sure what you mean? For now no code in the image needs to be changed. > > I was already thinking about the next steps. > I was wondering what kind of patterns the code to change was looking like. > A next stage, would be to refactor MorphicEvent & subclasses and move them into category Kernel-Events and then change EventSensor to convert raw events into nice XXXEvent instances, so the rest of image wouldn't have to deal with raw event buffers anymore. >> >> >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

2008/11/22 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> >> Here the further changes to fix above. > > Thanks, nice refactoring! > > There is no need though to keep the delay in a class variable, the instance > variable would be just fine. Well, its on class side because if you type: InputEventFetcher default eventPollPeriod: xx may not work, depending on what type of event fetcher currently working. While InputEventPollingFetcher eventPollPeriod: xx will work always. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Michael Rueger

Michael Rueger wrote: > So one of the next things I will try to do is get Miro loaded into > Morphic and also my ySqueak (formerly iSqueak) framework. But the latter into Pharo of course Need...more...caffeine.... Michael

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Michael Rueger

Igor Stasenko wrote: > Here the further changes to fix above. Thanks, nice refactoring! There is no need though to keep the delay in a class variable, the instance variable would be just fine. Michael

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Michael Rueger

StÃ©phane Ducasse wrote: >>> 3- could you tell me >>> what kind of code we would have to change? >> >> Not sure what you mean? For now no code in the image needs to be changed. > > I was already thinking about the next steps. > I was wondering what kind of patterns the code to change was looking like. The big question is whether we really want to clean up Morphic as it is or start putting in a new UI framework. The new input event architecture allows us to plug in in other UI and event systems without the need to touch Morphic. So one of the next things I will try to do is get Miro loaded into Morphic and also my ySqueak (formerly iSqueak) framework. But the latter relies on a lot more system changes than Miro IIRC, so it might take some time. Michael

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

Here the further changes to fix above. 2008/11/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Nov 22, 2008, at 7:13 PM, Igor Stasenko wrote: > >> I just loaded your changeset and have something to report :) >> >> It looks like it having bigger poll periods than old sensor, or works >> slower. >> An overall performance feels a bit more sluggish comparing to old >> implementation. >> Just open a window with long text and hold down the up/down key and >> see the difference. >> Or try to resize browser window - you can notice its not so smooth as >> in old image. > > I got the same feeling but I have the impression that it was less important > than > what igor reported. But I had the impression that everything was a bit > slower > >> >> >> 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >>> >>> StÃ©phane Ducasse wrote: >>>> >>>> so how do we proceed? >>>> We try to load it, play with it then? >>>> integrate it into pharo and you continue hacking and fixing? >>> >>> this version is really meant to be smoke tested, it needs some work on >>> the >>> comments and on the user interrupt handling. >>> >>> So please load it into your images, make sure you always have backups and >>> see how it holds up. If it turns out to be reasonably stable we can push >>> it. >>> >>> >>>> 1- Here I have a question >>>> =================== >>>> in this comment EventSensor = InputEventSensor? >>> >>> the comment is only a copy from EventSensor, needs to be rewritten. >>> If somebody has a better suggestion for naming this class I'm open to >>> suggestions. >>> >>>> 2- I saw a method defined on Controller >>>> But there are no reference to this class in pharo. So we could remove >>>> Controller I imagine >>> >>> It is superclass of other classes, so I'm not sure. >>> >>>> 3- could you tell me >>>> what kind of code we would have to change? >>> >>> Not sure what you mean? For now no code in the image needs to be changed. >>> >>> >>> Michael >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :) 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: > 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >> I just loaded your changeset and have something to report :) >> >> It looks like it having bigger poll periods than old sensor, or works slower. >> An overall performance feels a bit more sluggish comparing to old >> implementation. >> Just open a window with long text and hold down the up/down key and >> see the difference. >> Or try to resize browser window - you can notice its not so smooth as >> in old image. >> > > ... which can be fixed easily by reducing poll period from 100ms to 10ms in > InputEventPollingFetcher>>eventLoop > >> 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >>> StÃ©phane Ducasse wrote: >>>> >>>> so how do we proceed? >>>> We try to load it, play with it then? >>>> integrate it into pharo and you continue hacking and fixing? >>> >>> this version is really meant to be smoke tested, it needs some work on the >>> comments and on the user interrupt handling. >>> >>> So please load it into your images, make sure you always have backups and >>> see how it holds up. If it turns out to be reasonably stable we can push it. >>> >>> >>>> 1- Here I have a question >>>> =================== >>>> in this comment EventSensor = InputEventSensor? >>> >>> the comment is only a copy from EventSensor, needs to be rewritten. >>> If somebody has a better suggestion for naming this class I'm open to >>> suggestions. >>> >>>> 2- I saw a method defined on Controller >>>> But there are no reference to this class in pharo. So we could remove >>>> Controller I imagine >>> >>> It is superclass of other classes, so I'm not sure. >>> >>>> 3- could you tell me >>>> what kind of code we would have to change? >>> >>> Not sure what you mean? For now no code in the image needs to be changed. >>> >>> >>> Michael >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008