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

[pharo-project/pharo-core]

by GitHub

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

Aug. 28, 2015

[pharo-project/pharo-core] 936545: 40620

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9365458bed22792c84a338122c4f222edffb0011 https://github.com/pharo-project/pharo-core/commit/9365458bed22792c84a33812… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-28 (Fri, 28 Aug 2015) Changed paths: M Graphics-Files.package/ImageReadWriter.class/class/-- all --/formFromStream_.st M Graphics-Files.package/ImageReadWriter.class/class/image reading%2Fwriting/formFromStream_.st M ScriptLoader40.package/ScriptLoader.class/instance/-- all --/commentForCurrentUpdate.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script619.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/script620.st R ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40619.st A ScriptLoader40.package/ScriptLoader.class/instance/-- all --/update40620.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script619.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script620.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40619.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40620.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40620 16388 Backport Pharo4: 16387 remove Cursor read showWhile: from ImageReadWriter>>#formFromStream: https://pharo.fogbugz.com/f/cases/16388 http://files.pharo.org/image/40/40620.zip

Aug. 28, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 28, 2015

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

by Marcus Denker

This should be fixed in the last version (50286) On Fri, Aug 28, 2015 at 10:34 AM, S Krish <krishnamachari.sudhakar(a)gmail.com > wrote: > Getting an error on loading bloc: > > Using base Pharo 4.0 with Pharo 5 image / changes. > > [image: Inline image 1] > > On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <wettel(a)gmail.com> wrote: > >> Great job! Works well. Thank you! >> >> cheers >> Ricky >> >> On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> 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 >>> >>> >> > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Aug. 28, 2015

Re: [Pharo-dev] [Playground] Getting contents from the cloud?

by Peter UhnÃ¡k

On Fri, Aug 28, 2015 at 2:32 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > vonbecmann wrote > > GREAT!!!!! > > Yes, isn't it!? > > > vonbecmann wrote > > (what a dummy!) > > Not at all. We are terrible at documenting all our amazing features. How > would one guess that besides the fact that Spotter can do everything but > open your beer bottle? > I found it when exploring spotter extension methods... The problem is that we want to strike a balance between "no information" and "information overload", which is quite hard, because everyone has different preferences and features are added and removed almost daily to at least one of tools you use. So here easy discoverability is in my eyes more important than documentation. E.g. opening inspector on all spotter methods is even easier than googling a website where the documentation/list of features may or may not be. Plus this doesn't impose extra cost on the developer, as the source acts as documentation. Of course this doesn't always apply... Peter

Aug. 28, 2015

Re: [Pharo-dev] QANautilusPluggin Logic Question

by Yuriy Tymchuk

I will take a look at the issue in the evening. It's related to the latest refactoring but should not be connected to the AsyncTask in any way Uko Sent from my iPhone > On 28 Aug 2015, at 12:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Maybe related.. there is test failing on the CI server : > > ReleaseTests.ReleaseTest.testMethodsWithUnboundGlobals (from ReleaseTests) > Found methods with unbound globals: an OrderedCollection(QANautilusPluginMorph>>#buildConfirmationCheckbox:) > > > >>> On 28 Aug 2015, at 11:34, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> QANautilusPluggin > >

Aug. 28, 2015

Re: [Pharo-dev] [Playground] Getting contents from the cloud?

by Sean P. DeNigris

vonbecmann wrote > GREAT!!!!! Yes, isn't it!? vonbecmann wrote > (what a dummy!) Not at all. We are terrible at documenting all our amazing features. How would one guess that besides the fact that Spotter can do everything but open your beer bottle? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Playground-Getting-contents-from-the-cloud-tp4845720p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 28, 2015

[pharo-project/pharo-core] a5b426: 50286

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a5b4266f01ca09c575bc1be273233538df3dd585 https://github.com/pharo-project/pharo-core/commit/a5b4266f01ca09c575bc1be2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-28 (Fri, 28 Aug 2015) Changed paths: M Monticello-OldDataStreamCompatibility.package/MCOldDataStreamExtensions.class/class/class initialization/initialize.st M Monticello.package/MCDataStream.class/class/initialize-release/initializeTypeMap.st A Monticello.package/extension/WideString/class/newFromStream_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50285.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50286.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50285.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50286.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/NewVersionBrowser.class/instance/instance creation/buildChangeList.st R Spec-Tools.package/NewVersionBrowser.class/instance/private/scanVersionsOf_class_meta_category_selector_.st R System-Changes.package/ChangeSet.class/class/scanning/scanCategory_.st R System-Changes.package/ChangeSet.class/class/scanning/scanFile_from_to_.st R System-Changes.package/ChangeSet.class/class/scanning/scanVersionsOf_class_meta_category_selector_.st M System-Changes.package/extension/TBehavior/instance/changeRecordsAt_.st A System-Sources.package/SourceFileArray.class/instance/public - string reading/changeRecordsFrom_className_isMeta_.st Log Message: ----------- 50286 16392 Should register WideString reader/writer to MCDataStream https://pharo.fogbugz.com/f/cases/16392 16408 Clean up around changes files https://pharo.fogbugz.com/f/cases/16408 http://files.pharo.org/image/50/50286.zip

Aug. 28, 2015

Re: [Pharo-dev] DesktopManager does not respect background

by Sean P. DeNigris

EstebanLM wrote > I work with dark theme and switching back from one desktop does not > respect my background :) I experienced this too. I would say it's a design flaw in the theme-ing, which didn't matter much because we only had one desktop. IIRC the background is set on install, not as part of the theme instance. ----- Cheers, Sean -- View this message in context: http://forum.world.st/DesktopManager-does-not-respect-background-tp4846558p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2015