January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Nicolai Hess

2014/1/3 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > Le 03/01/2014 10:31, Marcus Denker a Ã©crit : > > From then the change was made *other* changes have been done. > > > > âChangeâ will show *all* differences, both the ones other integrations > > did to the package as well as the changes of the slice. > > > > In addition, there is still some bug that when e.g moving classes > > the *extending* packages are bot dirty and there might be some > > inconsistencies. > > Got it. So this is simply an usability concern with misleading button > text and button tooltips, or am I the only one to fell misguided? > > Not the only one :-) I asked the very same question. > Anyway should be easily fixable, if it should be. > > Thanks > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > > >

Jan. 3, 2014

Re: [Pharo-dev] Weird Athens Artifact

by J.F. Rick

OK. Here's some code to demonstrate the bug: wrap := AthensWrapMorph new extent: 100 @ 100; yourself. black := Morph new extent: 100 @ 100; color: Color black; yourself. red := Morph new extent: 100 @ 50; color: Color red; yourself. transparent := Morph new extent: 50 @ 50; position: 25 @ -25; color: Color transparent; yourself. wrap addMorph: black; addMorph: red; addMorph: transparent; openInWorld Please note that for this to work, you have to remove the "initialize" method in AthensWrapMorph that makes it use a TableLayout, which is a silly choice. Though adding transparent should not make a difference in the rendering, it does. Cheers, Jeff On Thu, Jan 2, 2014 at 5:29 PM, J.F. Rick <self(a)je77.com> wrote: > I'm aware of the default Morphic behavior. I've hacked it so that a > transparent 1x1 pixel bit is in the hand and its movement causes the brown > morph to move and remain a submorph of the AthensWrapMorph application. > > Yes, this is some kind of weird clipping thing. Specifically, it looks > like clipping is not happening. The brown morph (and the area behind it) > renders correctly but it is not rendered at the correct location. Instead, > the starting location of the rendering seems to be forced into the bounds > of the surface. That's why it looks like the background things have shifted > downwards. > > Cheers, > > Jeff > > > On Thu, Jan 2, 2014 at 5:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 2 January 2014 16:54, J.F. Rick <self(a)je77.com> wrote: >> >>> I've been converting DigiTile over to Athens with general success but I >>> have found an odd rendering bug. In this scenario, I am moving the brown >>> square around with a hand. As I am using AthensWrapMorph, I have made it so >>> that the brown square is a submorph of the application (an AthensWrapMorph) >>> and not in the hand. The brown square is actually twice the extent that it >>> appears (i.e., it has a 50 pixel transparent border). This has to be done >>> to allow rotation handles to be added. Anyway, when it moves so that its >>> top would go beyond the top of the application, some crazy rendering effect >>> happens, as illustrated in the included screenshots. This same behavior >>> happens when moving the square to the left side of the screen. It does not >>> happen on either the right or the bottom of the screen. It seems like >>> Athens does not like for submorphs of AthensWrapMorph to extend to the left >>> or above their parent. This seems like a problem and something that can >>> easily happen as somebody moves some morph to be partially offscreen. >>> >>> >> Sounds like clipping issue. But it is hard to tell anything by looking at >> screenshots.. >> Usually all things outside of visible area should be clipped. >> Also, note that dragging, like it is done in Morphic, the dragged morph >> changes its owner to hand (handmorph).. >> and since it is only within AthensWrapMorph it is where it uses rendering >> by Athens, it could be simply the case that it don't renders at all (or >> just uses morhic rendering while held by hand). >> >> >>> Cheers, >>> >>> Jeff >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Frank Shearar

On 3 January 2014 11:24, Otto Behrens <otto(a)finworks.biz> wrote: >> #printString and #printOn: protocol should be used for printing and #asString for conversion. This implies that #asString should not depend on #print protocol. > > Ah, I used it the other way around: printOn depends on asString. I saw > 'conversion' as the lower level. > > Why do you distinguish here between conversion and 'printing'? > Especially if displayString is being replaced with asString - to me > that sounds against your thinking in principle. 'Conversion' implies using the resulting String in some further computation. 'Printing' usually implies displaying something to the user (and nothing more), or serialising to a file/network. frank

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Otto Behrens

> #printString and #printOn: protocol should be used for printing and #asString for conversion. This implies that #asString should not depend on #print protocol. Ah, I used it the other way around: printOn depends on asString. I saw 'conversion' as the lower level. Why do you distinguish here between conversion and 'printing'? Especially if displayString is being replaced with asString - to me that sounds against your thinking in principle. > If we are going to use #asString to mimic #displayString (instead of as a conversion method) then to me #asString should be viewed at a higher level abstraction than #printOn:. If not then we can run into these issues when calling the higher-level abstraction from a lower level in the same objectt, as you mentioned. Calling #printString from #asString from an API perspective should not cause issues (as displaying something is very different from converting something) so Iâd say this is an API design problem. Yes, I think the API could be clearer. So this becomes the essence of the question here: What is the meaning of these methods from an API perspective? Thanks for the response

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Carlo

Hi The summary version of my view below: #printString and #printOn: protocol should be used for printing and #asString for conversion. This implies that #asString should not depend on #print protocol. On 03 Jan 2014, at 10:33 AM, Otto Behrens <otto(a)finworks.biz> wrote: > My first assumption is that the difference between printString and > asString is that printString may be more elaborate than asString, but > often they are the same. Do you agree? >From my experience Iâd tend to agree. #asString seems to be replacing #displayString in certain scenarios (I prefer #asString to be used as more of a conversion method as per Smalltalk Best Practice Patterns) > My second assumption is one should never override printString. Rather > override printOn:. Agreed? Agreed. > In Pharo, I get infinite recursion when I override printOn: to call > asString. I get infinite recursion problems in GemStone when I > override asString and call printString. So with my strategy to develop > in Pharo and deploy in GemStone, we have to be very careful. If we are going to use #asString to mimic #displayString (instead of as a conversion method) then to me #asString should be viewed at a higher level abstraction than #printOn:. If not then we can run into these issues when calling the higher-level abstraction from a lower level in the same objectt, as you mentioned. Calling #printString from #asString from an API perspective should not cause issues (as displaying something is very different from converting something) so Iâd say this is an API design problem. > Most often, overriding printString and / or asString has to do with > performance. If we have a simple object, we don't want to override > printOn: that creates a stream, prints an instanceVariable (already a > string) to it, and then throw away the stream. Agreed on the performance reasoning for #printString. For me the issue with #asString is that we are using it as a substitute for #displayString (instead of a conversion method) but without the underlying support protocol (i.e. #displayOn:). This means any performance related overrides for #asString can cause some confusion for other developers. i.e. When overriding #asString what base selector can you rely on, something along the lines of #displayOn: protocol or the #basicXYZ family of protocols where you are stating that this is the lowest level API and must not be overridden. > 1. Keep the default printString that calls printOn:. > 2. Override asString to return a simple representation of the object, > if you have one. Don't create streams in here, or go wild with string > concatenations. Practically, many objects will return a simple string, > which could be one instVar. Agreed. Although creating a stream and calling #printOn: should be safe to do and not cause issues, although not recommended. > 3. Override printOn: to return a representation concatenating parts of > the object as strings. Use this if you want to print a more elaborate > description than asString. It should read, if you want to print a more elaborate description than default #printOn:. #asString should not have any conceptual relation to #printOn:. > 4. Change Object >> asString return âa' or 'an', class name. Agreed, but this should be implemented by delegating to #printOn: or by creating a base method akin to #basicDisplayString so there is always some base display string functionality that subtypes can rely on. (Notice that naming the method with #basicAsString doesnât really make sense which again tends to validate that we are using #asString not for conversion but more for display purposes, as in #displayString which has been deprecated via grease). > 5. Change Object >> printOn: to write self asString to the stream. No, I donât think so as per above. #asString could depend on #printOn: but not the other way around. > 6. Fix printString overrides (more work in GemStone than Pharo) #printString should depend on #printOn:. If overriding for performance then it must use simple representations wherever possible or #asString. > 7. Normally use printString, but use asString where you are concerned > about performance. In some cases, you may have a longer printStringâ¦ Use #printString always as developers would override #printString for performance if need be. Use #asString for conversion. My last statement again raises the point that #asString should be used for conversion and not for displaying or printing. We should only have a handful of #asString methods in an image but multiple implementations of #displayOn: and #printOn: These are my personal (limited) views as I only use Pharo for personal projects. Kind Regards Carlo On 03 Jan 2014, at 10:33 AM, Otto Behrens <otto(a)finworks.biz> wrote: Hi, I've run into one of my favorite problems in Smalltalk and decided to try the list. Please don't shoot me on this one; perhaps you've run into it yourself. If there are discussions that I should read, please send me some info. My first assumption is that the difference between printString and asString is that printString may be more elaborate than asString, but often they are the same. Do you agree? 1. In Pharo, the default implementation of asString is ^ self printString. 2. printString normally calls self printOn: aStream. (Pharo and GemStone. Yay, consistency!) 3. In Pharo, the default printOn: writes the class name prefixed with 'a' or 'an'. 4. In GemStone, the default implementation of printOn: writes self asString to the stream. My second assumption is one should never override printString. Rather override printOn:. Agreed? In Pharo, we have very few classes that overrides printString. One problem area is UUID. It overrides asString, printOn: and printString, with a similar approach to GemStone in printOn:. In GemStone, there's a big heap of inconsistency. Character also overrides all 3 methods, with an apparent awful inconsistency there! In Pharo, I get infinite recursion when I override printOn: to call asString. I get infinite recursion problems in GemStone when I override asString and call printString. So with my strategy to develop in Pharo and deploy in GemStone, we have to be very careful. Most often, overriding printString and / or asString has to do with performance. If we have a simple object, we don't want to override printOn: that creates a stream, prints an instanceVariable (already a string) to it, and then throw away the stream. My suggestion is that we should get consistency. Decide on a way and follow that. To me, this makes sense: 1. Keep the default printString that calls printOn:. 2. Override asString to return a simple representation of the object, if you have one. Don't create streams in here, or go wild with string concatenations. Practically, many objects will return a simple string, which could be one instVar. 3. Override printOn: to return a representation concatenating parts of the object as strings. Use this if you want to print a more elaborate description than asString. 4. Change Object >> asString return 'a' or 'an', class name. 5. Change Object >> printOn: to write self asString to the stream. 6. Fix printString overrides (more work in GemStone than Pharo) 7. Normally use printString, but use asString where you are concerned about performance. In some cases, you may have a longer printString... Well, thanks for reading this far. Looking forward to your answers. Otto

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Hilaire Fernandes

Le 03/01/2014 10:31, Marcus Denker a Ã©crit : > From then the change was made *other* changes have been done. > > âChangeâ will show *all* differences, both the ones other integrations > did to the package as well as the changes of the slice. > > In addition, there is still some bug that when e.g moving classes > the *extending* packages are bot dirty and there might be some > inconsistencies. Got it. So this is simply an usability concern with misleading button text and button tooltips, or am I the only one to fell misguided? Anyway should be easily fixable, if it should be. Thanks Hilaire -- Dr. Geo http://drgeo.eu

Jan. 3, 2014

Re: [Pharo-dev] Spotlight Demo

by Tudor Girba

Hi Sean, I just tested the new implementation. Exciting :). See below the comments and the little improvement for item count. [image: Inline image 1] But, now, we have another problem: going with up/down jumps over one items (so, you can only reach 1, 3, 5 ...). I could not figure out where the problem comes from. It only happens in the full Spotlight, but not in the completion example. On Thu, Jan 2, 2014 at 1:53 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Tudor Girba-2 wrote > > - I love it how I can navigate with up/down and still continue typing. > > This > > is seriously cool. > > :) > > > Tudor Girba-2 wrote > > - Esc has no effect ( > > I had implemented it for entry completion. It is working in SpotlighMorph > now also. > Great. Works fine. Tudor Girba-2 wrote > > - The list entries behave strangely because you use a text morph that can > > be edited. For example, type something, go with the mouse over an item in > > the list, you will see the cursor changes to a text one, click, and you > > can > > start typing there. Why not use a LabelMorph? > > I didn't use LabelMorph because it deals with strings, not text, and I want > to be able to e.g. make the matching substring bold like in the examples. > But I locked the TextMorphs, so it's fixed. > Indeed. Got it. Tudor Girba-2 wrote > > - Pressing Enter does not seem to trigger the action associated with a > > list. Only pressing double click seems to work. > > - The PluggableTextMorph at the top allows Enter. Pressing Enter leads to > > a > > line break. This is not wanted (you asked what I meant by it a field). > > - The PluggableTextMorph at the top should not indicate dirty state > > Fixed. > Works. Tudor Girba-2 wrote > > - Pressing up/down also moves the cursor in the top PluggableTextMorph. > > This should not happen. > > This should be fixed now that you can't enter a new line > It's not fixed. Try this: - type ab - move down ==> all is fine: the search morph looks like (ab|) - move up ==> the cursor in the search morph moves at the beginning (|ab) > > Tudor Girba-2 wrote > > - It would be interesting to have the count of hits even though we are > > only > > displaying a limited amount. > > Yes it would. Feel free to submit code ;) > Done. You can find it here: Gofer new smalltalkhubUser: 'girba' project: 'GPlay'; package: 'Spotlight'; load > > Tudor Girba-2 wrote > > And a question related to "Show all on down arrow when closed": > > Ah, yes. I guess this is more relevant to entry completion, but if the > completion menu is not yet open, and you press the down arrow while the > text > field has the keyboard focus, the menu will appear with all possible > results. > > Aha. Got it. Cheers, Doru > Keep the feedback coming!!! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Spotlight-Demo-tp4733076p4733615.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Jan. 3, 2014

[pharo-project/pharo-core] 441a2e: 30669

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 441a2ef1edbf4a433d65aeb7a26e24ea9a21c3a0 https://github.com/pharo-project/pharo-core/commit/441a2ef1edbf4a433d65aeb7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-03 (Fri, 03 Jan 2014) Changed paths: A Morphic-Base.package/PolygonMorph.class/class/examples/example1.st A Morphic-Base.package/PolygonMorph.class/class/examples/example2.st A Morphic-Base.package/PolygonMorph.class/class/examples/example3.st A Morphic-Base.package/PolygonMorph.class/class/examples/example4.st A Morphic-Base.package/PolygonMorph.class/class/examples/example5.st M Morphic-Base.package/PolygonMorph.class/class/instance creation/arrowPrototype.st R Morphic-Base.package/PolygonMorph.class/instance/access/borderColor_.st A Morphic-Base.package/PolygonMorph.class/instance/accessing/borderColor_.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/borderWidth_.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/fillStyle.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/fillStyle_.st R Morphic-Base.package/PolygonMorph.class/instance/accessing/makeOpenOrClosed.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/midVertices.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/smoothOrSegmentedPhrase.st M Morphic-Base.package/PolygonMorph.class/instance/accessing/step.st A Morphic-Base.package/PolygonMorph.class/instance/accessing/toggleOpenOrClosed.st R Morphic-Base.package/PolygonMorph.class/instance/attachments/boundsSignatureHash.st M Morphic-Base.package/PolygonMorph.class/instance/attachments/defaultAttachmentPointSpecs.st M Morphic-Base.package/PolygonMorph.class/instance/attachments/nudgeForLabel_.st M Morphic-Base.package/PolygonMorph.class/instance/attachments/totalLength.st M Morphic-Base.package/PolygonMorph.class/instance/caching/releaseCachedState.st M Morphic-Base.package/PolygonMorph.class/instance/cubic support/changeInSlopes_of_.st M Morphic-Base.package/PolygonMorph.class/instance/cubic support/closedCubicSlopesOf_.st M Morphic-Base.package/PolygonMorph.class/instance/dashes/borderDashOffset.st M Morphic-Base.package/PolygonMorph.class/instance/drawing/drawOnFormCanvas_.st M Morphic-Base.package/PolygonMorph.class/instance/editing/deleteVertexAt_.st M Morphic-Base.package/PolygonMorph.class/instance/editing/dropVertex_event_fromHandle_.st M Morphic-Base.package/PolygonMorph.class/instance/editing/handleColorAt_.st M Morphic-Base.package/PolygonMorph.class/instance/editing/insertVertexAt_put_.st R Morphic-Base.package/PolygonMorph.class/instance/event handling/justDroppedInto_event_.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/arrowsContainPoint_.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/flipHAroundX_.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/flipVAroundY_.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/rotationCenter.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/rotationCenter_.st M Morphic-Base.package/PolygonMorph.class/instance/geometry/scale_.st M Morphic-Base.package/PolygonMorph.class/instance/initialization/initialize.st M Morphic-Base.package/PolygonMorph.class/instance/initialization/vertices_color_borderWidth_borderColor_.st M Morphic-Base.package/PolygonMorph.class/instance/menu/addPolyLIneCurveMenuItems_hand_.st M Morphic-Base.package/PolygonMorph.class/instance/menu/addPolyShapingMenuItems_hand_.st R Morphic-Base.package/PolygonMorph.class/instance/menu/quickFill_.st M Morphic-Base.package/PolygonMorph.class/instance/shaping/diamondOval.st R Morphic-Base.package/PolygonMorph.class/instance/shaping/rectOval.st A Morphic-Base.package/PolygonMorph.class/instance/shaping/rectangleOval.st M Morphic-Base.package/PolygonMorph.class/instance/smoothing/coefficients.st M Morphic-Base.package/PolygonMorph.class/instance/smoothing/coefficientsForMoreThanThreePoints.st M Morphic-Base.package/PolygonMorph.class/instance/smoothing/slopes_.st M Morphic-Base.package/PolygonMorph.class/instance/testing/hasArrows.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/restrictedBrowseGroups_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private/isSelectedPackage_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script322.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30669.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30669 12550 MNU on Browse scoped from a Group https://pharo.fogbugz.com/f/cases/12550 12526 Change Groups/packages in Nautilus can freeze the UI https://pharo.fogbugz.com/f/cases/12526 12495 Cleaning PolygonMorph https://pharo.fogbugz.com/f/cases/12495 http://files.pharo.org/image/30/30669.zip

Jan. 3, 2014

Re: [Pharo-dev] Anyone noticed or tried Gravel?

by Stephan Eggermont

Iâve asked the author of Gravel to show it to us at Fosdem2014. He wants to, but might not be able to make it due to expected family expansion. Stephan

Jan. 3, 2014