- Pharo-dev - lists.pharo.org

Another look at the [First Impression Count] in Pharo 5

by Hilaire

AMHO, there are some needed feedbacks on some tools. There are the most visible I can see, where newbies will be contemplating without understanding. I try to propose a tip, please *correct* it when wrong or incomplete. NAUTILUS - 'Scoped'-> not sure what is the extent of the Scoped, but a proposed tip: 'Browse in the context of the selected package/class: all nautilus tools -- including refactoring -- will proceed only within the selected package/class.' - 'Format as you read' -> based on Peter suggestion: 'Autoformat code without editing. Useful when reading some old/unformatted code.' - 'NW/W' -> I don't know - '+L' -> 'Toggle line number for code" SETTINGS BROWSERS - There are about 100 Spotter entries without unhelpful descriptions as: 'Trait>>#spotterReferenceFor: spotterReferenceFor: aStep <spotterOrder: 30> aStep listProcessor title: 'References'; allCandidates: [ (SystemNavigation default allReferencesTo: self binding) collect: #compiledMethod ]; itemName: [ :method | method gtDisplayString ]; filter: GTFilterSubstring' is it a bug or on purpose? However definitely not newbie friendly. If these settings are not relevant, may be hiding it. - GRAPHIC THEME It lacks contrast, (and no there is objective measure, otherwise what is design for) but I guess nothing much can be done. Tooltips lost again the blue contrasting background for a grey unconstrasting one. In the past I already fixed the Water theme from random refactoring, it is sad to see few care on the UI: this is the first thing newbies will notice even before reaching the deep beauty of Pharo, they will be gone because the first impression went wrong. Hilaire PS: Please, don't assume because I post this review I take responsibility on fixing it, I may or not. I really get this irritating feedback from my feedbacks, and I don't think pressure is helpful. We are doing our best according to our personnel life constraints. If not ok, I will shut up for ever. -- Dr. Geo http://drgeo.eu

May 5, 2016

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by Bernardo Ezequiel Contreras

Hi Esteban, I tried again and it doesn't work. :( But now i found another issue, if you take a look to pharo5.0/shared folder you will see the file PharoV40.sources (wrong version for this release) thanks On Sun, May 1, 2016 at 7:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 01 May 2016, at 10:59, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > On 30/04/16 23:13, Bernardo Ezequiel Contreras wrote: > >> Hi Esteban, > >> i found a problem with one of the packages, see below > >> > >> ** TODO This interpreter (vers. 6505) cannot read image file (vers. > 6521) > > > > So you have a non-spur vm there. You need a spur one > > yes, but Pharo5.0-linux-oldLibC.zip should download a spur vmâ¦ I need to > review that :) > > Esteban > > > > > Stephan > > > > > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

May 4, 2016

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

by Stephan Eggermont

On 05/05/16 00:23, Stephan Eggermont wrote: > On 05/05/16 00:15, Stephan Eggermont wrote: >> 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? > > Just a 50721 image I'm working in on SpecGenerator with 20 open windows: > > NewValueHolder allInstances size > 4872 > > (NewValueHolder allInstances select: [ :each | (each instVarNamed: > #announcer) numberOfSubscriptions = 0 ])size > 2566 Announcers are not designed to handle 0 or 1 subscriptions. If we want that, we need to fix them Stephan

May 4, 2016

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

by Stephan Eggermont

On 05/05/16 00:15, Stephan Eggermont wrote: > 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? Just a 50721 image I'm working in on SpecGenerator with 20 open windows: NewValueHolder allInstances size 4872 (NewValueHolder allInstances select: [ :each | (each instVarNamed: #announcer) numberOfSubscriptions = 0 ])size 2566

May 4, 2016

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

by Stephan Eggermont

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? Stephan

May 4, 2016

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

by Glenn CavarlÃ©

stepharo wrote > cleaning Spec API. +10 ! just general remarks i have about Spec: 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, ... Maybe, extending the SpecLayout's responsibility should be one idea to handle the full "presentation" part, like the role played by markup languages. I'm not saying I want to transform Spec to XML :), but its role is basically the same. The existing separation between the widget declarations (instance side) and the widgets composition (class side) seem confusing to me. 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... 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... But it is maybe a bit off topic -> "cleaning Spec API". 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 4, 2016

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

by Stephan Eggermont

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? Stephan

May 4, 2016

Re: [Pharo-dev] PhD Thesis offer

by stepharo

looks like a job for mOose :) Le 4/5/16 Ã 12:37, jannik laval a Ã©crit : > Dear friends, > > I am looking for a french student (or someone speaking french) who > wants to engage in a CIFRE PhD thesis (it is a thesis with a french > company). > > The subject is attached to the mail. > > Best regards, > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info

May 4, 2016

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

by stepharo

***Thanks*** Stephan this is the kind of things we should start fixing!!! I want more :). Can you open bug entries with such points? Stef Le 4/5/16 Ã 16:03, Stephan Eggermont a Ã©crit : > > > On 04/05/16 08:19, stepharo wrote: >> Hi guys >> >> >> this afternoon we will have a meeting with Peter and others to talk >> about cleaning Spec API. > > In AbstractWidgetModel we have > dragEnabled dropEnabled dragTransformationBlock wantDropBlock > acceptDropBlock transferBlock > > That needs to be one instance variable dealing with drag and drop. > > 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. > > ComposableModel: keyStrokesForNextFocusHolder > keyStrokesForPreviousFocusHolder I'm pretty sure I do not want > focus switch to be an individual widget concern > > Stephan > > >

May 4, 2016

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

by stepharo

I would rename composableModel into Presenters. Stef Le 4/5/16 Ã 16:58, Stephan Eggermont a Ã©crit : > On 04/05/16 16:10, Denis Kudriashov wrote: >> 2016-05-04 15:34 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: >> >>> There are too many Models. A clear distinction between DomainModel >>> and ViewModel is needed. Please explain when a ViewController should >>> be a Presenter. Where is the boundary between MVC and MVP? >>> >> >> But there is good article about it >> http://www.object-arts.com/downloads/papers/TwistingTheTriad.PDF >> > > I know. But that is not what Spec does. > > Stephan > > >

May 4, 2016