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

Re: [Pharo-dev] OSX code signing

by Marcus Denker

> On 26 Aug 2015, at 18:39, Ben Coman <btc(a)openinworld.com> wrote: > > What are the future plans for dealing with OSX code signing? > We need to do it. We should have done it ages ago, nobody had the time. > > So if we can no longer store a writable Image under the Resources > folder, what are the alternatives? > > 1. Deliver app with read-only Image under the Resources folder. The > INI file can define the location of the writeable Image under > ../{user}/Library/. When the VM starts, if the writable Image file > does not exist, the VM transparently copies the read-only Image from > resources to the writable location. > I want to ship the an app called âPharo5â that contains the VM, sources and a read-only image template. This just lives in /Applications. -> start it, it starts the template -> save template, it saves a one file pharo image -> klick on a pharo image, it starts the correct VM contained in Pharo<Version> package > 2. Use a launcher application like PharoLauncher. I would like to have the launcher concept be integrated with what i described. But I am not sure I want just a launcher to start when clicking on âPharoâ. And it needs to play well with people that manage images themselves. > > 3. For a "portable" app (e.g. on USB stick) push the app down one > folder, so rather than putting the Win/Lin executables inside the OSX > app, the top level folder contains folders Windows, Linux, Common, and > the app. No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps). Marcus

Aug. 28, 2015

DesktopManager does not respect background

by Esteban Lorenzano

Hi Torsten, First, thanks for desktop managerâ¦ even if I do not need it all the timeâ¦ time to time I really need it :) Now, the problem :) I work with dark theme and switching back from one desktop does not respect my background :) cheers, Esteban

Aug. 28, 2015

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

by Torsten Bergmann

I can confirm that this is a problem in latest Pharo 4.0 which is build #40619. The interesting thing is that we do not have this effect in the initial Pharo 5 version started right after Pharo 4 Release which is Pharo 5.0 Build #50000. As it is working in Pharo 5.0 Build #50000 I guess something was broken by one of the backports. Anyone know from what 4xxxx build nr. 50000 was forked? Thans T. > Gesendet: Donnerstag, 27. August 2015 um 20:04 Uhr > Von: "Julien Delplanque" <julien(a)tamere.eu> > An: "H. Hirzel" <hannes.hirzel(a)gmail.com> > Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [ANN] Multiple Desktop support for Pharo 5 > > 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. 28, 2015

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

by S Krish

Nice..!.. The shortcuts : Ctrl+D+P .. n others dont work on Windows.. On Thu, Aug 27, 2015 at 6:49 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Julien Delplanque provided this week a goodie to switch between > "desktops" - but his initial solution was more or less hiding windows > and not really switching between real Pharo worlds/desktops. > > I gave him some tips what could be done on the pharo-user list. Havent > heard > from him afterwards. > > Now I was able to spend a few hours on this topic myself and implemented > a full multiple desktop solution myself. > > This works in Pharo 5 only (currently) and requires latest VM (at least on > Windows) > from files.pharo.org to get the keyboard shortcuts right. > > To try: > > Gofer new > smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager'; > configuration; > loadDevelopment. > > The goodie has some nice features like keyboard navigation, world menu > integration and even a custom spotter with preview of the desktops. > > Quick start: > =========== > - evaluate the above expression in a Pharo 5 image > - 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 > - 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 > > The code is hopefully a good example on how to build a custom spotter, > shortcuts, inspector extensions, ... > Additionally all this is described in a new article including screenshots > and a guide on how to use this new goodie: > > https://medium.com/@astares/multiple-desktops-for-pharo-5cbc46f3179f > > Actually the article took more time to write than coding but I hope > it helps explaining Pharo and why it is a power tool. > > Project is on > http://www.smalltalkhub.com/#!/~TorstenBergmann/DesktopManager > Article and code is still subject to change. > > Have fun > T.

Aug. 28, 2015

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

by S Krish

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 >> >> >

Aug. 28, 2015

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

by Richard Wettel

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 > >

Aug. 28, 2015

QANautilusPluggin Logic Question

by stepharo

When I add an iv to Model I get a ByteSymbol>>entity: QANautilusPluggin>>initialize changeHandler := GLMAsyncTask new priority: Processor activePriority - 1; doInBackground: [ morph entity: self currentEntity ]; yourself And in the debugger morph is a a Morph exactly a QANautilusPluginMorph(493092864) Yuriy do you use thread? Stef

Aug. 28, 2015

[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