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

[pharo-project/pharo-core]

by GitHub

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

Jan. 6, 2014

[pharo-project/pharo-core] 45e33a: 30674

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 45e33a30e7c61460d3c0f69b5ec5f7f5e29d4720 https://github.com/pharo-project/pharo-core/commit/45e33a30e7c61460d3c0f69b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-06 (Mon, 06 Jan 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script327.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30674.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/LabelModel.class/instance/protocol/emphasis_.st A Spec-Core.package/MenuModel.class/instance/protocol/openWithSpecAt_.st A Spec-Core.package/TextModel.class/instance/protocol-errors/notify_at_in_.st M Spec-Core.package/TextModel.class/instance/protocol/accept_notifying_.st A Spec-MorphicAdapters.package/MorphicLabelAdapter.class/instance/spec protocol/emphasis_.st A Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/spec protocol/openAt_.st A Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/spec protocol/notify_at_in_.st M Spec-MorphicAdapters.package/MorphicTextAdapter.class/instance/widget API/accept_notifying_.st A Spec-MorphicAdapters.package/MorphicTextInputFieldAdapter.class/instance/initialization/adapt_.st Log Message: ----------- 30674 12569 TextModel should not move scroll when accepting text https://pharo.fogbugz.com/f/cases/12569 http://files.pharo.org/image/30/30674.zip

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by StÃ©phane Ducasse

I will read it. I do not like the UITheme. I was more interested by the pattern. Stef On 06 Jan 2014, at 10:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Doru > > do you have a sketch (UML) to see how it works? > Because indeed having a pattern for the theme is definitively important and Iâm sad that the same trick > as the settings do not work for theme. > > Stef > > On 06 Jan 2014, at 00:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi again, >> >> I added a first shot at theming. The idea is simple: >> - we have one method in UITheme called spotterThemer that simply returns a SpotterThemer, and >> - all Spotter/Spotlight specific rendering methods are in SpotterThemer >> >> I think this should be the design to follow for all morphs. I blogged about it in more details here: >> http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them… >> >> >> You can get the code from here: >> Gofer new >> smalltalkhubUser: 'girba' project: 'GPlay'; >> package: 'Spotlight'; >> disablePackageCache; >> load >> >> In summary, something like: >> >> SpotlightItemMorph>>onSelected >> self color: (Color r: 0.2627 g: 0.4588 b: 0.9333). >> >> becomes: >> >> SpotlightItemMorph>>onSelected >> self theme spotterThemer configureSelectedItemMorph: self >> >> And the default SpotterThemer says: >> >> SpotterThemer>>configureSelectedItemMorph: aMorph >> aMorph color: (Color r: 0.2627 g: 0.4588 b: 0.9333) >> >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >> >> On Sun, Jan 5, 2014 at 9:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Sean, >> >> I just tested it. It works just great. >> >> First, would it be Ok with you to move the project to a more public place (like http://www.smalltalkhub.com/#!/~PharoExtras) so that others can contribute easier? >> >> Second, I created a configuration with a development and stable version. You can find it here: >> Gofer new >> smalltalkhubUser: 'girba' project: 'GPlay'; >> package: 'ConfigurationOfSpotter'; >> load. >> (Smalltalk globals at: #ConfigurationOfSpotter) >> loadStable >> >> And in the MetaRepoForPharo30 so that you can load it from the Configuration Browser. Please note that I named the configuration Spotter, because there already exists a ConfigurationOfSpotlight for the widget of Esteban. Would it be Ok to change the name of the classes, too, to avoid confusion? >> >> Third, I think we should not mix the morph with the global shortcut. I understand this is convenient, but these should pretty much be different projects. Is that Ok with you? >> >> Fourth, I would like to theme this morph, too :). With this occasion, I would like to try a slightly different design for handling the theme code. I will follow up on this in another mail. >> >> Doru >> >> >> On Sat, Jan 4, 2014 at 5:42 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> I'm happy for now. As a general purpose completion option, I'd say we're >> officially at version 1.0. No obvious bugs, and provides the basic features >> I'd want. >> >> As for replacing the existing Spotlight, I've decided to eat my own dog food >> and use the new tool in my images: >> *** n.b., if you load the Spotlight package now, it will override the >> global Spotlight shortcut >> >> p.s. Steph, I added packages to the example for you ;) â¦ >> <http://forum.world.st/file/n4734153/Screen_Shot_2014-01-04_at_11.18.57_AM.p…> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spotlight-Demo-tp4733076p4734153.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Sebastian Sastre

On Jan 6, 2014, at 12:00 PM, Otto Behrens <otto(a)finworks.biz> wrote: >> I don't really understand why. How would you distinguish between which >> (kinds of) core objects and which not? Will you not end up with a >> displayString on Object again? >> >> >> You will not know all the 'why's in advance. The concrete answer is in the >> next developer's creativity. >> >> What you can do in advance is to ask 'why not?' > > Well, then we can argue why not put 'foo' on Object. I think we should > try to get to a good API with concrete meaning. And preferably on > Object, there should be as few methods as possible that can be > interpreted in as many ways as you want. > >> And a reason that comes to mind to answer that is: >> >> because >> 1) what are the odds to NOT needing to perceive an object? > > And how would I perceive a complex object through a string? Would I > then display multiple lines with all the data contained in the object? > Chip implants in my brain are out of the question so the first obvious thing will be by some kind of visual perception of its name regardless of the medium. The degree of complexity is irrelevant. You can't beat complexity with complexity. Smalltalk was done to beat complexity with simplicity. The most complex object graph can have a simple string representation of its root >> 2) what's the most obvious way to make objects perceivable one if not >> displayed as a string in some kind of >> screen/device/hologram/network-proocol/whatever? > > I think this is the core of the issue. We can't have a single > 'displayString' interface that cater for all of these requirements / > contexts. That's where the visitor pattern comes in - where the > "whatevers" can decide for themselves how best to represent the object > depending on the context. This is especially true when the object / > object graph becomes more complex. > You're right that you canNOT satisfy all interpretations of a graph. But what you CAN do is to set a starting point. Use the most obvious (popular) way to represent it and let creative minds deal with its own problems (and solutions) what that's isn't enough > Perhaps I'm misunderstanding the word 'perceive' here, but in my world > it can be widely interpreted, depending on the perspective of the > viewer. And 'screen/device/hologram/network-protocol/whatevers are all > quite different perspectives. > answered in previous paragraph > This is why I think that displayString is even for my 'DomainObject' > above a bit suspect. What if I want to display it differently (in the > same application), but in different views? > answered in previous paragraph

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Otto Behrens

> I don't really understand why. How would you distinguish between which > (kinds of) core objects and which not? Will you not end up with a > displayString on Object again? > > > You will not know all the 'why's in advance. The concrete answer is in the > next developer's creativity. > > What you can do in advance is to ask 'why not?' Well, then we can argue why not put 'foo' on Object. I think we should try to get to a good API with concrete meaning. And preferably on Object, there should be as few methods as possible that can be interpreted in as many ways as you want. > And a reason that comes to mind to answer that is: > > because > 1) what are the odds to NOT needing to perceive an object? And how would I perceive a complex object through a string? Would I then display multiple lines with all the data contained in the object? > 2) what's the most obvious way to make objects perceivable one if not > displayed as a string in some kind of > screen/device/hologram/network-proocol/whatever? I think this is the core of the issue. We can't have a single 'displayString' interface that cater for all of these requirements / contexts. That's where the visitor pattern comes in - where the "whatevers" can decide for themselves how best to represent the object depending on the context. This is especially true when the object / object graph becomes more complex. Perhaps I'm misunderstanding the word 'perceive' here, but in my world it can be widely interpreted, depending on the perspective of the viewer. And 'screen/device/hologram/network-protocol/whatevers are all quite different perspectives. This is why I think that displayString is even for my 'DomainObject' above a bit suspect. What if I want to display it differently (in the same application), but in different views?

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Sebastian Sastre

On Jan 6, 2014, at 11:31 AM, Otto Behrens <otto(a)finworks.biz> wrote: >> Some core objects (Blocks, CompiledMethods, etc.) could benefit from >> having a developer string representation (#printString) and a UI >> string representation (#displayString). > > I don't really understand why. How would you distinguish between which > (kinds of) core objects and which not? Will you not end up with a > displayString on Object again? You will not know all the 'why's in advance. The concrete answer is in the next developer's creativity. What you can do in advance is to ask 'why not?' And a reason that comes to mind to answer that is: because 1) what are the odds to NOT needing to perceive an object? 2) what's the most obvious way to make objects perceivable one if not displayed as a string in some kind of screen/device/hologram/network-proocol/whatever?

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Esteban A. Maringolo

2014/1/6 Otto Behrens <otto(a)finworks.biz>: >>> I need for example a string representation of objects generally to >>> display in anchors in our seaside application. We have a class >>> DomainObject from which most of our classes inherit, so this is >>> probably the place to add a 'displayString' for something like this. >> >> Not necessarily domain objects only. >> >> Some core objects (Blocks, CompiledMethods, etc.) could benefit from >> having a developer string representation (#printString) and a UI >> string representation (#displayString). > > I don't really understand why. How would you distinguish between which > (kinds of) core objects and which not? Will you not end up with a > displayString on Object again? Yes, I want displayString on Object. What I don't like is #asString in Object. I want to be able to do: Transcript show: anyObject displayString. Without getting a single quoted output if anyObject was a String. Regards.

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Otto Behrens

>> I need for example a string representation of objects generally to >> display in anchors in our seaside application. We have a class >> DomainObject from which most of our classes inherit, so this is >> probably the place to add a 'displayString' for something like this. > > Not necessarily domain objects only. > > Some core objects (Blocks, CompiledMethods, etc.) could benefit from > having a developer string representation (#printString) and a UI > string representation (#displayString). I don't really understand why. How would you distinguish between which (kinds of) core objects and which not? Will you not end up with a displayString on Object again?

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Sebastian Sastre

On Jan 6, 2014, at 10:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> DomainObject from which most of our classes inherit, so this is >> probably the place to add a 'displayString' for something like this. > > Not necessarily domain objects only. > > Some core objects (Blocks, CompiledMethods, etc.) could benefit from > having a developer string representation (#printString) and a UI > string representation (#displayString). +1 sebastian o/

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Camille Teruel

On 6 janv. 2014, at 13:30, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > You may need to do this if you are using proxies. The fact that #== is not sent is actually really useful for proxies. Because if #== were intercepted by the proxy and forwarded to the target then there is no straightforward way to make the distinction between two proxies on the same object. And if messing with identity breaks all weak maps used for caching proxies. > > Alexandre > > > On Jan 6, 2014, at 8:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 6 January 2014 10:56, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> Hello, >> >> here I have a class >> >> A>>== >> ^ true >> >> Now: >> a := A new. >> b := A new. >> a == b "Answers false" >> a perform: #== with: b "Answers true" >> >> Do I have to remove the usage of the byte code for #== in the compiler to be able to override == ? >> >> >> may i ask why you need to override it? >> >> >> -- >> Best regards, >> Igor Stasenko. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 6, 2014