August 2015 - Pharo-dev - lists.pharo.org

World Menu associated mouse click

by Ben Coman

A while back on reddit someone complained about the World Menu being associated with left-mouse-click. I have come to agree. The World Menu provides the actions available in the context of the World, i.e. the World's context-menu - but its not invoked by the usual convention for context menus, which is the right-mouse-click. By way of example, in a fresh image and open one Playground. * First right-click the Playground. Up comes the Playground's context-menu as expected per industry wide conventions. * Then right-click the background. Doh! Its not consistent, thats not the World's context-menu. "WTH is that?" says a newbie in surprise. (Btw, who uses that list of open windows ? I *never* do and might suggest that function be moved to a meta-mouse-click.) So can we discuss changing the World Menu to be invoked by the context-click (i.e. right-click) ? cheers -ben

Aug. 17, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50240 Home: https://github.com/pharo-project/pharo-core

Aug. 17, 2015

[pharo-project/pharo-core] 970e8c: 50240

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 970e8cb7bfb2ffa40a8c1de80425fe71763a1afe https://github.com/pharo-project/pharo-core/commit/970e8cb7bfb2ffa40a8c1de8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-17 (Mon, 17 Aug 2015) Changed paths: A Morphic-Widgets-Basic.package/PluggableToggleButtonMorph.class/instance/accessing/on_getState_action_label_icon_menu_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/showHierarchy_.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui buttons/buildCommentButton.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui buttons/buildHierarchyButton.st M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithoutComment.st M Nautilus.package/Nautilus.class/class/opening/openOnPackage_class_category_method_group_sortHierarchically_showHierarchy_showComment_showInstance_showCategories_inEnvironment_.st M Nautilus.package/Nautilus.class/definition.st M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showHierarchy_.st M NautilusGroupAutoBuilder.package/LoadedPackagesGroupCreatingCodeProvider.class/class/public access/configurationName_versionString_projectName_.st M RPackage-Core.package/RPackage.class/class/class initialization/initialize.st A RPackage-Core.package/RPackage.class/class/class initialization/initializeProperties.st M RPackage-Core.package/RPackage.class/definition.st A RPackage-Core.package/RPackage.class/instance/properties/ensureProperties.st A RPackage-Core.package/RPackage.class/instance/properties/properties.st A RPackage-Core.package/RPackage.class/instance/properties/propertyAt_.st A RPackage-Core.package/RPackage.class/instance/properties/propertyAt_ifAbsentPut_.st A RPackage-Core.package/RPackage.class/instance/properties/propertyAt_ifAbsent_.st A RPackage-Core.package/RPackage.class/instance/properties/propertyAt_put_.st A RPackage-Core.package/RPackage.class/instance/properties/removePropertiesIfEmpty.st A RPackage-Core.package/RPackage.class/instance/properties/removeProperty_.st A RPackage-Core.package/RPackage.class/instance/properties/removeProperty_ifAbsent_.st A RPackage-Tests.package/RPackageTest.class/instance/tests - properties/testPropertyAtPut.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50239.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50240.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50239.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50240.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/Slot.class/instance/properties/properties.st Log Message: ----------- 50240 16240 Rename loop variable to avoid conflicts in NautilusGroupAutoBuilder https://pharo.fogbugz.com/f/cases/16240 16227 Nautilus wrong buttonstate (hierarchy/class) https://pharo.fogbugz.com/f/cases/16227 16243 add property API to RPackage https://pharo.fogbugz.com/f/cases/16243 http://files.pharo.org/image/50/50240.zip

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Dimitris Chloupis

checking the name of the class should be enough, if you want to be more safe you could also check method names too. On Mon, Aug 17, 2015 at 12:16 PM Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > It could be easily done, but in a ugly way to me. The only thing you know > about a configuration package is that its name begins with > 'ConfigurationOf', or it has some specific methods. There is no data above > a package to know if it is a regular one or a configuration. Am I wrong ? > If there is, it can be done in a better way. > > Franck > > ------------------------------ > From: kilon.alios(a)gmail.com > Date: Mon, 17 Aug 2015 09:04:09 +0000 > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Projects are slowly getting to live... and > > > impressive you guys are busy non stop, I am feel so glad Pharo move > forward so fast. > > No I did not mean to remove configurations but rather hide them, or group > them together so they dont display together with other packages. > > On Mon, Aug 17, 2015 at 12:01 AM stepharo <stepharo(a)free.fr> wrote: > > First it could be worse :) We cannot build a full ecosystem without > capturing dependencies. > > Second we are (christophe) working since a year on the Cargo Package > Manager. > [Christophe knows many package manager (Java ruby and others).] > With Cargo every single package expresses its dependencies instead of > using external packages such as a Configuration. > So we will see how it goes. > > Stef > > > One of the things that annoy me is how many Configurations and Baselines > pollute the package space that are of little interest to the user. It would > be nice to group them and filter them out of Nautilus unless user asks for > them. > > I really like this new approach great work. > > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr> wrote: > > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : > > stepharo wrote > >> you get a project (group) with all your packages together ready to work > ;) > > Cool! I feel more and more that the standard "Package" pane is only > useful > > for... packaging, and when one takes off the dependency management hat > and > > puts the user hat on (i.e. most of the time), what you really want there > is > > a logical view of the system. So I see three use cases: > > - Logical view of the system - I guess this was the original intention of > > Categories, but has been hijacked by Monticello > > - By project - which, as you just showed, we have now, yay! > > - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > > >

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Thierry Goubier

2015-08-17 14:54 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > I tried your shortcuts for selecting a package, it highlights it but does > not select it in Pharo 5. > Ok, I'll have a look later tonight. Thierry > > On Mon, Aug 17, 2015 at 3:37 PM Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> 2015-08-17 14:34 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> yeap AltBrowser indeed does it, nice , time to give it another try:) >>> >> >> The thing I haven't done yet is turn a category of packages in a RB >> environment, to scope all commands and searches to that. Ah well, there is >> allways something to do ;) >> >> Thierry >> >> >>> >>> On Mon, Aug 17, 2015 at 12:36 AM Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> Le 16/08/2015 22:48, Dimitris Chloupis a Ã©crit : >>>> > One of the things that annoy me is how many Configurations and >>>> Baselines >>>> > pollute the package space that are of little interest to the user. It >>>> > would be nice to group them and filter them out of Nautilus unless >>>> user >>>> > asks for them. >>>> >>>> This is what AltBrowser does. All configurations are in a category named >>>> 'Configurations' and all Baselines are in a category named 'Baselines'. >>>> Unless you really search for it, you won't see it. >>>> >>>> > I really like this new approach great work. >>>> >>>> It certainly help. >>>> >>>> I have played a bit with extracting info from Configurations to classify >>>> automagically, but it doesn't work very well. >>>> >>>> Thierry >>>> >>>> > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr >>>> > <mailto:stepharo@free.fr>> wrote: >>>> > >>>> > >>>> > >>>> > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : >>>> > > stepharo wrote >>>> > >> you get a project (group) with all your packages together >>>> ready >>>> > to work ;) >>>> > > Cool! I feel more and more that the standard "Package" pane is >>>> > only useful >>>> > > for... packaging, and when one takes off the dependency >>>> > management hat and >>>> > > puts the user hat on (i.e. most of the time), what you really >>>> > want there is >>>> > > a logical view of the system. So I see three use cases: >>>> > > - Logical view of the system - I guess this was the original >>>> > intention of >>>> > > Categories, but has been hijacked by Monticello >>>> > > - By project - which, as you just showed, we have now, yay! >>>> > > - By package - the least useful, but primary (up til now), view >>>> > >>>> > Indeed. >>>> > We will see what we get at the end but may be something like >>>> > >>>> > MyProject >>>> > AnotherProject >>>> > System >>>> > LowLevel >>>> > >>>> > And people will not be overwhelmed by hundreds of nice packages. >>>> :) >>>> > >>>> > I think that touching package contents under the assumption that >>>> the >>>> > package list is too long in the UI >>>> > is the wrong way to look at the problem. >>>> > Packages are unit of deployment and we need Projects - unit >>>> of >>>> > knowledge. And the UI should shows both >>>> > depending on the view we want to get. >>>> > >>>> > Stef >>>> > > >>>> > > >>>> > > >>>> > > ----- >>>> > > Cheers, >>>> > > Sean >>>> > > -- >>>> > > View this message in context: >>>> > >>>> http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… >>>> > > Sent from the Pharo Smalltalk Developers mailing list archive >>>> at >>>> > Nabble.com. >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> >>>> >>>>

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Dimitris Chloupis

I tried your shortcuts for selecting a package, it highlights it but does not select it in Pharo 5. On Mon, Aug 17, 2015 at 3:37 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2015-08-17 14:34 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> yeap AltBrowser indeed does it, nice , time to give it another try:) >> > > The thing I haven't done yet is turn a category of packages in a RB > environment, to scope all commands and searches to that. Ah well, there is > allways something to do ;) > > Thierry > > >> >> On Mon, Aug 17, 2015 at 12:36 AM Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Le 16/08/2015 22:48, Dimitris Chloupis a Ã©crit : >>> > One of the things that annoy me is how many Configurations and >>> Baselines >>> > pollute the package space that are of little interest to the user. It >>> > would be nice to group them and filter them out of Nautilus unless user >>> > asks for them. >>> >>> This is what AltBrowser does. All configurations are in a category named >>> 'Configurations' and all Baselines are in a category named 'Baselines'. >>> Unless you really search for it, you won't see it. >>> >>> > I really like this new approach great work. >>> >>> It certainly help. >>> >>> I have played a bit with extracting info from Configurations to classify >>> automagically, but it doesn't work very well. >>> >>> Thierry >>> >>> > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr >>> > <mailto:stepharo@free.fr>> wrote: >>> > >>> > >>> > >>> > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : >>> > > stepharo wrote >>> > >> you get a project (group) with all your packages together ready >>> > to work ;) >>> > > Cool! I feel more and more that the standard "Package" pane is >>> > only useful >>> > > for... packaging, and when one takes off the dependency >>> > management hat and >>> > > puts the user hat on (i.e. most of the time), what you really >>> > want there is >>> > > a logical view of the system. So I see three use cases: >>> > > - Logical view of the system - I guess this was the original >>> > intention of >>> > > Categories, but has been hijacked by Monticello >>> > > - By project - which, as you just showed, we have now, yay! >>> > > - By package - the least useful, but primary (up til now), view >>> > >>> > Indeed. >>> > We will see what we get at the end but may be something like >>> > >>> > MyProject >>> > AnotherProject >>> > System >>> > LowLevel >>> > >>> > And people will not be overwhelmed by hundreds of nice packages. :) >>> > >>> > I think that touching package contents under the assumption that >>> the >>> > package list is too long in the UI >>> > is the wrong way to look at the problem. >>> > Packages are unit of deployment and we need Projects - unit >>> of >>> > knowledge. And the UI should shows both >>> > depending on the view we want to get. >>> > >>> > Stef >>> > > >>> > > >>> > > >>> > > ----- >>> > > Cheers, >>> > > Sean >>> > > -- >>> > > View this message in context: >>> > >>> http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… >>> > > Sent from the Pharo Smalltalk Developers mailing list archive at >>> > Nabble.com. >>> > > >>> > > >>> > > >>> > >>> > >>> >>> >>>

Aug. 17, 2015

Re: [Pharo-dev] Mongo - find object by id

by Sabine Manaa

Hi Steph, thanks. I am editing my suggestions and tell you when finished. Regards Sabine 2015-08-16 19:29 GMT+02:00 stepharo <stepharo(a)free.fr>: > > Hi Stephane, > > I have collected my points to add to the book. > > Can you give me an entry point how to do a pull request on the paper > please? > Pillar? Editor? Script? Sounds complicated for the first time. > > If you can use pillar this is better, else we will do a pass and convert > it to pillar > Since the chapter is for the book that should be out I'm not that editing > it directly is a good. > Now what we can do is to work on on a separate file that Johan or Esteban > can merge to the chapter once > it is finished. > > What I was thinking about is to have a series of extras section > with for example some of the problems and solutions you encountered. > > > How to handle loop within your domain? > > How to find an object by id? > > ... > > The original file is here: > > > https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Voya… > > > I created a VoyageAdditionalText.pier that you can edit. > > And this is easy > - you can go to the page > - fork the folder > - edit in the web the file and send a pull request. > > if this is not working, we will add you to the project and you can > directly edit this file. > > Regards > Sabine > > > > 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> Hi Stephane, >> >> sure, I am happy to give something back to the community. I dont have so >> much time because of my baby but I will try my best. >> >> Where shall I put it in? >> >> >> You can do pull requests in the paper. This way they will be close to the >> original version. >> >> >> Sabina >>> >>> you know what I would really love from you .... >>> this is that you reread the Voyage chapter and make a list of the >>> problems you faced and that are not described in the chapter. >>> You can write it in any bad ways and we can do a edit phase after, >>> >>> Why do I ask that? Because I'm stupid in Mongo and I would love to have >>> a good doc. >>> And only the people facing the problems can spot them nicely. >>> I often write doc on things that I do not know but this is not working >>> well because I'm slow in that case and .... I could be much better >>> doing something else where I'm good at. >>> >>> Stef >>> >>> Le 12/8/15 09:40, Sabine Manaa a Ã©crit : >>> >>>> Hi, >>>> >>>> on mongo console, this brings me a persons information from mongo db >>>> db.Persons.find({"_id" : ObjectId("75b900000000000000000000")}) >>>> >>>> I try to query the same person from pharo and I do not succeed. >>>> >>>> This makes my image hanging: >>>> RKAPerson selectMany: {('_id' -> (OID >>>> value:'75b900000000000000000000'))} >>>> >>>> also other variations e.g. >>>> RKAPerson selectMany: {('_id' -> ('75b900000000000000000000')). } >>>> asDictionary. >>>> >>>> do not work >>>> >>>> Other queries like >>>> RKAPerson selectMany:{('lastName' -> ('Maier')).} asDictionary. >>>> or >>>> RKAPerson selectMany:{('nextTripNumber' -> (57)).} asDictionary. >>>> >>>> work fine. >>>> >>>> How can I query for an object with the object id? >>>> >>>> Regards >>>> Sabine >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Mongo-find-object-by-id-tp4842231.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>>> >>>> >>> >>> >> > >

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Thierry Goubier

2015-08-17 14:34 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > yeap AltBrowser indeed does it, nice , time to give it another try:) > The thing I haven't done yet is turn a category of packages in a RB environment, to scope all commands and searches to that. Ah well, there is allways something to do ;) Thierry > > On Mon, Aug 17, 2015 at 12:36 AM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Le 16/08/2015 22:48, Dimitris Chloupis a Ã©crit : >> > One of the things that annoy me is how many Configurations and Baselines >> > pollute the package space that are of little interest to the user. It >> > would be nice to group them and filter them out of Nautilus unless user >> > asks for them. >> >> This is what AltBrowser does. All configurations are in a category named >> 'Configurations' and all Baselines are in a category named 'Baselines'. >> Unless you really search for it, you won't see it. >> >> > I really like this new approach great work. >> >> It certainly help. >> >> I have played a bit with extracting info from Configurations to classify >> automagically, but it doesn't work very well. >> >> Thierry >> >> > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr >> > <mailto:stepharo@free.fr>> wrote: >> > >> > >> > >> > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : >> > > stepharo wrote >> > >> you get a project (group) with all your packages together ready >> > to work ;) >> > > Cool! I feel more and more that the standard "Package" pane is >> > only useful >> > > for... packaging, and when one takes off the dependency >> > management hat and >> > > puts the user hat on (i.e. most of the time), what you really >> > want there is >> > > a logical view of the system. So I see three use cases: >> > > - Logical view of the system - I guess this was the original >> > intention of >> > > Categories, but has been hijacked by Monticello >> > > - By project - which, as you just showed, we have now, yay! >> > > - By package - the least useful, but primary (up til now), view >> > >> > Indeed. >> > We will see what we get at the end but may be something like >> > >> > MyProject >> > AnotherProject >> > System >> > LowLevel >> > >> > And people will not be overwhelmed by hundreds of nice packages. :) >> > >> > I think that touching package contents under the assumption that the >> > package list is too long in the UI >> > is the wrong way to look at the problem. >> > Packages are unit of deployment and we need Projects - unit of >> > knowledge. And the UI should shows both >> > depending on the view we want to get. >> > >> > Stef >> > > >> > > >> > > >> > > ----- >> > > Cheers, >> > > Sean >> > > -- >> > > View this message in context: >> > >> http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… >> > > Sent from the Pharo Smalltalk Developers mailing list archive at >> > Nabble.com. >> > > >> > > >> > > >> > >> > >> >> >>

Aug. 17, 2015

Re: [Pharo-dev] Projects are slowly getting to live... and

by Dimitris Chloupis

yeap AltBrowser indeed does it, nice , time to give it another try:) On Mon, Aug 17, 2015 at 12:36 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 16/08/2015 22:48, Dimitris Chloupis a Ã©crit : > > One of the things that annoy me is how many Configurations and Baselines > > pollute the package space that are of little interest to the user. It > > would be nice to group them and filter them out of Nautilus unless user > > asks for them. > > This is what AltBrowser does. All configurations are in a category named > 'Configurations' and all Baselines are in a category named 'Baselines'. > Unless you really search for it, you won't see it. > > > I really like this new approach great work. > > It certainly help. > > I have played a bit with extracting info from Configurations to classify > automagically, but it doesn't work very well. > > Thierry > > > On Sun, Aug 16, 2015 at 7:34 PM stepharo <stepharo(a)free.fr > > <mailto:stepharo@free.fr>> wrote: > > > > > > > > Le 16/8/15 17:00, Sean P. DeNigris a Ã©crit : > > > stepharo wrote > > >> you get a project (group) with all your packages together ready > > to work ;) > > > Cool! I feel more and more that the standard "Package" pane is > > only useful > > > for... packaging, and when one takes off the dependency > > management hat and > > > puts the user hat on (i.e. most of the time), what you really > > want there is > > > a logical view of the system. So I see three use cases: > > > - Logical view of the system - I guess this was the original > > intention of > > > Categories, but has been hijacked by Monticello > > > - By project - which, as you just showed, we have now, yay! > > > - By package - the least useful, but primary (up til now), view > > > > Indeed. > > We will see what we get at the end but may be something like > > > > MyProject > > AnotherProject > > System > > LowLevel > > > > And people will not be overwhelmed by hundreds of nice packages. :) > > > > I think that touching package contents under the assumption that the > > package list is too long in the UI > > is the wrong way to look at the problem. > > Packages are unit of deployment and we need Projects - unit of > > knowledge. And the UI should shows both > > depending on the view we want to get. > > > > Stef > > > > > > > > > > > > ----- > > > Cheers, > > > Sean > > > -- > > > View this message in context: > > > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p484… > > > Sent from the Pharo Smalltalk Developers mailing list archive at > > Nabble.com. > > > > > > > > > > > > > > > >

Aug. 17, 2015

Re: [Pharo-dev] RBFutureDeprecationWarningRule: remove?

by Marcus Denker

> On 17 Aug 2015, at 14:25, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Maybe we can have a superclass for that? Because for example selection (highlight) of the problematic code was not implemented some time ago for RBFutureDeprecationWarningRule. And itâs not trivial to do. So maybe having a superclass that implements this functionality can be useful. > Yes, that would be good. Marcus

Aug. 17, 2015