- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bloc Roadmap

by Sean P. DeNigris

> did you read the class comments? > or Morph and Views Yes. I see that the Morph is delegating it's drawing to a View, but what I'm interested in is the rationale. I believe that documenting the design at a higher level, so everyone can understand the rationale and features, is the only way to keep Bloc clean and lean and prevent another "Morphic is so cool but impossible to understand". Let's take the current example of the introduction of View classes Scenario #1: Design choice because of higher-level vision for Bloc? Right now views are hot-swappable: 1. Make a clock with "clock :=BlPolygonViewExamples exampleSimpleClock." 2. Now turn it into a vintage Bulova with "clock withRectangleView" That is awesome! But is it on-purpose? a documented feature? Those are important so a well-meaning refactorer doesn't come in and smash the design by bloating or removing important capabilities Scenario #2: Views extracted simply because Morphic Morphs were so bloated Morph methodDict size "962" BlMorph methodDict size "473" If #1 is the case, it may be important to preserve the feature, but if it's #2 we may not be as attached to that particular choice. > Decorators are not modularly extensible Bloc use a chain of command. I'm not sure what you mean. Right now, borders are an intrinsic part of BlEnclosedView. If Decorators were used (and I'm not saying they're appropriate, just asking), one could e.g. add multiple borders, or a border and scroll bars, etc. How are Decorators not modularly extensible when used that way? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Roadmap-tp4816171p4816747.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 1, 2015

Re: [Pharo-dev] Brand new modern Spotter design!

by kilon alios

If I understand what you are trying to say, then I don't agree, I prefer tools that work as part of the whole and that includes theming too. But the good news is that out of coincidence it fits my blue theme and I also love GTSpotter :) â On Wed, Apr 1, 2015 at 2:56 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I am saying that the current look is universally applicable and should be > used as is without alteration for all eternity :). > > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > On 01 Apr 2015, at 13:22, kilon alios <kilon.alios(a)gmail.com> wrote: > > can you explain a bit more what you mean ? are you referring to the pharo > central theme or GTSpotter theme ? > > It will be a huge pain for users to set a separate theme for each tool > inside pharo. > > On Wed, Apr 1, 2015 at 2:19 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> But we think that complementary universal colors work best in this >> context. >> >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> > On 01 Apr 2015, at 13:07, kilon alios <kilon.alios(a)gmail.com> wrote: >> > >> > >> > My opinion : >> > >> > Even when a tool has its own theme support should still support and >> respect the central theme. >> >> >

April 1, 2015

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

by Ben Coman

On Wed, Apr 1, 2015 at 12:34 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > Cyril Ferlicot <cyril.ferlicot(a)gmail.com> writes: > > > On 31 March 2015 at 17:22, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > > > >> Ben Coman <btc(a)openinworld.com> writes: > >> > >> > Regarding Windows... Last that I looked, the PharoLauncher image is > >> > installed into the "Program Files" System Folder. This causes a > problem > >> > since when a PharoLauncher Image is saved by a Standard User, they > cannot > >> > write to the System Folder so Windows *fakes* it and actually writes > to a > >> > User Fodler, but makes it look like the file is in the System Folder. > >> That > >> > is, the Standard User is looking at a Fake System Folder!! > >> > >> that's very strange. Can someone please evaluate this expression on your > >> Windows box and give us the result? > >> > >> PlatformResolver forCurrentPlatform cache > > > File @ C:\Users\Cyril\AddData\Roaming > > > looks good to me. So, I don't understand Ben's problem. > > > > >> > This confused me for quite a while - even as an IT Administrator of 15 > >> > years. Its likely to cause chaos and pain for others down the track. > So > >> I > >> > recommend that the installer be changed so that the PharoLauncher > Image > >> is > >> > installed into a User Folder - at least by default, and maybe as the > only > >> > option. > >> > >> > >> I disagree. The launcher should be installed with other applications. > >> But the data is per-user. On Ubuntu, the launcher is happily installed > >> under /usr/share/pharo-launcher and images are download to > >> ~/.cache/Pharo/images. > The location of the downloaded images is fine. It is the location of PharoLauncher's own image that is the problem on windows if the user happens to save the Image. Try the following on Windows 7+... 1. Install pharo_installer-0.x.x.exe as administrator. 2. Run Pharolauncher as a standard user. 3. Change to development mode, open Playground and type a note to yourself like "This should not show after a reinstall". Quit Pharolauncher and restart to check it still appears, and quit again. 4. Re-install pharo_installer-0.x.x.exe as administrator (like you might when a newer version is available) 5. Run Pharolauncher as a standard user. You would expect a fresh image - one that doesn't show the note to yourself, but I had found (a while ago) that the note still shows, indicating the upgrade effectively failed. That is a "typical" workflow in a corporate environment, which I expect Pharo would like to target. So when you: * run PharoLauncher as administrator and get the new Pharolauncher, but * run PharoLauncher as a standard user and get the old Pharolauncher you may rightfully ask wtf ?!? What do you observe? cheers -ben >> > >> > I had meant to fix this in PharoLauncher myself, and also would offer > to > >> > test it - but unfortunately I currently don't have access to a Windows > >> > machine. > >> > >> I hope someone else will try > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> "Success is the ability to go from one failure to another without > >> losing enthusiasm." --Winston Churchill > >> > >> > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

April 1, 2015

Re: [Pharo-dev] Bloc Roadmap

by stepharo

did you read the class comments? or Morph and Views Decorators are not modularly extensible Bloc use a chain of command. Much better Le 30/3/15 19:41, Sean P. DeNigris a Ã©crit : > I created a page at > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/BlocRoad… > > I started with some questions and my basic understanding after a few > experiments > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc-Roadmap-tp4816171.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 1, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by stepharo

Thanks ben Several rmoder are busy with paper deadline for this evening. ... Stef Le 1/4/15 18:56, Ben Coman a Ã©crit : > Issue 14606 [1] is tagged "Really Important" where evaluating.... > > | t1 t2 t3 t4 t5 t6 | > t1 := 1. > t2 := 2. > t3 := 3. > t4 := 4. > t5 := 5 . > t6 := 6. > [ t5 := 50. > t6 := 60. > t3 + t4. > 1 halt. > ] value > > => can't see the value of t4, t5, t6. > > I've just submitted a possible solution for this, but its a bit late > before release for such a change - so I'm asking for "all hands in" to > help stress test it. You don't need to review code, just please merge > latest slice 14606 into your normal working image and report your > experience. > > cheers -ben > > [1] https://pharo.fogbugz.com/default.asp?14606#124466 >

April 1, 2015

14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

Issue 14606 [1] is tagged "Really Important" where evaluating.... | t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value => can't see the value of t4, t5, t6. I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience. cheers -ben [1] https://pharo.fogbugz.com/default.asp?14606#124466

April 1, 2015

Re: [Pharo-dev] Brand new modern Spotter design!

by stepharo

Le 1/4/15 16:57, Torsten Bergmann a Ã©crit : > Returning to the childish look of Squeak? > Acceptable as an april fool... indeed http://artsytime.com/img/fun/girlish-transformer/girlish-transformer05.jpg

April 1, 2015

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

by Sean P. DeNigris

> You might want to rename it to something more > mac-ish because there will be other md5sum files for other platforms. I thought I set it to be named latest.dmg.md5sum. I figured the dmg would make it self-explanatory and mirror the main artifact name. Do you disagree? ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Pharo-Launcher-package-for-Mac-and-Windows-tp4815… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 1, 2015

Re: [Pharo-dev] Moose 5.1 on Pharo-4, .0 (was: Brand new modern Spotter design!)

by Andrei Chis

This is a problem we are having with icons: a lot of them do not work any more but are used in various themes. https://pharo.fogbugz.com/f/cases/15277/some-icons-from-ThemeIcons-are-brok… Cheers, Andrei On Wed, Apr 1, 2015 at 6:01 PM, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > Hi, > > I have downloaded the latest moose-5.1 build (from jenkins) in order to > have a look for the latest gt tools. > There seem to be a problem with moose on Pharo-4.0 for some time now: > If I try to open a menu (I don't know its name; its opened by clicking the > little triangle in the top right corner) > from within the tools (all tools I tested, like Nautilus, Playground, > debugger) I'll get a short menu with the first > menu entry "Why you see this menu". Hitting "Debug" reveals that there is > a MNU in SmallInteger>>asciiVal. > > Regards > Andreas > > > >

April 1, 2015

Re: [Pharo-dev] Moose 5.1 on Pharo-4, .0

by Andreas Wacknitz

Am 01.04.15 um 18:01 schrieb Andreas Wacknitz: > Hi, > > I have downloaded the latest moose-5.1 build (from jenkins) in order > to have a look for the latest gt tools. > There seem to be a problem with moose on Pharo-4.0 for some time now: > If I try to open a menu (I don't know its name; its opened by clicking > the little triangle in the top right corner) > from within the tools (all tools I tested, like Nautilus, Playground, > debugger) I'll get a short menu with the first > menu entry "Why you see this menu". Hitting "Debug" reveals that there > is a MNU in SmallInteger>>asciiVal. Sent to early: it's SmallInteger>>asciiValue. > > Regards > Andreas > > >

April 1, 2015