- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

Hi stefan Should we apply that for all the announcements? Do you write tests for this? Stef > Why does every NewValueHolder have its own announcer? >> And is initializing all those unused valueHolders in initialize >> of Spec presentation classes not slow? > > Talking to Latsabben on Slack, first step: > > Name: > SLICE-Issue-18167-NewValueHolder-classvalue-should-use-rawValue-StephanEggermont.1 > Author: StephanEggermont > Time: 5 May 2016, 11:55:36.083109 am > UUID: d89767d0-5d9d-40b8-ad67-5887b22a338f > Ancestors: > Dependencies: NewValueHolder-StephanEggermont.34 > > Do not send announcements when you know there can't be any subscriptions > > >

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

Le 5/5/16 Ã 00:15, Stephan Eggermont a Ã©crit : > On 04/05/16 08:19, stepharo wrote: >> if you have ideas let us know too. > > Why does every NewValueHolder have its own announcer? > And is initializing all those unused valueHolders in initialize > of Spec presentation classes not slow? I will let peter explained. We did an experience by trying to remove the valueHolder is ButtonPresenter but it led to refresh problem when we want to update the widget. Because when you change the label of your model you want that the widget get notified and (without ghving the adapter at runtime in the middle). But the state of PluggableButtonMorph is too bad to express that the way we want. Stef > > Stephan > > > >

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

Le 4/5/16 Ã 21:26, Glenn CavarlÃ© a Ã©crit : > stepharo wrote >> cleaning Spec API. > +10 ! > just general remarks i have about Spec: Glenn send code :) > > I think the role of Spec may be clarified. > If Spec is just an UI builder we may remove the "overengineering" and we > need another framework that provides someting like MVC, MVP, MVVM or ... > If Spec intent to be an "app" framework, it is too confused now, and yes, it > needs a clear separation between the presentation, the presentation logic, > the domain logic, ... It is the second Spec should be like MVP > Maybe, extending the SpecLayout's responsibility should be one idea to > handle the full "presentation" part, like the role played by markup > languages. Yes this is one idea > I'm not saying I want to transform Spec to XML :), but its role is basically > the same. Indeed > The existing separation between the widget declarations (instance side) and > the widgets composition (class side) seem confusing to me. Totally. If you look in Deprecator (sorry bad name) you will see a new ButtonPresenter API and tests We moved all the Model adaption code into the Adapter. The goal is to remove the Adapter at runtime but for now we need better widgets. > And we need also a clearest way to bind domain models to widgets. > Using #whenSomethingChangedDo:aBlock everywhere make code a bit hard to read > and to debug, if not completly ugly in complex UI... Yes but we also need much better widgets. Because they need to - accept blocks or provide correct APIs to be able to refresh - for example we got problem because we want to be able to open a button then change its label and the label should reflected. > > For me, the first goal of an UIBuilder (graphical or programmatic) is to > ease the presentation and to ease the two-way data-binding with domain > data/logic. > If the ease-of-use of Spec is not more obvious compared to the underlying > widget libraries (Morph / Bloc soon maybe...), it will be difficult to > convince people to use it in future developments... Reuse of interaction. > > But it is maybe a bit off topic -> "cleaning Spec API". Let us start by the beginning > > Cheers, > Glenn. > > > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/call-for-cleaning-ideas-around-Spec-tp4893494p4893625… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

Le 4/5/16 Ã 19:18, Stephan Eggermont a Ã©crit : > > > On 04/05/16 18:18, stepharo wrote: >> Can you open bug entries with such points? > > 18164 Put drag-and-drop behaviour in one object We were looking and I proposed to AbstractWidgetModel ButtonModel CheckboxModel DragDropModel TabModel TreeModel ListModel > > 18165 ComposableModel: aboutText seems to be in the wrong place peter check and this is ok because like that a composable model can do the same as for title just declare aboutText and the window grab it. > > 18166 Where should focus change keystrokes be handled? > > Stephan > > >

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by stepharo

With Peter we cleaned some subscription for enabled that were register twice. https://pharo.fogbugz.com/f/cases/18175/Cleaned-up-code-duplication-in-init… Stef and Peter Le 4/5/16 Ã 18:16, stepharo a Ã©crit : > First we should clean it, then we speed it up. > > > Stef > > > Le 4/5/16 Ã 15:45, Stephan Eggermont a Ã©crit : >> On 04/05/16 13:43, Peter UhnÃ¡k wrote: >>>> >>>> by a factor of at least 2,5x compared to pure Morphic (I've seen a >>>> 5x). >>>> >>> >>> This doesn't mean anything. Can you please provide concrete numbers >>> (what >>> you experience) and what is your expected target? Because I do not have >>> such problematic experience. >> >> Thierry develops on a machine that is somewhat slower than those most >> Pharo users develop on: a Celeron 2955U machine. For Pharo I'd hope >> to be able to reasonably do development on a Raspberry Pi2. >> >> He is very aware of Morphic performance issues, so that factor 2.5 is >> not the layout processing, as that is the same for Morphic and Spec. >> >> We could add some Spec performance tests to jenkins/travis to see >> when we have regressions. >> >> Stephan >> >> >> > > >

May 8, 2016

Help on using Git with Pharo

by Alexandre Bergel

Hi! I have written a help to use Git in Pharo. Execute the following: Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load. It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help One some point, I will propose an inclusion in the base image. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 8, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Peter UhnÃ¡k

Hi, today with Stef we spent some time going through Spec. But first to address some points In AbstractWidgetModel we have > dragEnabled dropEnabled dragTransformationBlock wantDropBlock > acceptDropBlock transferBlock > That needs to be one instance variable dealing with drag and drop. We question whether this belongs to AbstractWidgetModel, as only three (TreeModel, ListModel, and TabModel (iirc)) benefit from it in any way. One option would be to have an intermediate subclass so we can move at least some of it, like this â As for separating into a separate instance variableâ¦ I agree from design perspectiveâ¦ however having directly available methods is very user-friendly when you are configuring it, because you can use a cascade. ^ TreeModel new roots: #(a b c d); childrenBlock: [:it | it = #c ifTrue: [ {1. 2. 3} ] ifFalse: [ {} ]]; dragEnabled: true; dropEnabled: true. Which is quite nice. Without it you would have to do (tm := TreeModel new) roots :#(..); childrenBlock: [ :it | ... ]. tm dragAndDrop dragEnabled: true. tm dragAndDrop dropEnabled: true. There are different ways how to have it separate and provide and nice-ish API, for example keep the messages, but delegate the behavior. Or provide a configuration block. This is for example used when you are configuring a MenuModel/MenuGroup/MenuItem. ^ TreeModel new roots: #(...); childrenBlock: [ :it | ... ]; dragAndDrop: [ :dnd | dnd dragEnabled: true; dropEnabled: true ] The same questions also applies to Styles (color, borderColor, borderWidth). Which I would prefer to remove altogether (it's not really used, and I question whether whether it even belongs to Spec side). If we want to keep it, then separating it would be a nice idea (I've started, slice in Pharo60Inbox) ComposableModel: aboutText seems to be in the wrong place. > That is a WindowModel property, and we seem to need some kind of > mechanism to propagate property access in the widget hierarchy. I though so too at first, however this is very same as #title. In fact having directly in ComposableModel is very convenient. MyFormEditor>>title ^ 'Form Editor' MyFormEditor>>aboutText ^ 'Neither #aboutText, nor #title is actually used by MyFormEditor, but by WindowModel, but it makes for nicer API' ComposableModel: keyStrokesForNextFocusHolder keyStrokesForPreviousFocusHolder > I'm pretty sure I do not want focus switch to be an individual widget concern Take a look at http://smalltalkhub.com/#!/~StephaneDucasse/Deprecator We started cleaning up the API a bit. The idea is to start from Spec side, figure out what we need and then adapt adaptorâ¦ and not try to reimplement Morphic. Right now only ButtonModel (ButtonPresenter) is done, but without shortcuts. We would like to introduce some common/uniform behavior for this instead of each Widget redoing it in a chaos. And some more cleanup sits in Pharo60Inbox... Peter On Thu, May 5, 2016 at 1:18 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 04/05/2016 19:18, Stephan Eggermont a Ã©crit : > >> >> >> On 04/05/16 18:18, stepharo wrote: >> >>> Can you open bug entries with such points? >>> >> >> 18164 Put drag-and-drop behaviour in one object >> >> 18165 ComposableModel: aboutText seems to be in the wrong place >> >> 18166 Where should focus change keystrokes be handled? >> > > For this one there was an debate about the following point: why Spec needs > to reimplement the focus change keystroke implemented by Morphic? > > Thierry > > Stephan >> >> >> >> > >

May 7, 2016

Re: [Pharo-dev] Big clap to OSSubprocess

by Mariano Martinez Peck

Thanks Alex! I did not answer your question the other day not because I did not read it but because I saw you figure it out yourself :) On Sat, May 7, 2016 at 3:53 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Easy to use, well commentedâ¦ > > Thanks Mariano! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Mariano http://marianopeck.wordpress.com

May 7, 2016

Big clap to OSSubprocess

by Alexandre Bergel

Easy to use, well commentedâ¦ Thanks Mariano! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 7, 2016

Re: [Pharo-dev] UFFIOpenGL binding and Woden is now working in Pharo 5

by Tudor Girba

Hi Ronie, Would it be possible to provide Ricky with some pointers so that he can port his CodeCity to your new binding? Cheers, Doru > On Apr 30, 2016, at 11:09 AM, Richard Wettel <wettel(a)gmail.com> wrote: > > Hi Ronie > > Thank you, that is great news! > I was talking to Doru the other day about investing some time in the OpenGL binding and you did it in the meantime. > > You are saying that it is not working like the previous binding, in that it does not provide support for creating an OpenGL context or a morphic. As far as I can tell CodeCity rendering is based on exactly that, so I was wondering if you could provide some tips on what would be needed to make CodeCity work with the new binding. > > Cheers > Ricky > > > _____________________________ > From: Ronie Salgado <roniesalg(a)gmail.com> > Sent: Friday, April 29, 2016 15:37 > Subject: [Pharo-dev] UFFIOpenGL binding and Woden is now working in Pharo 5 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, > > I made new OpenGL bindings for Pharo 5 using the UFFI (Available at: http://smalltalkhub.com/#!/~ronsaldo/UFFIOpenGL ). > > Unlike the old NBOpenGL, these new bindings make a heavy use of OSWindow SDL2 which is integrated and enabled by default in the Pharo 5 image. These bindings do not provide a way to create an OpenGL context or to create a Morphic window using OpenGL unlike NBOpenGL. > > For testing quickly OpenGL in Pharo 5, it should be enough to do the following in the playground: > > (ConfigurationOfOSWindow project version: #stable) load: 'WithOpenGLAndExamples'. > > (Smalltalk at: #OSGLExampleBasic3) new. > > As for Woden, it is now working in Pharo 5 with the UFFI. For loading Woden in a Pharo 5 image, is enough to do the following in the playground (Also available at the Woden Smalltalkhub page): > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load.(Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge. > > For an example the following script should be executed in a Playground: > > WDFPSSimpleExample6 new open. > > Greetings, > Ronie > > > -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

May 7, 2016