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

Re: [Pharo-dev] Update question

by kilon alios

I tried it a few times, and had nothing but problems with it. We have discussed here several times and from what I have learned there several technical limitation. I am using pharolauncher non stop and wonder why Pharolauncher is not integrated inside Pharo yet. I have added my code inside the configuration browser (Ephestos, Nireas) and Installing my code back in a fresh image is just a two click process. On Tue, Mar 24, 2015 at 12:13 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Today I wanted (again) to update my image and it can't find GT packages. > So I'm interested how the community deals with that. Do you take fresh > downloaded images regularly? Or you do not update? Is it just me? > > thanks, > > Norbert > > >

March 24, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by Alain Plantec

Hello Henrik, I read windowEvent: anEvent .... WorldState quitSession. self removeProperty: #closeWorldDialogOpen ] but shouldn't it be windowEvent: anEvent .... WorldState quitSession. self removeProperty: #canOpenCloseDialog ] Cheers Alain > Le 23 mars 2015 Ã 14:06, Henrik Johansen <henrik.s.johansen(a)veloxit.no> a Ã©crit : > > I just ran into a case where all morphs became unresponsive, and clicking anywhere only gave me the World Menu. > > After some investigation, it turned out all the World submorphs had been locked, and I could "unfreeze" them with the following (from a new Workspace): > World submorphsDo: [ :aMorph | aMorph unlock ] > > What triggered it? > Well, the image had become unresponsive, so I clicked the close buttons a couple of times (before trying good ol' cmd-dot, which brought up a debugger on the old UI process and let me continue). > > The close dialog is modal, normally that's no problem, since the modal morph locks all other morphs, no two can be opened at the same time (unless you somehow let that modal morph open another), but the close triggered by the system window's close button is special, since it is triggered outside the control of the World. > > The bug is rare in occurrence, yet easy to trigger; press the window close button twice, cancel one of the close dialogs, all windows that were open will remain locked and seem unresponsive. > > It might be smart to rethink the whole modality concept to make the code more robust/coherent, but for now an extra check for this single case in PasteUpMorph >> windowEvent: (for instance, using a morph property) should do the trick, I'll submit a slice shortly. > > Cheers, > Henry

March 24, 2015

Re: [Pharo-dev] Update question

by Peter UhnÃ¡k

I didn't even know there was an update option. Instead I download fresh images (regularly) through Pharo Launcher, plus I have startup script that looks at the name of the image and does extra stuff â e.g. if the image name contains MyProjectX, it automatically adds repositories for it and loads it). Peter On Tue, Mar 24, 2015 at 11:13 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Today I wanted (again) to update my image and it can't find GT packages. > So I'm interested how the community deals with that. Do you take fresh > downloaded images regularly? Or you do not update? Is it just me? > > thanks, > > Norbert > > >

March 24, 2015

Update question

by Norbert Hartl

Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? thanks, Norbert

March 24, 2015

Re: [Pharo-dev] Old Pharo Mac VM on pharo.org

by Ben Coman

Is pharo-minimal going to be an artefact of the Release? Should it be temporarily sacrificed to allow a more recent VM to go out with the Release? If its too close to Release to change the VM, then perhaps the current release date could be a Release Candidate including a new VM, kept for maybe a two weeks with a hard rule for no updates except related to the new VM. I guess the creation of additional work and complexity for the Release, as well as risk updating the VM would be a consideration against. cheers -ben On Mon, Mar 23, 2015 at 9:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 23 Mar 2015, at 10:27, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 23.03.2015 um 09:51 schrieb Noury Bouraqadi <bouraqadi(a)gmail.com>: > > Hi, > > On http://pharo.org/download I got the Mac VM dating back to sept 2014. > Shouldn't it be http://files.pharo.org/vm/pharo/mac/latest.zip ? > > No, I think latest is more less a direct copy of the latest successful > build on jenkins. That would be a no-go to offer as the vm to use. VMs have > have releases as well. And in the same directory there is a stable.zip > which is the right one. And it is from september. Everything else is in the > hands of esteban. > > > this :) > > but seriously: Iâve been having some problems to promote a newer vm as > stable, concretely in the pharo-minimal step. I wanted to have new one for > Pharo4, but Iâm not arriving eitherâ¦ so I will move it as soon as I find a > solution, Iâm sorry :( > > Esteban > > > Norbert > > >

March 24, 2015

Making Seaside work in Pharo 4

by Stephan Eggermont

In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus was removed. What is the correct way to replace it? WABrowser uses a nautilus browser to show a web-based browser. (build 609, Seaside #'release3.1' pharo4, from ci) WABrowserTest>>testContentsNotifying | model | model := WABrowser browserClass new. model systemCategoryListIndex: (model systemCategoryList indexOf: 'Seaside-Tests-Pharo-Development'). model classListIndex: (model classList indexOf: #WABrowserTest). model messageCategoryListIndex: (model messageCategoryList indexOf: #'-- all --'). [ self assert: (model contents: 'sampleMethod ^ 1 + 1' notifying: self). self assert: message isNil ] ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ] Stephan

March 24, 2015

[pharo-project/pharo-core] 0368f1: 40579

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 0368f11bb36e30240a81bb6091d34a44f29fcd29 https://github.com/pharo-project/pharo-core/commit/0368f11bb36e30240a81bb60… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-24 (Tue, 24 Mar 2015) Changed paths: M Morphic-Core.package/PasteUpMorph.class/instance/event handling/windowEvent_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script578.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script579.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40578.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40579.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot-Tests.package/PropertySlotTest.class/instance/tests/testCreateClassWithPropertySlotAddSecond.st A Slot-Tests.package/PropertySlotTest.class/instance/tests/testRemovePropertySlot.st A Slot-Tests.package/PropertySlotTest.class/instance/tests/testRemovePropertySlot2.st R Slot.package/PropertySlot.class/instance/class building/installingIn_.st A Slot.package/PropertySlot.class/instance/class building/layoutChanged_.st R Slot.package/PropertySlot.class/instance/class building/removingFrom_.st R Slot.package/PropertySlot.class/instance/initalize/initialize.st A Slot.package/Slot.class/instance/class building/layoutChanged_.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st Log Message: ----------- 40579 15221 PropertySlot: Tests for removing PropertySlots https://pharo.fogbugz.com/f/cases/15221 15215 Prevent the World locking due to multiple modal dialogs open https://pharo.fogbugz.com/f/cases/15215 http://files.pharo.org/image/40/40579.zip

March 24, 2015

[pharo-project/pharo-core]

by GitHub

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

March 24, 2015

Re: [Pharo-dev] choose event in Bern on March 31: alain plantec on Bloc + working session on Pharo IDE

by Tudor Girba

Unlikely. Doru On Tue, Mar 24, 2015 at 5:05 AM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > fingers crossed. > > > On Mon, Mar 23, 2015 at 10:33 PM, Sean P. DeNigris > <sean(a)clipperadams.com> wrote: > > Will the talks be recorded? > > > > p.s. please, please, please ;) > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/choose-event-in-Bern-on-March-31-alain-plantec-on-Blo… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Thierry Goubier

Hi Aliaksei, this is a good and interesting read, especially the feedback on making it fast (solution to some performance problems in Morphic). However, I have the feeling that the css inspired layout syntax is a step backward on what is/was Morphic (which is using other morphs to constrain and adjust layout in the same way as TeX/LaTeX instead of adding padding, align). Was that syntax choosen because layouting with filler Morphs is considered too slow or too complex to be understandable? Regards, Thierry Le 23/03/2015 20:54, Aliaksei Syrel a Ã©crit : > Hi, > > Sorry if my reply will be too long, but I tried to summarise our > experience with Morphic/Brick and give some useful feedback or even > provide ideas. Who wants will read :) > > Brick is not a thin layer anymore. > > It depends on what you mean under 'a thin layer' ;) Anyway, Brick was > born out of need. Spotter is completely built using Brick and Rubric. No > morphs are used at all (except Rubric of course). All Bricks in Spotter > in the end are subclasses of GLMBrick, which uses from original Morph > only Canvas (without drawing) and MorphicEvents. Everything else was > rewritten from scratch. During some period of time Brick was able to > render itself on Athens canvas, but we dropped it because of Font issues > in athens. > Spotter is not the only tool written using Brick, GLMPager - a pane > pager in GT-Inspector, GT-Playground and GT-Debugger is also completely > done using Brick. Almost all tab labels and tab selector in GT tools are > Bricks. > > I could say that we collected quite some experience building it. Now I > would like to enumerate features of UI framework we used to solve > encountered problems. > > * Local bound coordinates. > > Nothing to say more here :) It's somehow obvious to have. > > * Detects graph of Bricks that should be invalidated when Brick > triggers invalidation. So there is no need to invalidate the whole > graph. > o For example if Brick fills parent it means that it doesn't > depend on children (simple and most common situation). So if any > child triggers invalidation there is no need to invalidate > parent as it doesn't depend on them. The same works in reversed way. > o Build graph separately for each dimension: width and height. If > only height of Brick was changed and children depend only on > width, there is no need to invalidate them => x2 faster. > o Invalidate resizing and re layouting separately. If there is no > need to reposition bricks when size changes we just skip it. > > * Link subbricks in a DoubleLinked list. So subbrickAfter and > subbrickBefore could be done in O(1). Morphic does it in O(n). It > iterates over the whole submorphs collection of the owner finds > index if current morph and then returns submorphs at: index +/-1. > submorphAfter is used when morphic tries to detect which morph > should take focus. Take a look at: Morph>>nextMorphWantingFocus. It > iterates over owner's subbricks and for each asks submorphAfter > (O(n)) - resulting time O(n^2)! That is why opening a window with a > lot of submorphs takes so many time, especially system browser for > big classes. > > * Native support of /paddings/ with css-like syntax: > > padding: anArrayOrInteger > > paddingTop: anInteger > paddingRight: anInteger > paddingBottom: anInteger > paddingLeft: anInteger > > > padding: 10. "top, right, bottom, left padding are 10px" > > padding: #(10 20). "top, bottom padding 10px. left, right padding 20px" > > padding: #(10 20 30). "top 10px. left, right 20px. bottom 30px" > > padding: #(10 20 30 40). "top 10px, right 20px, bottom 30px, left 40px" > > * Native support of /margins/ with css-like syntax: > > margin: anArrayOrInteger > > marginTop: anInteger > marginRight: anInteger > marginBottom: anInteger > marginLeft: anInteger > > Have the same syntax as padding. > > * Native support of dynamic /minHeight, minWidth, maxHeight, maxWidth/ > > minWidth: anIntegerOrBlock "actually any object that > implements brickValue:" > maxHeight: anIntegerOrBlock > > > minHeight: [ : brick | brick label width * 2 ]. > > minHeight: 200. > > maxWidth: [ self height / 2 ]. > > maxWidth: 100. > > * Native support of /z-index/, so we don't rely on subbricks' order > any more if one brick should be drawn above/below others. Works the > same as css one. > > zIndex: 2. "default value is 1" > > > * Native support of /floating /bricks. Floating bricks don't > influence on any other neighbour bricks in layout. > > floating: aSymbol > > floating: #right. "top right brick's corner matches top right > parent's corner + corresponding paddings and margins" > > floating: #center. "will be in the center of the parent and doesn't > care about other subbricks" > > Example use case is scroll bar in spotter - it has floating: > #right and zIndex: 2 so it appears above all list elements. (+ some > margins to make it fancy). > > * Native support of horizontal and vertical /aligning/. > > hAlign: aSymbol > > vAlign: aSymbol > > hAlign: #right. > > vAlign: #center. > > > * Horizontal and vertical /shrinking/ to fit children. It is > possible to have in one brick two subbricks where one shrink wraps > and other fills parent. > > hShrinkWrap. > vShrinkWrap. > > > * Horizontal and vertical /filling/ with support of percents and > min/max height/width. If in brick one child shrink wraps width (or > have static width) and other fills 100% of parent's width, filling > one will take only available space left by shrinking (or static) brick. > > hSpaceFill: aFloat - fills aFloat percents of parent's width > hSpaceFill. - alias for 100 percents. > vSpaceFill: aFloat - fills aFloat percents of parent's height > vSpaceFill. - alias for 100 percents. > > > * Transparent /border/ styling with possibility to separately > configure each side. > > borderWidth: anArrayOrInteger. > borderColor: anArrayOrColor > > The same syntax as used for paddings/margins > > * Native support of smooth gradient /box-shadows/ with rounded corners: > > shadowColor: aColor. > shadowWidth: anInteger. > > > * Layout events such as: > > onLayouted - "called when brick was completely resized and > layouted in its parent" > > onChildrenLayouted - "called when all children are completely > resized and layouted" > > > Use case: implementing flexible and responsive UI. Used in > GLMLabelBrick to shrink text and add '...' when it doesn't fit in > parent. Example is tab labels in Playground. Morphic version of tabs > shrinks text and change ui of the tab during drawing. WAT? > > * Application dependent themes. To make app work perfect all UI > elements should have the same style. In case of spotter, item > preview is created outside of spotter and there is no way using > existing morph theme mechanism to customize its look&feel especially > for spotter, because widgets always refer to global UITheme. Brick > extends theming mechanism and allows to extend existing themes > specifically for needed application and it will be applied to the > whole tree of subbricks. For example spotter can completely change > theme in runtime to dark (without even closing it). > > "in context of SpotterMorph" self themer: > GTSpotterBrickDarkThemer new. (or just replace first line in > initialize) > > Even having white theme chosen in settings. (all rubric fields > become dark too). > > > * What we really want to have in Bloc is an easy way to detect that > user clicked outside of specific morph. > > > What do you want with brick ? A new framework or just an > "implementation detail" for spotter? > It is *really* important to clarify this. > > > Now it becomes more stable, api changes less and less. We already have > quite a number of tests for layouting logic and documentation for basic > widgets. > What we want from brick... I think we want to have a way to build fast > and cheap unique and complex UIs. While it will fit our needs in GT Team > we will use it. We really would like to move all tools to Bloc as soon > as possible, but we just need something right now that works and can be > used in current version. Of course it would be great to cooperate to > make Bloc release sooner. > > Some time ago I tried to port Brick on top of Bloc saving all business > logic untouched and only changing events from morphic ones to bloc and > FormCanvas to AthensCanvas. It was rather successful. I will be happy if > it would be possible to do everything or almost everything mentioned > above in Bloc. I think we will never (but who knows) announce Brick as > separate project. In our minds it is just useful helper library. > > Thanks for reading :) > > Cheers, > Alex

March 24, 2015