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

Re: [Pharo-users] MOOC offline download

by Ben Coman

On Fri, Apr 28, 2017 at 5:11 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi ben > > I do not really get the request? > Because people can download the file and the portal. > I could not find a whole zip file of entire course, only the individual files which would be a pain to download, and did not know of the git repo. Peter's suggestion should works fine. Consider the case that someone is stocking up on reading material before going on a trip with limited internet access. cheers -ben > 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

Dark theme and white vs. green color

by Juraj Kubelka

Hi, While we were improving the DiffMorph for the dark theme, we conclude that it is much harder to read the text. I personally also often miss a new debugger window on a big screen. Something I have not experienced before. And this discussion reminds me the old computers where the background was black and text green. There are two screenshot to compare it: A personally feel that it is much easier to read the green text. What do you think? Juraj

April 28, 2017

Voyage - collecting data from Mongo

by Mark Rizun

Hi, Is it possible to retrieve data from Mongo collection if it was not created via Voyage? Meaning that I do not have a class in Pharo that would correspond to said collection (should I implement one?). Cheers, Mark -- View this message in context: http://forum.world.st/Voyage-collecting-data-from-Mongo-tp4944784.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 28, 2017

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

by Denis Kudriashov

2017-04-28 12:58 GMT+02:00 bachitoph <cj-bachinger(a)gmx.de>: > Is there any recommendation about the different morphs. What is the best > button, droplist, input field .., because this is a great bulk of classes. > For input field look at Twisty http://forum.world.st/ANN-Twisty-text-with-active-state-framework-td4863625…

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

2017-04-28 12:59 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-04-28 12:26 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > >> > backend specific like createMorphicView: and we need hierarchy of >> backends >> > here which will choose appropriate message. >> >> Which is exactly what we do not want, to directly bind model to the view; >> but I feel I am missing your point, can you rephrase it please? > > > This is exactly what I mean. Now there is no cases where anybody defines > special adapter for existing model. And you can't do it because then you > will need modify global MorphicAdapterBindings to specify new morph class. > And my sentence was: if we now live with that then we can simplify design > a lot by directly asking model for a view. It will be still > platform independent because concrete backend will use specific message > like createMorphicView or createCocoaView. > And it is not too far from supporting multiple view. Imaging that we have ItemSelectionModel. It can be shown as comboBox, radio button group or list. In spec methods ( #defaultSpec) we can use logical name for views: #comboBoxView, #radioGroupView, #listView. Then spec interpreter will call this methods on current backend which will return view instances. MorphicBackend will return concrete morph instances. Then view will be passed to model for initialisation: view := backend perform: spec viewName. model showItemsOn: view. view layoutWith: spec layout. Example is of course simplistic but I hope it shows that we can model spec without extra adapter component.

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

2017-04-28 12:26 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > 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. > > This depends heavily on what the respective APIs provide. > > In TabAdapter I connect SpecTab and MorphicTab directly, so it no longer > lives during runtime. > > In LabelAdapter the emphasis is being transcoded from symbol to random > numbers (so this is not simple delegation) > In MenuItemAdapter you can see much more behavior. All they do is asking model about set of options. For example menu adapter ask self model autoRefresh ifTrue: ifFalse: And this logic can be moved to model itself and represented by different model classes if necessary. (I talk about model as a presenter)

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Denis Kudriashov

2017-04-28 12:26 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > > backend specific like createMorphicView: and we need hierarchy of > backends > > here which will choose appropriate message. > > Which is exactly what we do not want, to directly bind model to the view; > but I feel I am missing your point, can you rephrase it please? This is exactly what I mean. Now there is no cases where anybody defines special adapter for existing model. And you can't do it because then you will need modify global MorphicAdapterBindings to specify new morph class. And my sentence was: if we now live with that then we can simplify design a lot by directly asking model for a view. It will be still platform independent because concrete backend will use specific message like createMorphicView or createCocoaView.

April 28, 2017

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

by bachitoph

Hi Esteban, >>why you say you cannot doit with Spec? As I understand Spec it depends on a SpecLayout which uses columns and rows instead of rectangles. Is there any way to define in Spec a dialog with explicite setting to any control view, something like aControlMorph bounds: (50@50 extent: 100@30). >>Using a FTTableMorph (or FTEasyListMorph), which are the ones I recommend you to use, you would do something like this: I will give it a try. Is there any recommendation about the different morphs. What is the best button, droplist, input field .., because this is a great bulk of classes. 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] improving audio/video quality of pharo days recordings

by Stephane Ducasse

Ok we will have a mic now I do not know how to record it. On Thu, Apr 27, 2017 at 5:18 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Peter Uhnak wrote > > clip-on microphone > > Yes! Even a cheap lapel mic like the Sony ECM-CS3 would make a world of > difference > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ > improving-audio-video-quality-of-pharo-days-recordings- > tp4944070p4944334.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 28, 2017

Re: [Pharo-users] Spec Adapter Advice

by Peter Uhnak

On Fri, Apr 28, 2017 at 11:50:48AM +0200, Denis Kudriashov wrote: > 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. This depends heavily on what the respective APIs provide. In TabAdapter I connect SpecTab and MorphicTab directly, so it no longer lives during runtime. In LabelAdapter the emphasis is being transcoded from symbol to random numbers (so this is not simple delegation) In MenuItemAdapter you can see much more behavior. So the naming is appropriate, but it is overall poorly connected. > 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. As I've shown in my previous answer this is not the case. The connection is done via the class-side spec method where you can specify any class at all; MorphicAdapterBindings is just a convenience, you can put there whatever you want. Likewise when you are composing widgets, you can specify what layout to use, something like (don't remember the precise naming out of my head) ^ SpecRowLayout composed add: #textModel withSpec: #cocoaSpec > But it not works. I've used it several times so it does work, if you had troubles then maybe it doesn't work with all models. > 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. Which is exactly what we do not want, to directly bind model to the view; but I feel I am missing your point, can you rephrase it please? > > 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. When you go the the internals, then depending on the context spec can mean: spec layout, adapter, spec model; and in some parts all contexts overlap, so it's fun to read. :) Now Pharo 7 will have new SpecInterpreter (it took me two weeks and I've created two extra tools to understand the old one and there are still some special exceptions), so then we can rethink the way it is done. Peter > > 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