- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by kilon alios

hmm my mistake, I must have mixed something up I can see now my progress bar On Tue, Sep 9, 2014 at 12:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > I can see your changes in the pharolauncher build 891 > > "Pharo Contribution Jenkins-PharoLauncher-#891" > > PharoLauncher-Core: > > Name: PharoLauncher-Core-kilonAlios.62 > Author: kilonAlios > Time: 8 September 2014, 3:09:22.87321 pm > UUID: 368940aa-996d-e34a-989c-63c618316b37 > Ancestors: PharoLauncher-Core-TimMackinnon.61 > > > > > > > 2014-09-09 10:15 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> revise away, downloading in the background sounds very cool. I also have >> some more contributions to make. >> >> By the way my commit was successful >> >> >> http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher/diff/PharoLauncher-Core… >> >> The build was succesful >> >> >> https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… >> >> but when I downloaded the new PharoLauncher image to my surprise the code >> was nowhere to be found. Its strange because the log says it loads the >> bleeding edge of PharoLauncher so that means it should pull in my change ? >> Am I correct ? Any idea what is wrong here ? >> >> On Mon, Sep 8, 2014 at 3:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> kilon alios wrote: >>> >>> It should not be a problem because it affects only the PharoLauncher image >>> and not the images you download with PharoLauncher so the old progress bar >>> will remain in those images. >>> >>> Its personal taste of course but let remember here that a common complain >>> about smalltalk is that it looks weird and for some people ugly. How many >>> progress bars you have seen up left ? What advantage is there for a >>> progress bar to be up left ? >>> >>> Also because when performing such jobs pharo freezes and does not allow for >>> further interactions with the user until the job ends it makes more sense >>> for the progress bar to be in the middle , bigger size so its very visible >>> even from distance if the user decides to leave the screen to grab some >>> coffee or fight with his light saber and if possible even display a "Please >>> wait..." message so the user / beginner Pharoers knows this is not a bug or >>> he /she did not brake Pharo. >>> >>> >>> >>> Thats cool, but I may revise it later if I actually get around to making >>> PharoLauncher download images in the background. A few other things on my >>> plate to clear first. >>> cheers -ben >>> >>> >>> I am not saying Pharo should be an exact copy of the GUIs out there but at >>> least we should respect the user habits and broke those habits only if it >>> is necessary. Or else you will have more and more people looking at the >>> GUI and going "Eeeewwww". >>> >>> On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> <sven(a)stfx.eu> wrote: >>> >>> >>> >>> Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other >>> words, there are preferences for the location of the progress bar, these >>> should probably be honoured. A big or a small bar also depends a bit on >>> taste I would say. >>> >>> On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> wrote: >>> >>> >>> >>> ok with a bit of help I was able to figure things out, it turns out that >>> >>> >>> it was simple to do difficult to understand :D so here is my answer >>> >>> >>> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >>> >>> I also attached the new progress bar i customised and the old for >>> >>> >>> comparison as attached images >>> >>> >>> <newProgressBar.JPG> >>> >>> <oldProgressBar.JPG> >>> â >>> Personally I would make my code the default Progress Bar for entire >>> >>> >>> Pharo including all operations because its annoying to be that small and up >>> there. This should work well even if there are multiple Progress Bars >>> displayed. But for not its PharoLauncher only progress bar. >>> >>> >>> How I add this code to PharoLauncher ? do I use just the development >>> >>> >>> mode of PharoLauncher and Commit ? I dont want to mess anything up. >>> >>> >>> Next step would be to add an info box for each image so people know what >>> >>> >>> they download before downloading it. >>> >>> >>> On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> >>> >>> wrote: >>> >>> >>> yeah yeah I see it now, there actually many announcers (3 of them ) all >>> >>> >>> seem to signal SystemProgressMorph , oh boy this will be a tricky one . >>> Thanks for the pointer, now I have to find how to capture the instance of >>> that SystemProgressMorph. If I find the instance sending a width: message >>> should do the trick. Looks like I will need to investigate further but at >>> least you are pointed me to the right direction so I no longer feel lost in >>> space. >>> >>> >>> On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < >>> >>> >>> thierry.goubier(a)gmail.com> wrote: >>> >>> >>> Le 07/09/2014 11:53, kilon alios a Ã©crit : >>> >>> Hello pharoers it has been almost a year since the last time I commited >>> >>> >>> to PharoLauncher so I decided to go for it once again. The first time I >>> added a progress bar for people to see the progress of the download of the >>> image . Now I want to scale and reposition the progress bar as I am not >>> happy at all in the way it looks , its too small and hard to read. >>> >>> >>> So I created a question at stackoverflow with all the details of my >>> >>> >>> problem >>> >>> >>> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >>> >>> I would not mind also some extra details on how I can fetch the Morphs >>> >>> >>> used by UIManager or to even further customise UIManager. I tried to find >>> the answer myself but after an hour of staring at the Pharo system browser >>> I gave up. >>> >>> >>> Hi Kilon, >>> >>> I don't have a stackoverflow account, so here is what I found. >>> >>> From displayProgress: , asJob brings you to Job, which has no morph at >>> >>> >>> all. But, on the class side of Job, you have a job announcer (instance >>> class variable jobAnnouncer). Inspect that variable, search among the >>> subscriptions of the announcer, and you'll find SystemProgressMorph. >>> >>> >>> A good use case of a fairly good design which is a lot harder to unravel >>> >>> >>> than it should be, due to the lack of tools to explore announcer / >>> subscription relations. >>> >>> >>> Thierry >>> >>> >>> >>> >>> >>> >>> >> >

Sept. 9, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 9, 2014

[pharo-project/pharo-core] b8f125: 40215

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b8f1253e51bede13b294f6b1c6c90df2b43161e8 https://github.com/pharo-project/pharo-core/commit/b8f1253e51bede13b294f6b1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-09 (Tue, 09 Sep 2014) Changed paths: M Monticello.package/MCFileBasedRepository.class/instance/accessing/readableFileNames.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script215.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40215.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40215 13421 Problem in Monticello and the cached packages https://pharo.fogbugz.com/f/cases/13421 http://files.pharo.org/image/40/40215.zip

Sept. 9, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by Nicolai Hess

fogbugz entry for fixing the menu builder 13979 <https://pharo.fogbugz.com/default.asp?13979> PragmaMenuBuilder relies on modifying a collection while iterating over it. 2014-09-03 22:59 GMT+02:00 stepharo <stepharo(a)free.fr>: > Clement we should fix the code of the menu :) > > Stef > > > On 3/9/14 15:25, ClÃ©ment Bera wrote: > > Hello, > > Sven you are right, the old compiler was consistent in the sense that it > always iterated over all the elements, including the ones added with #add: > and #addLast: while iterating over the collection. > On the other hand, VW is consistent with the Opal implementation for > #to:do: in the sense that they iterate only on the elements of the > collection excluding the ones added while iterating. > > #add:after: and co do not work well if you edit the collection while > iterating over it for sure :). > > It's too late for "don't modify a collection while iterating it" because > the system does it, for example, to build the world menu. So I think the > solution is in two steps: > - removing code which edit the collection while iterating over it. As most > frameworks work both on Pharo and VW and that the behavior is different I > think there shouldn't be that much, so fixing the Pharo image may be enough. > - be consistent in our collection protocol, basically by rewriting do: and > reverseDo: like that: > > FROM: > do: aBlock > "Override the superclass for performance reasons." > | index | > index := firstIndex. > [index <= lastIndex] > whileTrue: > [aBlock value: (array at: index). > index := index + 1] > TO: > do: aBlock > "Override the superclass for performance reasons." > firstIndex to: lastIndex do: [ :index | > aBlock value: (array at: index) ] > > > > > > 2014-09-03 14:05 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > >> >> On 3 sept. 2014, at 11:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > Hello guys, >> > >> > I was looking into the OrderedCollection protocols recently to see how >> well the sista optimizer perform with it methods, and I realized that this >> is completely broken. >> > >> > For example: >> > >> > col := #(1 2 3 4 5) asOrderedCollection. >> > col do: [ :elem | elem trace . >> > elem < 4 ifTrue: [ col add: col size + 1 ]]. >> > >> > => '12345678' >> > >> > However: >> > >> > col := #(1 2 3 4 5) asOrderedCollection. >> > col collect: [ :elem | elem trace . >> > elem < 4 ifTrue: [ col add: col size + 1 ]]. >> > >> > => '12345' >> > >> > This means that #do: and #reverseDo: iterate over all the elements of >> the collection,*including* the ones that you are adding while iterating >> over the collection, whereas all the other OrderedCollection protocols, >> such as #collect:, #select:, iterates over all the elements of the >> collection, *excluding* the ones you are adding while iterating over the >> collection. >> > >> > Marcus argued that one should not edit a collection while iterating >> over it, however this point is not valid as the World menu relies on this >> feature, using #do: to iterate over the elements of the OrderedCollection >> including the one it is adding while iterating over the collection. >> Changing the implementation makes the world menu display half of its items. >> > >> > I don't like this difference because it is inconsistent. For example, >> refactoring a #do: into a #collect: can simply not work because they do not >> iterate over the same elements if you are editing the collection while >> iterating over it. >> > >> > In VW, the protocols are consistent and iterating over a collection >> never iterates over the elements one is adding while iterating over it. >> Therefore, I believe most frameworks should expect this behavior (at least >> the ones cross smalltalk) which sounds the most correct. >> > >> > I think we should fix the world menu implementation and make the >> protocols consistent. Alternatively, we can let VW be a much more >> consistent Smalltalk environment than Pharo. What do you think ? >> >> >> The thing is to find alternative implementations that are efficient >> enough (no copy). Maybe we can get some inspirations from VW for that (how >> do they do BTW?). >> You should also check with other kinds of collection because they may act >> differently than OrderedCollection. >> So in the end it depends on the amount of effort needed to make all >> collections consistent with this new requirement and on the resulting >> overhead. >> If it's too much, I think that following the old advice "don't modify a >> collection while iterating it" is enough. If one really needs to do such >> kind of things he should consider an alternative design like using a zipper >> for example. >> >> Camille >> >> > >> > Clement >> > >> >> >> > >

Sept. 9, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by Nicolai Hess

I can see your changes in the pharolauncher build 891 "Pharo Contribution Jenkins-PharoLauncher-#891" PharoLauncher-Core: Name: PharoLauncher-Core-kilonAlios.62 Author: kilonAlios Time: 8 September 2014, 3:09:22.87321 pm UUID: 368940aa-996d-e34a-989c-63c618316b37 Ancestors: PharoLauncher-Core-TimMackinnon.61 2014-09-09 10:15 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > revise away, downloading in the background sounds very cool. I also have > some more contributions to make. > > By the way my commit was successful > > > http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher/diff/PharoLauncher-Core… > > The build was succesful > > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… > > but when I downloaded the new PharoLauncher image to my surprise the code > was nowhere to be found. Its strange because the log says it loads the > bleeding edge of PharoLauncher so that means it should pull in my change ? > Am I correct ? Any idea what is wrong here ? > > On Mon, Sep 8, 2014 at 3:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> kilon alios wrote: >> >> It should not be a problem because it affects only the PharoLauncher image >> and not the images you download with PharoLauncher so the old progress bar >> will remain in those images. >> >> Its personal taste of course but let remember here that a common complain >> about smalltalk is that it looks weird and for some people ugly. How many >> progress bars you have seen up left ? What advantage is there for a >> progress bar to be up left ? >> >> Also because when performing such jobs pharo freezes and does not allow for >> further interactions with the user until the job ends it makes more sense >> for the progress bar to be in the middle , bigger size so its very visible >> even from distance if the user decides to leave the screen to grab some >> coffee or fight with his light saber and if possible even display a "Please >> wait..." message so the user / beginner Pharoers knows this is not a bug or >> he /she did not brake Pharo. >> >> >> >> Thats cool, but I may revise it later if I actually get around to making >> PharoLauncher download images in the background. A few other things on my >> plate to clear first. >> cheers -ben >> >> >> I am not saying Pharo should be an exact copy of the GUIs out there but at >> least we should respect the user habits and broke those habits only if it >> is necessary. Or else you will have more and more people looking at the >> GUI and going "Eeeewwww". >> >> On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> <sven(a)stfx.eu> wrote: >> >> >> >> Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other >> words, there are preferences for the location of the progress bar, these >> should probably be honoured. A big or a small bar also depends a bit on >> taste I would say. >> >> On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> wrote: >> >> >> >> ok with a bit of help I was able to figure things out, it turns out that >> >> >> it was simple to do difficult to understand :D so here is my answer >> >> >> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >> >> I also attached the new progress bar i customised and the old for >> >> >> comparison as attached images >> >> >> <newProgressBar.JPG> >> >> <oldProgressBar.JPG> >> â >> Personally I would make my code the default Progress Bar for entire >> >> >> Pharo including all operations because its annoying to be that small and up >> there. This should work well even if there are multiple Progress Bars >> displayed. But for not its PharoLauncher only progress bar. >> >> >> How I add this code to PharoLauncher ? do I use just the development >> >> >> mode of PharoLauncher and Commit ? I dont want to mess anything up. >> >> >> Next step would be to add an info box for each image so people know what >> >> >> they download before downloading it. >> >> >> On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> >> >> wrote: >> >> >> yeah yeah I see it now, there actually many announcers (3 of them ) all >> >> >> seem to signal SystemProgressMorph , oh boy this will be a tricky one . >> Thanks for the pointer, now I have to find how to capture the instance of >> that SystemProgressMorph. If I find the instance sending a width: message >> should do the trick. Looks like I will need to investigate further but at >> least you are pointed me to the right direction so I no longer feel lost in >> space. >> >> >> On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < >> >> >> thierry.goubier(a)gmail.com> wrote: >> >> >> Le 07/09/2014 11:53, kilon alios a Ã©crit : >> >> Hello pharoers it has been almost a year since the last time I commited >> >> >> to PharoLauncher so I decided to go for it once again. The first time I >> added a progress bar for people to see the progress of the download of the >> image . Now I want to scale and reposition the progress bar as I am not >> happy at all in the way it looks , its too small and hard to read. >> >> >> So I created a question at stackoverflow with all the details of my >> >> >> problem >> >> >> http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… >> >> I would not mind also some extra details on how I can fetch the Morphs >> >> >> used by UIManager or to even further customise UIManager. I tried to find >> the answer myself but after an hour of staring at the Pharo system browser >> I gave up. >> >> >> Hi Kilon, >> >> I don't have a stackoverflow account, so here is what I found. >> >> From displayProgress: , asJob brings you to Job, which has no morph at >> >> >> all. But, on the class side of Job, you have a job announcer (instance >> class variable jobAnnouncer). Inspect that variable, search among the >> subscriptions of the announcer, and you'll find SystemProgressMorph. >> >> >> A good use case of a fairly good design which is a lot harder to unravel >> >> >> than it should be, due to the lack of tools to explore announcer / >> subscription relations. >> >> >> Thierry >> >> >> >> >> >> >> >

Sept. 9, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 9, 2014

[pharo-project/pharo-core] f681e6: 40214

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f681e684b87198b4254c801cab43063920e9661c https://github.com/pharo-project/pharo-core/commit/f681e684b87198b4254c801c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-09 (Tue, 09 Sep 2014) Changed paths: M Refactoring-Critics.package/RBAbstractClassRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBAssignmentOnBlockArgumentRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBClassNotReferencedRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBEquivalentSuperclassMethodsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBImplementedNotSentRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBJustSendsSuperRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBLongMethodsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBMethodSourceContainsLinefeedsRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBNoClassCommentRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBParseTreeLintRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBReturnsBooleanAndOtherRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSendsDifferentSuperRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSendsMethodDictRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSentNotImplementedRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBSuperSendsNewRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTempVarOverridesInstVarRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTemporaryVariableCapitalizationRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTempsReadBeforeWrittenRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBTransformationRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUncommonMessageSendRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUndeclaredReferenceRule.class/instance/running/checkMethod_.st M Refactoring-Critics.package/RBUnreferencedVariablesRule.class/instance/running/checkClass_.st M Refactoring-Critics.package/RBUtilityMethodsRule.class/instance/running/checkMethod_.st A Refactoring-Critics.package/extension/CompiledMethod/instance/selfMessages.st A Refactoring-Critics.package/extension/CompiledMethod/instance/superMessages.st A Refactoring-Critics.package/extension/SystemNavigation/instance/implementorsExistOf_.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/possible bugs/abstractClass.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/classNotReferenced.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/implementedNotSent.st M Refactoring-Tests-Core.package/RBBasicLintRuleTest.class/class/unnecessary code/unreferencedVariables.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script214.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40214.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40214 13955 Rewrite Lint rules to use common tools https://pharo.fogbugz.com/f/cases/13955 http://files.pharo.org/image/40/40214.zip

Sept. 9, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 9, 2014

[pharo-project/pharo-core] 427530: 40213

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 427530c3f3d4ab2adda0a79a20f038e3e08a5e40 https://github.com/pharo-project/pharo-core/commit/427530c3f3d4ab2adda0a79a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-09 (Tue, 09 Sep 2014) Changed paths: M Morphic-Base.package/MenuMorph.class/instance/construction/addUpdating_target_action_.st A Morphic-Base.package/MenuMorph.class/instance/construction/addUpdating_target_selector_.st M Morphic-Base.package/PolygonMorph.class/instance/menu/addCustomMenuItems_hand_.st M Morphic-Base.package/PolygonMorph.class/instance/menu/addPolyLIneCurveMenuItems_hand_.st M Morphic-Base.package/TextMorph.class/instance/menu/addCustomMenuItems_hand_.st M Polymorph-Widgets.package/TEnableOnHaloMenu.class/instance/menu %26 halo/addToggleItemsToHaloMenu_.st M Refactoring-Tests-Core.package/RBSearchTest.class/instance/accessing/buildSimpleLiteralSearch.st M Refactoring-Tests-Core.package/RBSearchTest.class/instance/accessing/buildSimpleVariableSearch.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script213.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40213.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Browser-Old.package/CodeHolder.class/instance/what to show/addContentsTogglesTo_.st M Tool-Workspace.package/Workspace.class/instance/window menu/addModelItemsToWindowMenu_.st Log Message: ----------- 40213 13928 Failing test: RBSearchTest>>#testAllSearches https://pharo.fogbugz.com/f/cases/13928 13865 Cleaning menuMorph https://pharo.fogbugz.com/f/cases/13865 http://files.pharo.org/image/40/40213.zip

Sept. 9, 2014

Re: [Pharo-dev] Trying to scale and reposition the progress bar for PharoLauncher

by kilon alios

revise away, downloading in the background sounds very cool. I also have some more contributions to make. By the way my commit was successful http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher/diff/PharoLauncher-Core… The build was succesful https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… but when I downloaded the new PharoLauncher image to my surprise the code was nowhere to be found. Its strange because the log says it loads the bleeding edge of PharoLauncher so that means it should pull in my change ? Am I correct ? Any idea what is wrong here ? On Mon, Sep 8, 2014 at 3:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > > It should not be a problem because it affects only the PharoLauncher image > and not the images you download with PharoLauncher so the old progress bar > will remain in those images. > > Its personal taste of course but let remember here that a common complain > about smalltalk is that it looks weird and for some people ugly. How many > progress bars you have seen up left ? What advantage is there for a > progress bar to be up left ? > > Also because when performing such jobs pharo freezes and does not allow for > further interactions with the user until the job ends it makes more sense > for the progress bar to be in the middle , bigger size so its very visible > even from distance if the user decides to leave the screen to grab some > coffee or fight with his light saber and if possible even display a "Please > wait..." message so the user / beginner Pharoers knows this is not a bug or > he /she did not brake Pharo. > > > > Thats cool, but I may revise it later if I actually get around to making > PharoLauncher download images in the background. A few other things on my > plate to clear first. > cheers -ben > > > I am not saying Pharo should be an exact copy of the GUIs out there but at > least we should respect the user habits and broke those habits only if it > is necessary. Or else you will have more and more people looking at the > GUI and going "Eeeewwww". > > On Mon, Sep 8, 2014 at 2:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> <sven(a)stfx.eu> wrote: > > > > Nice, but did you see SystemProgressMorph class>>#settingsOn: ? In other > words, there are preferences for the location of the progress bar, these > should probably be honoured. A big or a small bar also depends a bit on > taste I would say. > > On 08 Sep 2014, at 13:00, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> wrote: > > > > ok with a bit of help I was able to figure things out, it turns out that > > > it was simple to do difficult to understand :D so here is my answer > > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > I also attached the new progress bar i customised and the old for > > > comparison as attached images > > > <newProgressBar.JPG> > > <oldProgressBar.JPG> > â > Personally I would make my code the default Progress Bar for entire > > > Pharo including all operations because its annoying to be that small and up > there. This should work well even if there are multiple Progress Bars > displayed. But for not its PharoLauncher only progress bar. > > > How I add this code to PharoLauncher ? do I use just the development > > > mode of PharoLauncher and Commit ? I dont want to mess anything up. > > > Next step would be to add an info box for each image so people know what > > > they download before downloading it. > > > On Sun, Sep 7, 2014 at 8:52 PM, kilon alios <kilon.alios(a)gmail.com> <kilon.alios(a)gmail.com> > > wrote: > > > yeah yeah I see it now, there actually many announcers (3 of them ) all > > > seem to signal SystemProgressMorph , oh boy this will be a tricky one . > Thanks for the pointer, now I have to find how to capture the instance of > that SystemProgressMorph. If I find the instance sending a width: message > should do the trick. Looks like I will need to investigate further but at > least you are pointed me to the right direction so I no longer feel lost in > space. > > > On Sun, Sep 7, 2014 at 7:22 PM, Thierry Goubier < > > > thierry.goubier(a)gmail.com> wrote: > > > Le 07/09/2014 11:53, kilon alios a Ã©crit : > > Hello pharoers it has been almost a year since the last time I commited > > > to PharoLauncher so I decided to go for it once again. The first time I > added a progress bar for people to see the progress of the download of the > image . Now I want to scale and reposition the progress bar as I am not > happy at all in the way it looks , its too small and hard to read. > > > So I created a question at stackoverflow with all the details of my > > > problem > > > http://stackoverflow.com/questions/25708970/trying-to-find-the-progressbar-… > > I would not mind also some extra details on how I can fetch the Morphs > > > used by UIManager or to even further customise UIManager. I tried to find > the answer myself but after an hour of staring at the Pharo system browser > I gave up. > > > Hi Kilon, > > I don't have a stackoverflow account, so here is what I found. > > From displayProgress: , asJob brings you to Job, which has no morph at > > > all. But, on the class side of Job, you have a job announcer (instance > class variable jobAnnouncer). Inspect that variable, search among the > subscriptions of the announcer, and you'll find SystemProgressMorph. > > > A good use case of a fairly good design which is a lot harder to unravel > > > than it should be, due to the lack of tools to explore announcer / > subscription relations. > > > Thierry > > > > > > > >

Sept. 9, 2014