July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo4] Weekend Project 1: Cleanup Low-Level animation code

by stepharo

Marcus I pushed it to the git pharo-workingRoadmaps Stef On 24/7/14 11:04, stepharo wrote: > Yes marcus may be we should add that description to pharo roadmaps on > github. > I like to document design problems that I encounter but cannot fix fast. > > Stef > > On 24/7/14 10:28, Marcus Denker wrote: >> Hi, >> >> Now with holidays comingâ¦ maybe someone wants to do a small Pharo >> related Project with impact on the future? >> >> Here is suggestion 1. >> >> Context: cleanup graphics. (so e.g. one could replace the canvas later). >> >> Details >> ====== >> Morphic has some very arcane code for animating moving morphs >> around that bypasses layers. >> >> DisplayObject has these methods: >> >> follow:while: >> follow:while:bitsBehind:startingLoc: >> slideFrom:to:nSteps:delay: >> slideWithFirstFrom:to:nSteps:delay: >> displayOnPort:at:rule: >> >> They are used by morphic for some not really important animation that >> for sure >> can be directly done by moving the morphs as morphs around. Bypassing >> and directly using low level (not even Canvas level) functionality is >> for sure not needed. >> >> On the Morph level the users are: >> >> slideBackToFormerSituation: >> vanishAfterSlidingTo:event: >> animationForMoveSuccess: >> >> What to do? >> >> -> rewrite the morphic level code to just move the morphs around. >> -> delete all the code from DisplayObject >> -> review âGrafPortâ usage, as this might have been the last client. >> >> >> Marcus >> > > >

July 24, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Pavel Krivanek

2014-07-24 15:42 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > > 2014-07-24 15:01 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, >> >> >> On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> On 24/7/14 13:37, Pavel Krivanek wrote: >>> >>>> Hi, >>>> >>>> SystemWindows support >>>> ============================ >>>> SystemWindow is quite complex morph that requires many of other morph >>>> classes including text morphs, theming support etc. But in several >>>> situations the system windows play special role and the Morphic core >>>> classes need to be aware of them. So we have several options: >>>> >>>> - (current) do not have SystemWindow & co. in the image but let basic >>>> support of them. That will produce some unimplemented calls >>>> >>>> - create very simple SystemWindow superclass that will be part of the >>>> Morphic-Core but will not have look and possibilities of real SystemWindow >>>> >>>> - include SystemWindow and supporting classes >>>> >>> I had the same questions than you: >>> - I have the impression that systemWindow is really linked to >>> widgets. >>> >> >> I think we should go with option 2 and have a way of providing basic >> windows. SystemWindow is too much anyway. >> > > one problem is that SystemWindow/isSystemWindow is hardcoded on so many > places... > > >> >>> >>> Tools >>>> ============================ >>>> The current image generated by this configuraton will crash as soon as >>>> you try to press some keyboard button. The reason is in the method >>>> Morph>>#handleKeystroke. This method contains this code to support >>>> Keymapping >>>> >>>> Smalltalk tools shortcuts handleKeystroke: anEvent inMorph: self. >>>> >>> >>> I think that keymapping should not be a tool but the default way to >>> change and control shortcuts. >>> Do you have a take on this? >> >> >> +1. Although it can still be improved, keymapping is better than any >> other option we have and we should promote it as the default mechanism. >> >> Cheers, >> Doru >> > > I checked the package dependensies of Keymappings and Keymapping-Core, > Keymapping-KeyCombinations and Keymapping-Pragmas. The only ugly dependency > is on MenuRegistration (that is dependent on several other packages). > Becuase this is only one place where the Keymappings are used in > Morphic-Core, I whould prefer to add a class variable named > ShortcutsHandler to Morph and register Keymappings here (or let it be nil > for Morphic-Core) > https://pharo.fogbugz.com/f/cases/13681/replace-Smalltalk-tools-shortcuts-w… > > -- Pavel > > >> >> >> The #tools message is part of Tool-Base package and need to be there >>>> because it uses lazy evaluation that creates a ToolRegistry instance. >>>> Because Tool-Base is not loaded in the minimal nor Morphic-Core image, it >>>> raises DNU >>>> >>>> Solutions: >>>> - introduce some safer form like Smalltalk withToolsDo: [:tools | ...]. >>>> In this case it will not be able to look if the class variable "Tools" is >>>> nil (because of lazy evaluation) but it will need to do some ugly check of >>>> presence of ToolRegistry class or something similar. In this case we will >>>> produce more unimplemented calls (on several places in the image because >>>> withToolsDo: may be handy in other cases too) >>>> >>>> - something different :) >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

July 24, 2014

Re: [Pharo-dev] File Outs: Can We Have Unix Line Endings?

by Esteban A. Maringolo

2014-07-24 2:17 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Any reason not to? Tedious to continually do "%s/\r/\r/g"s on Mac to fix: > TextStream subclass:^M#UCTextStream^MinstanceVariableNames: > ''^MclassVariableNames: ''^MpoolDictionaries: ''^Mcategory: 'UFFA-Core'!^M! Yes please. And have an option to switch to any other ending for those who want it that way for any uncomprehensible reason :P. But Unix by default. Esteban A. Maringolo

July 24, 2014

Re: [Pharo-dev] On my way to vacation

by Marcus Denker

On 24 Jul 2014, at 15:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > I drive past Lille, and would be interested in spending an afternoon the 29. doing some pair programming > (and the evening preferably with some beer and a good diner). I would be hereâ¦ people are slowly leaving for holidays, but there will be still some here. So for me it would fit perfectly. > Would need to find a place to sleep for us (wife and 2 boys of 5 & 7) though. > My flat is to small for thatâ¦ -> AirBnB? But for just one night maybe too much hassle. -> For 4 people, I heard good reviews about the Suite Novotel directly at the Lille Europe station. http://www.tripadvisor.co.uk/Hotel_Review-g187178-d628635-Reviews-Suite_Nov… Around EUR 90 for a room for 4, plus EU20 or so for Parking. Marcus

July 24, 2014

Re: [Pharo-dev] Morphic Core dependencies

by Serge Stinckwich

On Thu, Jul 24, 2014 at 3:15 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2014-07-24 14:33 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Pavel >> >> [ Morphic-Core ] WorldMorph>>mouseDown: evt >> super mouseDown: evt. >> self currentWindow ifNotNil: [ :topWindow | >> SystemWindow passivateTopWindow ] >> >> creates another dependencies to Morphic-Widgets-Windows > > > I can see this dependencies as Undeclared in the generated image. > >> >> >> There is also >> >> slideBackToFormerSituation: that could be omve to morphic-base because >> it refers to transformation morph. > > > It is very ugly dependency because we need this classes only for one > uncommon case. If it is possible, I would gladly to remove this obsucre code > and not add the next one :-) > >> >> >> Pavel why don't we use >> https://github.com/pharo-project/pharo-workingRoadmaps >> >> to share possible ideas? > > > I would prefer some on-line solution. Eg. wiki on Google Code that is still > active... You could modify these roadmaps online like a Wiki. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 24, 2014

On my way to vacation

by Stephan Eggermont

I drive past Lille, and would be interested in spending an afternoon the 29. doing some pair programming (and the evening preferably with some beer and a good diner). Would need to find a place to sleep for us (wife and 2 boys of 5 & 7) though. Stephan

July 24, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Pavel Krivanek

2014-07-24 15:01 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> On 24/7/14 13:37, Pavel Krivanek wrote: >> >>> Hi, >>> >>> SystemWindows support >>> ============================ >>> SystemWindow is quite complex morph that requires many of other morph >>> classes including text morphs, theming support etc. But in several >>> situations the system windows play special role and the Morphic core >>> classes need to be aware of them. So we have several options: >>> >>> - (current) do not have SystemWindow & co. in the image but let basic >>> support of them. That will produce some unimplemented calls >>> >>> - create very simple SystemWindow superclass that will be part of the >>> Morphic-Core but will not have look and possibilities of real SystemWindow >>> >>> - include SystemWindow and supporting classes >>> >> I had the same questions than you: >> - I have the impression that systemWindow is really linked to widgets. >> > > I think we should go with option 2 and have a way of providing basic > windows. SystemWindow is too much anyway. > one problem is that SystemWindow/isSystemWindow is hardcoded on so many places... > >> >> Tools >>> ============================ >>> The current image generated by this configuraton will crash as soon as >>> you try to press some keyboard button. The reason is in the method >>> Morph>>#handleKeystroke. This method contains this code to support >>> Keymapping >>> >>> Smalltalk tools shortcuts handleKeystroke: anEvent inMorph: self. >>> >> >> I think that keymapping should not be a tool but the default way to >> change and control shortcuts. >> Do you have a take on this? > > > +1. Although it can still be improved, keymapping is better than any other > option we have and we should promote it as the default mechanism. > > Cheers, > Doru > I checked the package dependensies of Keymappings and Keymapping-Core, Keymapping-KeyCombinations and Keymapping-Pragmas. The only ugly dependency is on MenuRegistration (that is dependent on several other packages). Becuase this is only one place where the Keymappings are used in Morphic-Core, I whould prefer to add a class variable named ShortcutsHandler to Morph and register Keymappings here (or let it be nil for Morphic-Core) -- Pavel > > > The #tools message is part of Tool-Base package and need to be there >>> because it uses lazy evaluation that creates a ToolRegistry instance. >>> Because Tool-Base is not loaded in the minimal nor Morphic-Core image, it >>> raises DNU >>> >>> Solutions: >>> - introduce some safer form like Smalltalk withToolsDo: [:tools | ...]. >>> In this case it will not be able to look if the class variable "Tools" is >>> nil (because of lazy evaluation) but it will need to do some ugly check of >>> presence of ToolRegistry class or something similar. In this case we will >>> produce more unimplemented calls (on several places in the image because >>> withToolsDo: may be handy in other cases too) >>> >>> - something different :) >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

July 24, 2014

Re: [Pharo-dev] Komitter in 30852?

by Stephan Eggermont

Works for me. Thank you Thierry! Stephan

July 24, 2014

Re: [Pharo-dev] Morphic Core dependencies

by Pavel Krivanek

2014-07-24 14:33 GMT+02:00 stepharo <stepharo(a)free.fr>: > Pavel > > [ Morphic-Core ] WorldMorph>>mouseDown: evt > super mouseDown: evt. > self currentWindow ifNotNil: [ :topWindow | > SystemWindow passivateTopWindow ] > > creates another dependencies to Morphic-Widgets-Windows > I can see this dependencies as Undeclared in the generated image. > > There is also > > slideBackToFormerSituation: that could be omve to morphic-base because > it refers to transformation morph. > It is very ugly dependency because we need this classes only for one uncommon case. If it is possible, I would gladly to remove this obsucre code and not add the next one :-) > > Pavel why don't we use > https://github.com/pharo-project/pharo-workingRoadmaps > > to share possible ideas? I would prefer some on-line solution. Eg. wiki on Google Code that is still active... -- Pavel > > > > > On 24/7/14 14:24, stepharo wrote: > >> Hi pavel >> >> this is related to your interrogations about system window >> >> Gofer it >> smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; >> configuration; >> loadStable >> > > >

July 24, 2014

Re: [Pharo-dev] Komitter in 30852?

by Thierry Goubier

2014-07-24 12:19 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > Open a fresh 30852 with 355 (Mac Mavericks 10.9.4). > Open a Nautilus browser, create class Bla in category Bla. > Open Komitter, 6 MNUs > Close MNUs and Komitter > add a class Blah in category Bla > Open Komitter, 10 MNUs > > I tried it originally on an image that took over a minute to produce the > MNUs... > > Stephan > Can you try with slice 13680 loaded? I backported the fix. Do I need to unsubscribe an object listening to MorphDeleted or not? Thierry

July 24, 2014