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

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

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Thierry Goubier

2014-07-24 13:47 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 24/7/14 13:37, Pavel Krivanek 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 >> > I would take this one. Having a minimal Morphic is to be able to do GUI stuff, and this requires some form of SystemWindow. Maybe a fullscreen SystemWindow / world abstraction then? If I only load Morphic-Core, then I can use it for full-screen demos. > >> - include SystemWindow and supporting classes >> > I had the same questions than you: > - I have the impression that systemWindow is really linked to widgets. > > > > 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? Looks like an integration fault to me (hidden dependency on KeyMapping). handleKeystroke: was a Keymapping-Core-override in 2.0. In 3.0 and 4.0, it's a core method of Morph... If you go back to 2.0, no more problem :) Thierry

July 24, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by stepharo

On 24/7/14 13:37, Pavel Krivanek 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 I had the same questions than you: - I have the impression that systemWindow is really linked to widgets. > 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? > 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 >

July 24, 2014

ConfigurationOfMorphicCore

by Pavel Krivanek

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

July 24, 2014

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

by Damien Cassou

On Thu, Jul 24, 2014 at 9:32 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Why you cannot detect OS and then format accordingly? OSPlatform current lineEnding -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 24, 2014

Re: [Pharo-dev] Refactor Nautilus

by Damien Cassou

please On Thu, Jul 24, 2014 at 11:49 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-07-24 10:28 GMT+02:00 Baptiste Quide <baptiste.quide(a)inria.fr>: > >> Good luck for that. >> I will have a look because the tool which allows to watch package >> dependencies embeds the Nautilus Browser, and i'm one of the maintainer at >> this time. > > > Good to know! > >> >> >> Baptiste >> >> ________________________________ >> >> De: "Nicolai Hess" <nicolaihess(a)web.de> >> Ã: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> EnvoyÃ©: Jeudi 24 Juillet 2014 10:23:15 >> Objet: [Pharo-dev] Refactor Nautilus >> >> >> If no one raises objections, I would like to start on refactor / cleanup >> nautilus code. >> >> This includes: >> >> renaming / recategorizing >> solve code critics shown in Critics Browser >> split classes (AbstractNautilusUI has 427 methods 24 instvars ) >> stronger separation between the browser model, browser state >> and browser UI. >> >> review event handling and UI updating >> (sometimes there is a difference between what the UI shows >> as selected and the selection the model(s) holds >> >> maybe: >> create one package pane widget for package and groups >> (therefore move all that package vs groups handling from >> nautilus ui to that widget) >> merge Nautilus and PackageTreeNautilus >> >> (I don't consider all of Nautilus bad code, it has well >> designed parts, it just has grown meanwhile...) >> >> How to update the code? >> >> Working with slices makes it easier to find changes >> that introduces new bugs. >> Otherwise it takes time to do it in such small steps and I don't >> know if those changes are reviewed at all. >> >> So, I would try to group the changes. >> 1. code critics >> 2. renameing/ simple refactoring >> 3. .... >> >> >> nicolai >> >> >> >> > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 24, 2014