- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Tudor Girba

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. > > 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 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] ConfigurationOfMorphicCore

by Tudor Girba

Really great! Doru On Thu, Jul 24, 2014 at 1:37 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > in latest update we integrated several patches needed for proper working > of ConfiguratonOfMorphicCore. This simple configuration loads Morphic-Core > package into the minimal image and initializes it so the result is a small > standalone Morphic subset. > > But some issues that I would like to discuss with the community left: > > 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 > > 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. > > 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

Deprecator

by Camille Teruel

Hello Pharo users, I'm pleased to announce the release of Deprecator. It's a prototype of a small tool that permits you to deprecate method by annotating them with a <deprecated: ...> pragma. This pragma takes a rewrite expression as argument that specifies how to rewrite the message send to the deprecated method. If such a deprecated method is executed, a warning is thrown and a debugger opens. This debugger has a little 'Rewrite' button that permits to rewrite the sending method according to the rewrite expression and then resume the execution with the new rewritten sending method :) The implementation is a proof-of-concept and is a bit hacky here and there, but it works. Example: You have a class C with a method that you deprecate. Its rewrite expression tells that if it's executed as the result of a message send of the form: <receiver> deprecatedMethodArg1: <arg1> arg2: <arg2>, this message send should be rewritten to: <receiver> replacementMethodArg1: <arg2> arg2: <arg1>. Note you can change the order of arguments or even the receiver. C>>deprecatedMethodArg1: o1 arg2: o2 <deprecated: '`@receiver replacementMethodArg1: `@arg2 arg2: `@arg1'> ^ #deprecated C>>replacementMethodArg1: o1 arg2: o2 ^ #replacement C>>senderMethod ^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2. Then if you execute C new senderMethod, and then click on the "Rewrite" button of the debugger, then sending method is rewritten to: C>>senderMethod ^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1. and the result is #replacement. The repo is on sSmalltalkHub: MCHttpRepository location: 'http://smalltalkhub.com/mc/CamilleTeruel/Deprecator/main' user: '' password: '' I hope for comments, feature suggestions, code reviews, contributors, etc :) BTW, if you have a better name for this project let me know! For example, I thought about Ammonite because it's an extinct animal (analogy with deprecated) and it fits the sea naming theme. Cheers, Camille

July 24, 2014

Re: [Pharo-dev] Morphic Core dependencies

by stepharo

Pavel [ Morphic-Core ] WorldMorph>>mouseDown: evt super mouseDown: evt. self currentWindow ifNotNil: [ :topWindow | SystemWindow passivateTopWindow ] creates another dependencies to Morphic-Widgets-Windows There is also slideBackToFormerSituation: that could be omve to morphic-base because it refers to transformation morph. Pavel why don't we use https://github.com/pharo-project/pharo-workingRoadmaps to share possible ideas? 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

Morphic Core dependencies

by stepharo

Hi pavel this is related to your interrogations about system window Gofer it smalltalkhubUser: 'BaptisteQuide' project: 'PackageDependenciesAnalysis'; configuration; loadStable

July 24, 2014