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

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

by Tudor Girba

Hi Esteban, Sorry for the delayed response. There are two parts in your mail: 1. the decomposition of theme to have one themer per widget 2. a centralized catalog of values I certainly agree with 2. In fact, when I refactored the theme colors a long time ago, I introduced a rudimentary reuse mechanism on the class side of the Theme class. So, now, we should extract those separately. About 1., I have a different opinion. The hierarchy you mention already exists in the Theme class as well, only it is hidden, and it is very hard to see what each methods impacts. Here is how I reached this conclusion. Take a look at this picture I produced before we started with Brick (the one from Morphic). The gray circles are methods in UITheme, and the red circles are typical Morphs (like TextMorph, ListMorph). The gray lines show self calls inside the UITheme, and the red lines shod calls from the morph to the UITheme methods. What you see here is a very strong clustering of the methods around the widgets, and this indicates that having a theme object per widget is appropriate. A further constrain is that we want to be able to change the appearance of a widget on an instance basis (that is, overriding the default theme setting), and having a per-widget themer object, we can achieve that as well. A similar design appears in Bloc as well, and I think it is actually more scalable then the current UITheme, provided that you indeed have a way to either centralize the definitions of colors (and other properties), or inject those properties from the outside. All in all, letâs go ahead and extract the palette :). Cheers, Doru > On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > For one of my side-projects, I made a new theme for Pharo (still no name, I was planing to call it âDark Metalâ or something like that. Is a variation on the Dark Theme but âourâ dark theme is more brown and this one is more blue (see attached)â¦ I wanted to publish it to push it but then I arrived to an unexpected problem: For Spotter and GTTools in general, theming is not done following current theming approach. Instead, they made a full hierarchy of objects. > > IMO this is plain bad. I understand the attempt to decouple, but now that means if I want to create a new theme, I need to create my theme object with colors I want and then also I need to create an undetermined number of classes (at least one for each tool, but there is also a hierarchy of things there)â¦ anyway, this DOES NOT scale. Because each tool will have to have a âtheme classâ for each existing themeâ¦ > How themes (skins, bah) work in all word is to have a color palette and then tools takes them (they can âplayâ a bit with this palette, but need to always respect the palette). > > Then, I will commit a SLICE modifying the âthemerâ classes to take colors from the current theme (instead of have them hardcoded). > But of course, how theme work now is not good because they mix âthemeâ (how they display) and âskinâ (color palette). I will also extract the palette to where should have always been (some kind of a style sheet object)â¦ who also should have been editable in settings so people can tweak their configuration. > > I didnât wanted to touch this before, because this will supposedly change with brick, but honestly this will not be ready for Pharo 6 and this is annoying (also, I want to publish my theme and I do not want to add overrides all around :P) > > cheers, > Esteban > > > <Screen Shot 2016-08-01 at 11.00.15.png> -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Aug. 4, 2016

Re: [Pharo-dev] [ANN] MatchTool

by Nicolai Hess

2016-08-04 11:38 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Hey Uko, > > this pattern for a message sent: > > `@msg:`@args > > can match message sends with or without arguments, so it matches both > > 1 squared. > and > 1 raisedTo:2 > > The problem is that the first match "1 squared" will give a DNU on the > right pane, as the argument var '@args is empty. > > And if you match a method, it can happen that the keys <-> values in the map are actually strings or text and not a pattern variable (-source--, -pragma-, and the pattern method selector). > > > 2016-08-04 10:23 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi everyone! >> >> Iâm happy to announce a new tool that can help you to understand to the >> pattern code is working in match & rewrite rules. >> You can read more on my blogpost: http://blog.yuriy.ty >> mch.uk/2016/08/matchtool.html >> The tool is available for Pharo 6 from the catalog. >> >> >> Cheers! >> Uko >> > >

Aug. 4, 2016

Re: [Pharo-dev] [ANN] MatchTool

by Nicolai Hess

Hey Uko, this pattern for a message sent: `@msg:`@args can match message sends with or without arguments, so it matches both 1 squared. and 1 raisedTo:2 The problem is that the first match "1 squared" will give a DNU on the right pane, as the argument var '@args is empty. 2016-08-04 10:23 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi everyone! > > Iâm happy to announce a new tool that can help you to understand to the > pattern code is working in match & rewrite rules. > You can read more on my blogpost: http://blog.yuriy. > tymch.uk/2016/08/matchtool.html > The tool is available for Pharo 6 from the catalog. > > > Cheers! > Uko >

Aug. 4, 2016

[ANN] MatchTool

by Yuriy Tymchuk

Hi everyone! Iâm happy to announce a new tool that can help you to understand to the pattern code is working in match & rewrite rules. You can read more on my blogpost: http://blog.yuriy.tymch.uk/2016/08/matchtool.html The tool is available for Pharo 6 from the catalog. Cheers! Uko

Aug. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 4, 2016

[pharo-project/pharo-core] 31f30e: 60168

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 31f30e5e8f01ec9696c792611dcd51f4d93b84b0 https://github.com/pharo-project/pharo-core/commit/31f30e5e8f01ec9696c79261… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-04 (Thu, 04 Aug 2016) Changed paths: A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st R ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version798_.st A EpiceaBrowsers.package/EpLostChangesDetector.class/class/accessing/enabled_.st M EpiceaBrowsers.package/EpLostChangesDetector.class/class/startup - shutdown/startUp_.st A EpiceaBrowsers.package/EpLostChangesDetector.class/class/testing/isEnabled.st A EpiceaBrowsers.package/EpSettings.class/class/accessing/lostEventsDetectorEnabled.st A EpiceaBrowsers.package/EpSettings.class/class/accessing/lostEventsDetectorEnabledSettingOn_.st A EpiceaBrowsers.package/EpSettings.class/class/accessing/lostEventsDetectorEnabled_.st M EpiceaBrowsers.package/EpSettings.class/class/system settings/enabledSettingOn_.st M EpiceaBrowsers.package/EpSettings.class/class/system settings/groupSettingsOn_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/classDefinitionModified_.st M Ombu.package/OmFileStore.class/definition.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/accessing/ast.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/backward compatibility/messages.st A Ring-Core-Kernel.package/RGMethodDefinition.class/instance/private/astFromSource.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/testing/isAbstract.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/testing/isOverridden.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/traits/argumentNames.st R Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/as yet unclassified/foo.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/running/runCase.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/running/tearDown.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testASTExistingMethod.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testASTNonExistingMethodWithNoSource.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testASTNonExistingMethodWithSource.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testArgumentNamesExistingMethod.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testArgumentNamesNonExistingMethodWithNoSource.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testArgumentNamesNonExistingMethodWithSource.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testIsAbstractExistingMethod.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testIsAbstractNonExistingMethod.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testMessagesExistingMethod.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testMessagesNonExistingMethodWithNoSource.st A Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/test - accessing source/testMessagesNonExistingMethodWithSource.st M Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/testing/testAsActive.st M Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/testing/testAsHistorical.st M Ring-Tests-Kernel.package/RGMethodDefinitionTest.class/instance/testing/testAsPassive.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60167.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60168.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60167.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60168.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60168 18856 After Epicea integration: "an OmReference(Pharo_2elhj7i:199) not found in OmSessionStore" https://pharo.fogbugz.com/f/cases/18856 17710 rename variable do not update class template https://pharo.fogbugz.com/f/cases/17710 18855 reduce calls on #compiledMethod in RGMethodDefinition https://pharo.fogbugz.com/f/cases/18855 18860 cleanup after running RGMethodDefintionTest https://pharo.fogbugz.com/f/cases/18860 http://files.pharo.org/image/60/60168.zip

Aug. 4, 2016

Re: [Pharo-dev] Stable configuration of PetitParser broken for stable PetitGui in Pharo 5

by Tudor Girba

Hi, Thanks for the report. PetitParser was not yet released for Pharo 5. It comes in the following days as part of the Moose release. Cheers, Doru > On Aug 4, 2016, at 7:18 AM, Martin McClure <martin(a)hand2mouse.com> wrote: > > Loading PetitGui with this expression: > > --- > Metacello new > configuration: 'PetitParser'; > version: #'stable'; > repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/'; > load: 'PetitGui'. > --- > > loads, but any attempt to use the PetitParser GUI tool results in deprecation exceptions like this: > > --- > The method GLMCompositePresentation>>smalltalkCode has been deprecated. > Use #pharoMethod (if you need to display a method) > or #pharoScript (if you need to display snippets of code that do not belong to a method) > --- > > It looks like this problem may have been fixed in PetitGui-AndreiChis.156, but the stable configuration loads the earlier PetitGui-StefanReichhart.150. > > Perhaps the stable configuration needs to be updated for Pharo 5? It looks like the latest version of the configuration is still using the same version for Pharo 4 and Pharo 5. > > Regards, > > -Martin > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Aug. 4, 2016

Stable configuration of PetitParser broken for stable PetitGui in Pharo 5

by Martin McClure

Loading PetitGui with this expression: --- Metacello new configuration: 'PetitParser'; version: #'stable'; repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/'; load: 'PetitGui'. --- loads, but any attempt to use the PetitParser GUI tool results in deprecation exceptions like this: --- The method GLMCompositePresentation>>smalltalkCode has been deprecated. Use #pharoMethod (if you need to display a method) or #pharoScript (if you need to display snippets of code that do not belong to a method) --- It looks like this problem may have been fixed in PetitGui-AndreiChis.156, but the stable configuration loads the earlier PetitGui-StefanReichhart.150. Perhaps the stable configuration needs to be updated for Pharo 5? It looks like the latest version of the configuration is still using the same version for Pharo 4 and Pharo 5. Regards, -Martin

Aug. 4, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] f57843: 60163

by Ben Coman

Thanks for the follow up post of this change log Marcus. cheers -ben On Wed, Aug 3, 2016 at 5:23 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 03 Aug 2016, at 11:07, GitHub <noreply(a)github.com> wrote: >> >> >> Log Message: >> ----------- >> 60163 >> 18831 Integrate new Epicea version >> https://pharo.fogbugz.com/f/cases/18831 >> > ChangeLog for this: > > - Case 18813: Implement redo and undo of protocol addition and removal. > > - Case 18612: disable drag&drop until TreeModel supports it correctly. > > - Case 18384: Redo and undo: show on any selection (not only when all selected entries are code changes). > > - Enhancement: Improve lost changes detection; show only the events actually lost. > > - Enhancement: Pass on filters. > > - Clean up: Do not show the "absent entry" item anymore since it was not useful at all. > > - Clean up: Remove unused "commit tags" in log browser. > > - Clean up: Remove unused tests. They were good idea, we can re-introduce them but working and covering more cases. > > - Clean up: Rename #displayWidget to #asMorph in EpLogBrowserItem''s hierarchy. It is more meaningful. > > - Workaround: Hide "Open in Sorter" menu action since it is useless until Treemodel drag&drop is fixed. > > > >> 18768 Inlined method const could be implemented by metalinks >> https://pharo.fogbugz.com/f/cases/18768 >> >> 18835 Update RBParser-Nodes class comments >> https://pharo.fogbugz.com/f/cases/18835 >> >> http://files.pharo.org/image/60/60163.zip >> >> > >

Aug. 4, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by stepharo

> exactlyâ¦ we even have the algorithm implemented for this. > I insist I would enhance ocompletion instead of adding an expansion shortcut. But the rules may not be the same and we will see what lukas will do. and if someone want to hack just that now then we can use it now. Stef > > Esteban > >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 165 Avenue Bretagne >> Lille 59000 France >> > >

Aug. 3, 2016