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

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

by phil＠highoctane.be

This whole theming story is not nice. One good thing about Pharo is that one can make the environment one's own. But most of the time, this starts with the colors, and one hits a brick wall. I just can't help thinking about pieces of software like WinAmp where one could do theming easily, adding plugins with ease etc. A lot of editors these days do it all with CSS and similar tech, blowing us out of the water on that front. Generally speaking, with the new Pharo (like 4.x, 5,x, 6,x), I face a more difficult system to get into (despite all the cool things Spotter allows). Somedays, I am wondering if we aren't actively keeping people out. Phil On Mon, 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 > > >

Aug. 1, 2016

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

by Julien Delplanque

Your new theme looks nice, congratulation! I will probably switch from the dark theme to this one once it will be available. :-) Julien On 01/08/16 11:13, Esteban Lorenzano 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 > >

Aug. 1, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 1, 2016

[pharo-project/pharo-core] 8b93b4: 60159

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 8b93b4841c18b83abda46d511b4c50d5d75c4f54 https://github.com/pharo-project/pharo-core/commit/8b93b4841c18b83abda46d51… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-01 (Mon, 01 Aug 2016) Changed paths: R Collections-Abstract.package/extension/String/instance/join_.st A Collections-Strings.package/String.class/instance/splitjoin/join_.st A Graphics-Tests.package/MarginTest.class/README.md A Graphics-Tests.package/MarginTest.class/definition.st A Graphics-Tests.package/MarginTest.class/instance/tests/testConstruction.st A Graphics-Tests.package/MarginTest.class/instance/tests/testExpandRectangle.st A Graphics-Tests.package/MarginTest.class/instance/tests/testExtendRectangle.st A Graphics-Tests.package/MarginTest.class/instance/tests/testFromPoint.st A Graphics-Tests.package/MarginTest.class/instance/tests/testInitialization.st A Graphics-Tests.package/MarginTest.class/instance/tests/testInsetRectangle.st M Kernel.package/Margin.class/instance/accessing/height.st R Kernel.package/Margin.class/instance/accessing/rightBottom.st M Kernel.package/Margin.class/instance/accessing/width.st M Kernel.package/Margin.class/instance/initialization/fromNumber_.st M Kernel.package/Margin.class/instance/initialization/fromPoint_.st M Kernel.package/Margin.class/instance/initialization/fromRectangle_.st M Kernel.package/Margin.class/instance/initialization/initialize.st M Kernel.package/Margin.class/instance/operations/expandRectangle_.st M Kernel.package/Margin.class/instance/operations/extendRectangle_.st M Kernel.package/Margin.class/instance/operations/insetRectangle_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60158.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60159.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60158.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60159.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/CheckBoxModel.class/definition.st M Spec-Core.package/RadioButtonModel.class/definition.st M Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/factory/buildWidget.st A Spec-Tests.package/IconListModelTest.class/README.md A Spec-Tests.package/IconListModelTest.class/definition.st A Spec-Tests.package/IconListModelTest.class/instance/running/classToTest.st A Spec-Tests.package/IconListModelTest.class/instance/tests/testGetIconFor.st M Spec-Tests.package/ListModelTest.class/definition.st A Spec-Tests.package/ListModelTest.class/instance/running/classToTest.st M Spec-Tests.package/ListModelTest.class/instance/tests/testSelectAll.st M Spec-Tests.package/ListModelTest.class/instance/tests/testWhenListChanged.st M Spec-Tests.package/ListModelTest.class/instance/tests/testWhenListChangedOldContents.st A Spec-Tests.package/RadioButtonModelTest.class/README.md A Spec-Tests.package/RadioButtonModelTest.class/definition.st A Spec-Tests.package/RadioButtonModelTest.class/instance/running/classToTest.st A Spec-Tests.package/RadioButtonModelTest.class/instance/tests/testCanDeselectByClick.st A Spec-Tests.package/RadioButtonModelTest.class/instance/tests/testToggleState.st A Spec-Tests.package/SliderModelTest.class/README.md A Spec-Tests.package/SliderModelTest.class/definition.st A Spec-Tests.package/SliderModelTest.class/instance/running/classToTest.st A Spec-Tests.package/SliderModelTest.class/instance/running/initMinMax.st A Spec-Tests.package/SliderModelTest.class/instance/tests/testAbsoluteValue.st A Spec-Tests.package/SliderModelTest.class/instance/tests/testReset.st A Spec-Tests.package/TextModelTest.class/README.md A Spec-Tests.package/TextModelTest.class/definition.st A Spec-Tests.package/TextModelTest.class/instance/running/classToTest.st A Spec-Tests.package/TextModelTest.class/instance/running/initText.st A Spec-Tests.package/TextModelTest.class/instance/tests/testSelectAll.st Log Message: ----------- 60159 18844 Move String>>#join: to correct protocol https://pharo.fogbugz.com/f/cases/18844 18838 ScrollSyncExample seems dont really work https://pharo.fogbugz.com/f/cases/18838 18769 Add test for Spec-Core-Widgets https://pharo.fogbugz.com/f/cases/18769 18841 Margin improvements https://pharo.fogbugz.com/f/cases/18841 http://files.pharo.org/image/60/60159.zip

Aug. 1, 2016

let's talk about themes (and GLMBrickThemer)

by Esteban Lorenzano

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

Aug. 1, 2016

Re: [Pharo-dev] Status of SmallPOS

by stepharo

Hi yuriy I know that lionel Akue is interested in library to support little business. So if you open-source your code under MIT it is the best for everybody. Stef Le 30/7/16 Ã 19:16, Yuriy Mironenko a Ã©crit : > Sorry for answering the "deadly long forgotten" post, but, anyway: it happens > at the moment of migration to ss3, I believe. I don't really remember actual > "relicensing" process, I think it was just...welll...selecting from the > drop-down list, and this time I selected another option. > > If you or somebody else will ever need SmallPOS under any other open > license, I will be glad to deliver it under this license. > > > > -- > View this message in context: http://forum.world.st/Status-of-SmallPOS-tp4649796p4908797.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 1, 2016