- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Aug. 28, 2015

[pharo-project/pharo-core] 014fad: 50283

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 014fad6f38d6a0269a8b56f45c59283abbc932d0 https://github.com/pharo-project/pharo-core/commit/014fad6f38d6a0269a8b56f4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-28 (Fri, 28 Aug 2015) Changed paths: M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showHierarchy_.st A NautilusRefactoring.package/CodeSearchingRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBExplicitRequirementMethodsRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBRemoveAssignmentWithoutEffectRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBRuleIfNotEmptyDo.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBRuleIfNotNilDo.class/class/accessing/uniqueIdentifierName.st M Refactoring-Critics.package/RBSmalltalkGlobalsRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Critics.package/RBUnaryAccessingMethodWithoutReturnRule.class/class/accessing/uniqueIdentifierName.st M Refactoring-Critics.package/RBkeysDoRule.class/class/accessing/uniqueIdentifierName.st A Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/test unique identifier/testUniqueIdentifierName.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50282.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50283.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50282.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50283.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Diff.package/DiffMorph.class/instance/actions/calibrateScrollbar.st M Tool-Diff.package/DiffMorph.class/instance/event handling/verticalScroll_.st Log Message: ----------- 50283 16391 Switching hierarchy visually removes selection of a protocol https://pharo.fogbugz.com/f/cases/16391 16331 MergeDiffMorph - Wrong scrollbars https://pharo.fogbugz.com/f/cases/16331 16406 RBkeysDoRule has the same #uniqueIdentifierName as RBEqualNilRule https://pharo.fogbugz.com/f/cases/16406 http://files.pharo.org/image/50/50283.zip

Aug. 28, 2015

Re: [Pharo-dev] [squeak-dev] #instSize in Squeak 5 seems to be broken for Traits

by Max Leske

> On 28 Aug 2015, at 02:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > fixed in Squeak via a preamble in a new version of Traits. I must remember to fix this in the bootstrap so that it doesn't afflict Pharo Spur. Great, thanks! > > On Sun, Aug 23, 2015 at 4:34 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 22 Aug 2015, at 19:21, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> On Fri, Aug 21, 2015 at 2:11 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> On 21 Aug 2015, at 19:31, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> >>> Hi Max, >>> >>> On Fri, Aug 21, 2015 at 8:57 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> Hi folks >>> >>> Iâve been trying to load Fuel into Squeak 5 but canât because I get errors when loading Traits (they have not instance variables). The reason for this error seems to be that #instSize answers 2 for Traits when it should answer 0. >>> >>> The current implementation is: >>> >>> ^format bitAnd: 16rFFFF >>> >>> The comment in the 4.6 version says: >>> >>> " >>> NOTE: This code supports the backward-compatible extension to 8 bits of instSize. >>> When we revise the image format, it should become... >>> ^ ((format bitShift: -1) bitAnd: 16rFF) - 1 >>> Note also that every other method in this category will require >>> 2 bits more of right shift after the change. >>> â >>> >>> When I use that version in TraitBehaviour>>instSize in Squeak 5 I get 0 as expected and I can load Fuel without problems. >>> >>> So Spur has a different layout for format than V3. The above implementation (format bitAnd: 16rFFFF) is correct for Spur. In loading classes or traits via Fuel from 4.6 to 5.0 you're going to have to convert the format inst var to reflect its usage in Spur. So we need to be clear here. >>> >>> Is the issue that you're trying to load classes and/or traits from a Fuel file written by 4.6 or is it that as part of the Fuel load a new Trait gets created which has a format of 2? >> >> The latter. This is reproducible by simply creating a new Trait: >> >> Trait named: #NewTrait >> uses: #() >> category: ânew catâ. >> NewTrait instSize ââ> 2â >> >> I just took a look at this and it doesn't reproduce. I'm using a trunk Squeak 5 image and I get 0 and required. ? > > Thanks Eliot. Youâre right. The problem is not with #instSize, I donât know how I managed to get the aboveâ¦ > > The problem is actually, that TApplyingOnClassSide (which is already present) has a format of 2: > > TApplyingOnClassSide instSize ââ> 2â > > > Also, all Traits in the image have format 2, while new Traits have format 0: > > format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. > Smalltalk allTraits size = format2 size ââ> true" > > Trait named: #NewTrait > uses: #() > category: 'new catâ. > > NewTrait instSize ââ> 0" > format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. > Smalltalk allTraits size = format2 size ââ> falseâ > > > This is with build 15113 (which is trunk I suppose). > > Cheers, > Max > >> >> Cheers, >> Max >> >>> >>> >>> Cheers, >>> Max >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 28, 2015

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

by Ben Coman

On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self(a)je77.com> wrote: > On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc(a)openinworld.com> wrote: >> >> So morphic has a Z-order but I think not a Z-depth. Is that be >> something we should be aiming for? > > > In HTML5, Z-depth is pretty exclusively used as a mechanism to determine > Z-order in the HTML / CSS separation. Normally, the order of HTML determines > the Z-order. But, Z-order is really a style thing, rather than a composition > thing. So, specifying the Z-depth allows you to override standard behavior > in the style sheet. This is not necessary in a true object-based GUI where > graphical objects are more self contained and can easily determine their own > Z-order. > > I doubt we will see general purpose adoption of any 2D interface that will > rely on Z-depth for anything besides determining Z-order. For instance, the > example of shadow size seems interesting but runs into usability problems > quickly. Let's say that you have element A with a larger shadow to indicate > that it is above element B with a smaller shadow. That seems great. What > happens if element B is selected and brought to the forefront? Does A's > shadow go down in size? If so, that breaks the normal shadow analogy. If > not, it would seem that the shadows would just keep growing bigger each time > a new element is brought to the front. For limited general-purpose > applications (e.g., a larger shadow for an object currently being dragged), > you don't need Z-depth info. For specialized applications where a Z-depth > might make sense (I can't even think of one), there's little problem adding > such functionality to custom widgets. So, my recommendations is to stay away > from trying to implement Z-depth as a fundamental component of a 2D > interface. The benefit is minimal and largely theoretical. > > Cheers, > > Jeff Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben

Aug. 28, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Dimitris Chloupis

impressive work and it looks very nice indeed , great work guys :) On Thu, Aug 27, 2015 at 11:01 PM Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > We prepared a working image with Brick preview :) Just open it with the > latest Pharo VM and you will instantly see an example browser > â > Pharo-Brick.zip > <https://drive.google.com/file/d/0B-bMBVDOi3oTdll3dGJValVIenc/view?usp=drive…> > â > > Cheers, > Alex > > On Tue, Aug 25, 2015 at 10:13 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi, >> >> We are happy to announce the first preview version of Brick, a new widget >> set created from scratch on top of Bloc. >> >> Brick is being developed primarily by Alex Syrel (together with Alain >> Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick >> is part of the Glamorous Toolkit effort and will provide the basis for the >> new versions of the development tools. >> >> Brick's goal is to provide a beautiful looking widget set, and the >> default look is based on material design. The widgets are theme-able. >> >> Right now, there exists: >> - Label >> - Simple button >> - Toggle button >> - Checkbox >> - Radio button >> - Window with or without an active title bar that can include various >> visual actions and info >> - Menu >> - Beautiful scrollbars that are thin by default and enlarge when the >> mouse hovers over it >> - Scalable list for huge amounts of items with various heights >> (The list also allows one for embedding text widgets with in place >> editing) >> >> The next immediate target is the creation of a new Pager widget (the >> widget that is behind the current GTInspector). >> >> You can see some screenshots on the official site: >> http://gt.moosetechnology.org/brick >> >> To play with it, you can download a ready-made image: >> >> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… >> >> and, in a Bloc space, you can browse the examples: >> BrExampleBrowser exampleOpen >> >> We would be happy to hear your feedback. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Aug. 28, 2015

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

by J.F. Rick

On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc(a)openinworld.com> wrote: > So morphic has a Z-order but I think not a Z-depth. Is that be > something we should be aiming for? > In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order. I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical. Cheers, Jeff

Aug. 28, 2015

Re: [Pharo-dev] [squeak-dev] #instSize in Squeak 5 seems to be broken for Traits

by Eliot Miranda

Hi Max, fixed in Squeak via a preamble in a new version of Traits. I must remember to fix this in the bootstrap so that it doesn't afflict Pharo Spur. On Sun, Aug 23, 2015 at 4:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 22 Aug 2015, at 19:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Fri, Aug 21, 2015 at 2:11 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 21 Aug 2015, at 19:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Max, >> >> On Fri, Aug 21, 2015 at 8:57 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Hi folks >>> >>> Iâve been trying to load Fuel into Squeak 5 but canât because I get >>> errors when loading Traits (they have not instance variables). The reason >>> for this error seems to be that #instSize answers 2 for Traits when it >>> should answer 0. >>> >>> The current implementation is: >>> >>> ^format bitAnd: 16rFFFF >>> >>> The comment in the 4.6 version says: >>> >>> " >>> NOTE: This code supports the backward-compatible extension to 8 >>> bits of instSize. >>> When we revise the image format, it should become... >>> ^ ((format bitShift: -1) bitAnd: 16rFF) - 1 >>> Note also that every other method in this category will require >>> 2 bits more of right shift after the change. >>> â >>> >>> When I use that version in TraitBehaviour>>instSize in Squeak 5 I get 0 >>> as expected and I can load Fuel without problems. >>> >> >> So Spur has a different layout for format than V3. The above >> implementation (format bitAnd: 16rFFFF) is correct for Spur. In loading >> classes or traits via Fuel from 4.6 to 5.0 you're going to have to convert >> the format inst var to reflect its usage in Spur. So we need to be clear >> here. >> >> Is the issue that you're trying to load classes and/or traits from a Fuel >> file written by 4.6 or is it that as part of the Fuel load a new Trait gets >> created which has a format of 2? >> >> >> The latter. This is reproducible by simply creating a new Trait: >> >> Trait named: #NewTrait >> uses: #() >> category: ânew catâ. >> NewTrait instSize ââ> 2â >> > > I just took a look at this and it doesn't reproduce. I'm using a trunk > Squeak 5 image and I get 0 and required. ? > > > Thanks Eliot. Youâre right. The problem is not with #instSize, I donât > know how I managed to get the aboveâ¦ > > The problem is actually, that TApplyingOnClassSide (which is already > present) has a format of 2: > > TApplyingOnClassSide instSize ââ> 2â > > > Also, all Traits in the image have format 2, while new Traits have format > 0: > > format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. > Smalltalk allTraits size = format2 size ââ> true" > > Trait named: #NewTrait > uses: #() > category: 'new catâ. > > NewTrait instSize ââ> 0" > format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. > Smalltalk allTraits size = format2 size ââ> falseâ > > > This is with build 15113 (which is trunk I suppose). > > Cheers, > Max > > > Cheers, >> Max >> >> >> >>> Cheers, >>> Max >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 28, 2015

Re: [Pharo-dev] [Moose-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Alexandre Bergel

Works well! Splendide! Cheers, Alexandre > On Aug 27, 2015, at 5:00 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi, > > We prepared a working image with Brick preview :) Just open it with the latest Pharo VM and you will instantly see an example browser > â > Pharo-Brick.zip > â > > Cheers, > Alex > > On Tue, Aug 25, 2015 at 10:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 27, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Aliaksei Syrel

Hi, We prepared a working image with Brick preview :) Just open it with the latest Pharo VM and you will instantly see an example browser â Pharo-Brick.zip <https://drive.google.com/file/d/0B-bMBVDOi3oTdll3dGJValVIenc/view?usp=drive…> â Cheers, Alex On Tue, Aug 25, 2015 at 10:13 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We are happy to announce the first preview version of Brick, a new widget > set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain > Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick > is part of the Glamorous Toolkit effort and will provide the basis for the > new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default > look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various > visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse > hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the > widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 27, 2015

Re: [Pharo-dev] [ANN] Multiple Desktop support for Pharo 5

by Julien Delplanque

When changing the desktop, windows opened before where not clickable anymore like if they where a part of the "wallpaper". Julien On 27/08/15 18:52, H. Hirzel wrote: > Julien, > > could you please describe the problem you had in Pharo 4.0 with more details? > > --Hannes > > On 8/27/15, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> On 27/08/15 11:42, H. Hirzel wrote: >>> On 8/27/15, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> Hi Julien, >>>> >>>> sorry for "hijacking" the topic. But I got some time left while >>>> traveling >>>> allowing me to put my recommended puzzle pieces together myself and as I >>>> wrote the code was less time consuming compared to the article. The >>>> article >>>> >>>> should help others to investigate in the goodies code and learn how to >>>> do >>>> own >>>> inspector extensions, spotter models, ... in recent Pharo now. If there >>>> is >>>> something wrong with the implementation feel free to send me >>>> comments/corrections. >>>> >>>> Also note that the project on STHub is open for commits, so if you find >>>> something >>>> missing please add it. I would like to keep the "multiple desktops" >>>> metaphor >>>> instead of "multiple worlds" as it better fits what people know and >>>> expect. >>> +1 >>> >>>> Additional info: >>>> ================ >>>> Meanwhile the job run that checks the configurations for the Catalog >>>> Browser. >>>> So in a fresh and updated Pharo 5 image you can just: >>>> >>>> - hit SHIFT + ENTER to open the default Spotter >>>> - enter "DesktopManager" as a search term to find the project >>>> automagically >>>> - hit enter to load it >>>> >>>> So there is no need to rember cumbersome Gofer scripts anymore. Just >>>> type >>>> and go. >>>> >>>> After loading you can use the tool as written before: >>>> >>>> - check the world menu "Desktop" >>>> - you can press CTRL + D and then CTRL + A (= Desktop Add) to add a >>>> new >>>> desktop >>>> - you can press CTRL + D and then CTRL + D (= Desktop Desktop) to open >>>> the >>>> overview (custom spotter for desktop selection) >>>> - you can press CTRL + D and then CTRL + P (= Desktop Previous) to >>>> navigate >>>> to the previous desktop >>>> - you can press CTRL + D and then CTRL + N (= Desktop Next) to navigate >>>> to >>>> the next desktop >>>> >>>> You can also use the world menu (see another screenshot attached). >>>> >>>> Hope it will become useful to others as well. We should have cared >>>> already >>>> back in 2010/2011 when >>>> Jochen and Sean raised the issue. On the other side with the nice >>>> moldable >>>> GT tools introduced now >>>> in Pharo 4/5 it was really easy to implement. >>> Does this mean that it is available in Pharo 4 as well? >>> >>> >> I tried it on pharo 4 and it doesn't works, it has the same problem as >> the one I had when implementing my version. >> >> Julien >>

Aug. 27, 2015