May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Progress bar in the top left

by Sean P. DeNigris

Sean P. DeNigris wrote > > As I've been working on NewSystemProgressMorph > NewSystemProgressMorph feels ready... The most significant change is that now, when you use methods like String>>displayProgressFrom:to:during:, you have a real API for updating the progress bar. Instead of sending symbols to a block*, you send messages to aSystemProgressItemMorph. For example: bar value: 'newLabel' -> bar label: bar value: #increment -> increment * see SystemProgressMorph>>label:min:max: for the mess we had before Issue 5969: [ENH]: Clean SystemProgressMorph and friends (Part 2) http://code.google.com/p/pharo/issues/detail?id=5969 This version is much cleaner and seems to work well. I tested it loading a few Metacello configurations. There is a small issue where long labels make the morph off-center for an instant, but it seems like we're moving toward putting it in a corner anyway (http://forum.world.st/Progress-bar-in-the-top-left-td4631530.html) so I won't spend time fixing it now... Fix in inbox: SLICE-Issue-5969-ENH-Clean-SystemProgressMorph-and-friends-Part-2-SeanDeNigris.1 * Cleanup new classes - categorize all uncategorized methods - a lot of little cleanups, refactors - NewSystemProgressMorph - remove forking - fix recentering when long labels are added * Integrate new classes with the system - Replace SystemProgressMorph with NewSystemProgressMorph (i.e. remove SystemProgressMorph and rename NewSystemProgressMorph to SystemProgressMorph) - SystemProgressBarMorph -> ProgressBarMorph (there is nothing "system"-specific about it. It is generally useful - ProgressInitiationException>>defaultMorphicAction - update to new classes/functionality * related changes - Collection>>do:displayingProgress:every: - return immediately for empty collections - if aStringOrBlock is aString, use it right away - Polymorph - fixed some formatting (e.g. double spaces) Status: FixReviewNeeded -- View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631763.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Progress bar in the top left

by Esteban Lorenzano

On 24/05/2012, at 18:06, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > StÃ©phane Ducasse wrote >> >> Now sometimes we should have a blocking UI. >> > > As I've been working on NewSystemProgressMorph, I've been toying with > whether the progress bar should be directly manipulated, as is the case now, > or should just be another subscriber for progress announcements. This way it > could be disabled by unsubscribing, and any other actions could be taken > additionally/instead (e.g. send progress to stdout, transcript, etc.) +1 > > -- > View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631730.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 24, 2012

Re: [Pharo-project] Suggestions about Nautilus Look

by Fabrizio Perin

Hi, > Fabrizio Perin-3 wrote > > > > 1 - If the Nautilus browser is a package browser why an infinity stack of > > grey packages is shown? I think it is possible to safely remove all the > > grey package icons since they are not really useful nor meaningful. This > > will make the visual impact of nautilus lighter. > > > The gray icons indicate that the package is clean. When there are unsaved > changes, the color goes to red > I have noticed that but what I'm saying is that we know those are packages because that is a package browser. The gray icons are a redundant information and so not useful and also visually disturbing. I think, if you don't have to tell me something in particular like that there are unsaved changes, there should be no icon on the packages. > > Fabrizio Perin-3 wrote > > > > 3- The text in the message that appear in bottom-left corner that notify > > about the test results it is not really visible if the background is > > yellow > > or green so what about to make it black. Or better, what about to make it > > black if the background color is green or yellow and leave it white if > the > > background is red? > > > Whatever color we make them, they will be less visible with *some* color > background ;-) I *really* like that the visual color feedback is part of > the > testing domain. I know the test passed without moving my eyes to the corner > to read the text. Your point about checking the background color and > altering for some contrast is valid, but seems like a long-shot (how many > people have those bold green/yellow colors as backgrounds?!). I would guess > if you're passionate about it, you should implement it yourself and submit > the code :) > > I also like that notification. What I'm saying here is that the color of the text into the feedback is white (or transparent and so white since I have white background) and so it is not really readable in case the feedback is green or yellow accordingly to the tests result. But this is a really tiny point. Regards, Fabrizio

May 24, 2012

[Pharo-project] Bug fixes for 1.4

by Sean P. DeNigris

There is a bug in 1.4 where a trailing slash causes FileReference>>exists to return false e.g. on my machine, "(FileLocator home asFileReference / '.jenkins/') exists" -> false "(FileLocator home asFileReference / '.jenkins') exists" -> true I noticed it has been fixed in 2.0 and tracked the change down to DiskStore>>nodeAt:ifPresent:ifAbsent:. Now how do I figure out where this change came from? I didn't see anything promising in the issue tracker. Assuming this was part of a slice, I want to make sure I include any associated changes to other packages. Also, this makes me wonder again about the tagging process. It seems this should have gone into both 1.4 and 2.0 if I correctly understand the new release process... Sean -- View this message in context: http://forum.world.st/Bug-fixes-for-1-4-tp4631751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Update stream for released images

by Mariano Martinez Peck

On Thu, May 24, 2012 at 10:32 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Now that there will be bug fixes for released images, it seems like we > should > we keep "Software update" in the world menu, no? > > yes, it starts to make sense once again now :) > Sean > > -- > View this message in context: > http://forum.world.st/Update-stream-for-released-images-tp4631743.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 24, 2012

Re: [Pharo-project] Posible bug

by Sean P. DeNigris

Camillo Bruni-3 wrote > > check the HOWTOBUILD file in the git repository > + there is an image.sh script in the /image folder of the git repo > > I think the git repo should be the place to keep track of such > documentation! > I don't know enough about the process - will that guarantee a working build? Right now, Jenkins "Cog Git Tracker" is failing (not because of the sources this time). If there was something broken, using the versions of image/ConfigurationOfXxx, sources, etc. from Jenkins' last successful build would guarantee success anyway. Sean -- View this message in context: http://forum.world.st/Posible-bug-tp4631484p4631744.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

[Pharo-project] Update stream for released images

by Sean P. DeNigris

Now that there will be bug fixes for released images, it seems like we should we keep "Software update" in the world menu, no? Sean -- View this message in context: http://forum.world.st/Update-stream-for-released-images-tp4631743.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Progress bar in the top left

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > Now sometimes we should have a blocking UI. > As I've been working on NewSystemProgressMorph, I've been toying with whether the progress bar should be directly manipulated, as is the case now, or should just be another subscriber for progress announcements. This way it could be disabled by unsubscribing, and any other actions could be taken additionally/instead (e.g. send progress to stdout, transcript, etc.) -- View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631730.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Suggestions about Nautilus Look

by Sean P. DeNigris

Fabrizio Perin-3 wrote > > I have a couple of propositions about the Nautilus look: > Great feedback! Thanks for taking the time to start the discussion... Fabrizio Perin-3 wrote > > 1 - If the Nautilus browser is a package browser why an infinity stack of > grey packages is shown? I think it is possible to safely remove all the > grey package icons since they are not really useful nor meaningful. This > will make the visual impact of nautilus lighter. > The gray icons indicate that the package is clean. When there are unsaved changes, the color goes to red Fabrizio Perin-3 wrote > > 3- The text in the message that appear in bottom-left corner that notify > about the test results it is not really visible if the background is > yellow > or green so what about to make it black. Or better, what about to make it > black if the background color is green or yellow and leave it white if the > background is red? > Whatever color we make them, they will be less visible with *some* color background ;-) I *really* like that the visual color feedback is part of the testing domain. I know the test passed without moving my eyes to the corner to read the text. Your point about checking the background color and altering for some contrast is valid, but seems like a long-shot (how many people have those bold green/yellow colors as backgrounds?!). I would guess if you're passionate about it, you should implement it yourself and submit the code :) Sean -- View this message in context: http://forum.world.st/Suggestions-about-Nautilus-Look-tp4631723p4631728.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Progress bar in the top left

by StÃ©phane Ducasse

Indeed. > Is it possible to have an uniform way to present announcement. There > is already the growl-like announcements of tests used by the Nautilus > Browser done ob botton left. Maybe progress bar should be done in the > same screen area. Now sometimes we should have a blocking UI. Stef > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

May 24, 2012