April 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec Adapter Advice

by Peter Uhnak

Hi Rob, > I need to find a good starting point because you can't poke at the existing > code too much since even the debugger is built with Spec! I don't know what Pharo you are on, but this is not the case. Debugger itself is based on Glamour (there used to be SpecDebugger, but it is no longer used). What is blowing up on you is the predebugger window, which is in Spec. You can disable this in your settings or by calling GTGenericStackDebugger alwaysOpenFullDebugger: true this will skip the debugger. But keep in mind that other tools might be using spec too (like the Browser window that opens when you are listing senders/implementors. overriding the #windowClass (or whatever the name was) is a good start. (also FML because apparently I've deleted my image with my spec changes by accident -_-) Peter > > It's pretty exciting, though, because it feels like all the right pieces > are there and a lot of this could mostly be "just work" once I get going. > > Thanks again, > > Rob > > On Thu, Apr 27, 2017 at 6:04 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > Hi Rob, > > > > I guess the best resource at the moment is to just look at existing > > adapters. > > > > But here are some thoughts to get you started: > > > > (Spec) ComposableModel has as its widget (Spec) Adapter > > Adapter has as its widget the actual visual component, which currently > > means Morphic. > > > > > > The simplest example: LabelModel > > > > 1. model to adapter > > > > LabelModel is adapted by MorphicLabelAdapter: > > > > you can see on the class side in method `defaultSpec`. > > There is only `LabelAdapter` there because there is some extra mapping for > > some classes, but you can specify directly the class of the Adapter, so the > > following would work just as well: > > > > LabelModel class>>defaultSpec > > <spec> > > > > ^ #(MorphicLabelAdapter > > adapt: #(model)) > > > > > > LabelModel -> LabelAdapter direct event propagation (pushing changes) > > > > in Model world you can call changed:with: to execute code on the Adapter, > > e.g. > > > > self changed: #emphasis: with: {emphasis} > > > > which in turn will call the #emphasis: method on the LabelAdapter. > > > > LabelModel -> LabelAdapter events (pulling changes) > > > > preferred alternative is to do the opposite; properties of models are > > often held in ValueHolders, which can be observed on ValueChange, so the > > Adapter can register to event change and react on itself; > > > > you can see this best in MorphicTabAdapter (but you will see that > > TabAdapter looks a bit different from the rest, because I was experimenting > > with cleaning up Adapters...) > > > > 2. adapter to morphic > > > > Every adapter implements #buildWidget method that returns a Morphic Object. > > Typically the adapter registers itself as the model of the adapter (so > > adapter's model is Spec, and Morphic's model is the adapter). This depends > > a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so > > there's no buildWidget, and it is in #buildWidgetWith:). > > > > It is all kinds of messy, but if you have other widgets then it will be a > > good test how well Spec can handle it... or rather we'll see how it can be > > improved... > > > > Peter > > > > > > > > On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote: > > > Hello, > > > > > > I have recently been lucky enough to get the Cocoa portion of Mars > > working > > > on Pharo 5.0. While there are some issues, it has a wonderful set of > > > examples that allowed me create new Cocoa classes and delegate methods > > and > > > see a straightforward path to learning how to use Coco widgets from > > Pharo. > > > > > > I'd like to do that by creating appropriate Spec adapters, but > > > unfortunately the new Spec booklet wasn't designed for that! > > > > > > Can anyone give me any insight into creating (and using) a new Spec > > > adapter? Maybe just some high level steps to help me orient my > > > investigation into how Spec works? > > > > > > Thank you, > > > > > > Rob > > > >

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

>From design point of view I think we should remove adapters at all. They bring parallel hierarchy which is always bad. In fact they are not adapters. They are factories which creates backend views (morphs). And now there are completely no logic behind them: every adapter just passes state received from model to view instance. I think full hierarchy of adapters can be easily substituted by single backend factory class like MorphicViewFactory. Every model will ask it to create concrete view instance. Actually I have another idea: we do not need this factory at all. Now Spec allows very restricted relationship between model and view. We can only have single kind of view per model (MorphicAdapterBindings defines this relation). There is no way to use different kind of views for same model in single application. Maybe current design tried to address this issue. But it not works. And interesting that all Spec based tools do not require such kind of flexibility which means that it is not really an issue. Now you can imaging that if we always use same view class for same model class then we can directly ask model to instantiate view. Message can be backend specific like createMorphicView: and we need hierarchy of backends here which will choose appropriate message. P.S. Every time I read word model in Spec I feel something bad. It should be named to presenter. But it is quite difficult due to compatibility. And I am not sure that others agree with this. 2017-04-28 0:04 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi Rob, > > I guess the best resource at the moment is to just look at existing > adapters. > > But here are some thoughts to get you started: > > (Spec) ComposableModel has as its widget (Spec) Adapter > Adapter has as its widget the actual visual component, which currently > means Morphic. > > > The simplest example: LabelModel > > 1. model to adapter > > LabelModel is adapted by MorphicLabelAdapter: > > you can see on the class side in method `defaultSpec`. > There is only `LabelAdapter` there because there is some extra mapping for > some classes, but you can specify directly the class of the Adapter, so the > following would work just as well: > > LabelModel class>>defaultSpec > <spec> > > ^ #(MorphicLabelAdapter > adapt: #(model)) > > > LabelModel -> LabelAdapter direct event propagation (pushing changes) > > in Model world you can call changed:with: to execute code on the Adapter, > e.g. > > self changed: #emphasis: with: {emphasis} > > which in turn will call the #emphasis: method on the LabelAdapter. > > LabelModel -> LabelAdapter events (pulling changes) > > preferred alternative is to do the opposite; properties of models are > often held in ValueHolders, which can be observed on ValueChange, so the > Adapter can register to event change and react on itself; > > you can see this best in MorphicTabAdapter (but you will see that > TabAdapter looks a bit different from the rest, because I was experimenting > with cleaning up Adapters...) > > 2. adapter to morphic > > Every adapter implements #buildWidget method that returns a Morphic Object. > Typically the adapter registers itself as the model of the adapter (so > adapter's model is Spec, and Morphic's model is the adapter). This depends > a lot on the API of morphic. (in TabAdapter I'm overriding adapt: so > there's no buildWidget, and it is in #buildWidgetWith:). > > It is all kinds of messy, but if you have other widgets then it will be a > good test how well Spec can handle it... or rather we'll see how it can be > improved... > > Peter > > > > On Thu, Apr 27, 2017 at 05:10:39PM -0400, Rob Rothwell wrote: > > Hello, > > > > I have recently been lucky enough to get the Cocoa portion of Mars > working > > on Pharo 5.0. While there are some issues, it has a wonderful set of > > examples that allowed me create new Cocoa classes and delegate methods > and > > see a straightforward path to learning how to use Coco widgets from > Pharo. > > > > I'd like to do that by creating appropriate Spec adapters, but > > unfortunately the new Spec booklet wasn't designed for that! > > > > Can anyone give me any insight into creating (and using) a new Spec > > adapter? Maybe just some high level steps to help me orient my > > investigation into how Spec works? > > > > Thank you, > > > > Rob > >

April 28, 2017

Re: [Pharo-users] Basic controls <Normal List> does not change selection

by Esteban Lorenzano

Hi, why you say you cannot doit with Spec? If I understand correctly, what you want to do is to attach the windows you do to the Pharo world. For doing that with Spec you would do something like this: myMorph := mySpecModel buildWithSpec. World addMorph: myMorph fullFrame: LayoutFrame identity. myMorph beSticky. (also you have to change the layout of myMorph, etc.) anywayâ¦ the other thing you ask is how to attach one list to another? Letâs say you have listA and listB, you want to change selection on listB when listA changes? That you have to doit listening the change event. Using a FTTableMorph (or FTEasyListMorph), which are the ones I recommend you to use, you would do something like this: listB := FTEasyListMorph new elements: myElementsForB; display: [ :each | each asString ]; yourself. listA := FTEasyListMorph new elements: myElementsForA; display: [ :each | each asString ]; onAnnouncement: FTSelectionChanged do: [ :ann | listB selection: newSelectionForB ]; yourself. then you can add your list morph whenever you want. hope this helps :) Esteban > On 28 Apr 2017, at 10:57, bachitoph <cj-bachinger(a)gmx.de> wrote: > > Hello, > > porting my digitalk / dolphin application to pharo (www.trimfox.com) I have > to port my dialog creation part. Unfortunately I can't use Spec because my > dialog creation depends on boundingBox: (Pharo bounds:) by calculation > position and extent in pixels. So I have to use Morphic. There is the nice > class WidgetExamples which helped me very much. But the Normal List control > does not change selection if there is a click on another item. You can see > the behavior evaluating the code below, and click maybe on the <Two> item. > Same behavior in my Dialog class. Any hint! > > WidgetExamples exampleBasicControls > > thanks > cjb > > > > -- > View this message in context: http://forum.world.st/Basic-controls-Normal-List-does-not-change-selection-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 28, 2017

Re: [Pharo-users] Modal Menu in Pharo5

by bachitoph

Peter Thanks, that's it :) cjb -- View this message in context: http://forum.world.st/Re-Modal-Menu-in-Pharo5-tp4944703p4944716.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 28, 2017

Re: [Pharo-users] Modal Menu in Pharo5

by PBKResearch

Christoph It looks as though MenuMorph>>invokeModal should do what you want. The method comment has a useful code demo. HTH Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Christoph J. Bachinger Sent: 28 April 2017 09:25 To: pharo-users(a)lists.pharo.org. Subject: [Pharo-users] Modal Menu in Pharo5 Hello, I'm looking for a modal menu. It should stop method code execution until any left mouse klick. I tried MenuMorph with code like below, but this does not stop execution. Any hint? thank you cjb ComposableModel subclass: #BachitophTestWindow instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Trimfox'. BachitophTestWindow compile: 'initializeWidgets'. |window menu choice| window := BachitophTestWindow new openWithSpecLayout: SpecLayout composed. menu := MenuMorph new defaultTarget: window; color: (window theme menuColorFor: window); addToggle: 'abcabcabcabc' target: window selector: #yourself"(labels at: 1)"; addToggle: 'cdfgcdfgcdfg' target: window selector: #yourself; addLine; addToggle: 'hijkhijkhijk' target: window selector: #yourself; yourself. choice := menu popUpInWorld. choice selectedItem isNil ifTrue: [ choice := 'abc' ] ifFalse: [choice := choice selectedItem contents]. self halt.

April 28, 2017

Re: [Pharo-users] MOOC offline download

by Stephane Ducasse

Hi ben I do not really get the request? Because people can donwload the file and the portal. I wanted to get a CD delivery services but I failed to find one (because I have all the files to be uploaded). Stef On Thu, Apr 27, 2017 at 5:50 PM, Ben Coman <btc(a)openinworld.com> wrote: > I was just chatting with someone with limited Internet who was looking to > odownload the mooc files [1] for use offline. Does such exist? > > [1] http://files.pharo.org/mooc > > cheers -ben >

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

Hi Ben 2017-04-28 4:32 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > Would your remote IDE [1] be suitable to help Rob to hack around Spec > without blowing up his IDE? > Yes. But I think it is easy to just use Calypso tools to hack Spec. Calypso not depends on Spec. And it would be not a problem to break Spec based MessageBrowser. To use remote tools generally refactorings should be fixed. Right now they are not working from remote browser. > But I think its only available on Pharo 6? > Yes. > > [1] http://forum.world.st/Ann-PharmIDE-Pharo-remote-IDE-to- > develop-farm-of-Pharo-images-remotely-td4930602.html >

April 28, 2017

Basic controls <Normal List> does not change selection

by bachitoph

Hello, porting my digitalk / dolphin application to pharo (www.trimfox.com) I have to port my dialog creation part. Unfortunately I can't use Spec because my dialog creation depends on boundingBox: (Pharo bounds:) by calculation position and extent in pixels. So I have to use Morphic. There is the nice class WidgetExamples which helped me very much. But the Normal List control does not change selection if there is a click on another item. You can see the behavior evaluating the code below, and click maybe on the <Two> item. Same behavior in my Dialog class. Any hint! WidgetExamples exampleBasicControls thanks cjb -- View this message in context: http://forum.world.st/Basic-controls-Normal-List-does-not-change-selection-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 28, 2017

Modal Menu in Pharo5

by Christoph J. Bachinger

Hello, I'm looking for a modal menu. It should stop method code execution until any left mouse klick. I tried MenuMorph with code like below, but this does not stop execution. Any hint? thank you cjb ComposableModel subclass: #BachitophTestWindow instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Trimfox'. BachitophTestWindow compile: 'initializeWidgets'. |window menu choice| window := BachitophTestWindow new openWithSpecLayout: SpecLayout composed. menu := MenuMorph new defaultTarget: window; color: (window theme menuColorFor: window); addToggle: 'abcabcabcabc' target: window selector: #yourself"(labels at: 1)"; addToggle: 'cdfgcdfgcdfg' target: window selector: #yourself; addLine; addToggle: 'hijkhijkhijk' target: window selector: #yourself; yourself. choice := menu popUpInWorld. choice selectedItem isNil ifTrue: [ choice := 'abc' ] ifFalse: [choice := choice selectedItem contents]. self halt.

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Stephane Ducasse

This is a cool news. We could have a new adapter for Mars. I'm really interested in getting this working. Stef On Thu, Apr 27, 2017 at 11:10 PM, Rob Rothwell <r.j.rothwell(a)gmail.com> wrote: > Hello, > > I have recently been lucky enough to get the Cocoa portion of Mars working > on Pharo 5.0. While there are some issues, it has a wonderful set of > examples that allowed me create new Cocoa classes and delegate methods and > see a straightforward path to learning how to use Coco widgets from Pharo. > > I'd like to do that by creating appropriate Spec adapters, but > unfortunately the new Spec booklet wasn't designed for that! > > Can anyone give me any insight into creating (and using) a new Spec > adapter? Maybe just some high level steps to help me orient my > investigation into how Spec works? > > Thank you, > > Rob > > >

April 28, 2017