- Pharo-dev - lists.pharo.org

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

by Henrik Johansen

> On 09 May 2016, at 1:53 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > (Which is a neat storage format for, say, a UIBuilder) > > When you don't touch it, you don't care about it. > > The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec. > > I guess because it's written by handâ¦ I mean the array looks like bad attempt at STON. > > In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout. > > Peter Uhuh, in my mind, it seemed to get off to a kind of shaky start, and never improved. Rather than take the opportunity to design a more generic object model for widgets with a clear strategy in mind for mapping to a literal syntax, it seemed to me to have started by copy-pasting the entire API used by Morphic widgets, adding Spec in front of some of the class names, and call it a day. Slap some {}'s around where appropriate, and you have a literal syntax! The good news is, no-one in their right mind would willingly use the literal format as is, so changing it probably wouldn't cause too much of an uproar, the bad new is, all the hard work involved in creating a sensical format, still remains. It's also rather hard to make a good object model that you then later graft a literal format on top of... For instance, with the use of blocks for everything, and the weird mix of symbols and method calls: row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] I'd have no idea how to represent as a literal in an intuitive way. Cheers, Henry

May 9, 2016

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

by Esteban Lorenzano

> On 09 May 2016, at 13:45, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Yes, IIRC, the whole idea behind Spec was to have a literal syntax for specifying UI's. (Which is a neat storage format for, say, a UIBuilder) > The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec. btw, Iâve never been happy with that change :) and I agree, the original idea was to have some s-strings based description so an UI builder (to be done) could do a better job. Esteban > > Cheers, > Henry > >> On 09 May 2016, at 1:22 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>>: >> No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together. >> Regardless, there's no parsing involvedâ¦ what is there to parse? There are no literal arrays anywhere. >> The SpecLayout (that we called array last week), is not an array, it's a composition of real objects >> >> defaultSpec >> ^ SpecLayout composed >> newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ] >> height: self toolbarHeight; >> newRow: [ :row | >> row >> newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1; >> addSplitter; >> newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1; >> addSplitter; >> newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] >> top: self toolbarHeight; >> yourself >> >> Maybe array approach deprecated? But in first demos of Spec it was like this: >> >> CheckBoxExample class>>defaultSpec >> >> ^ { #ContainerModel. >> #add:. { self topSpec. #layout:. #(#SpecLayoutFrame >> bottomFraction: 0 >> bottomOffset: 20) }. >> #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } >> } >> >> (Actually it is from Pharo 5 image). >

May 9, 2016

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

by Peter UhnÃ¡k

> (Which is a neat storage format for, say, a UIBuilder) > When you don't touch it, you don't care about it. > The focus seems to have changed over time to directly using what was > initially the intermediate object model the builder generated when parsing > the spec. > I guess because it's written by handâ¦ I mean the array looks like bad attempt at STON. In any case, we can always introduce a proper DSL for layout later (or even better, have a UI builder!). Right now it's written with the spec layout. Peter

May 9, 2016

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

by Henrik Johansen

Yes, IIRC, the whole idea behind Spec was to have a literal syntax for specifying UI's. (Which is a neat storage format for, say, a UIBuilder) The focus seems to have changed over time to directly using what was initially the intermediate object model the builder generated when parsing the spec. Cheers, Henry > On 09 May 2016, at 1:22 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>>: > No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together. > Regardless, there's no parsing involvedâ¦ what is there to parse? There are no literal arrays anywhere. > The SpecLayout (that we called array last week), is not an array, it's a composition of real objects > > defaultSpec > ^ SpecLayout composed > newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ] > height: self toolbarHeight; > newRow: [ :row | > row > newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1; > addSplitter; > newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1; > addSplitter; > newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] > top: self toolbarHeight; > yourself > > Maybe array approach deprecated? But in first demos of Spec it was like this: > > CheckBoxExample class>>defaultSpec > > ^ { #ContainerModel. > #add:. { self topSpec. #layout:. #(#SpecLayoutFrame > bottomFraction: 0 > bottomOffset: 20) }. > #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } > } > > (Actually it is from Pharo 5 image).

May 9, 2016

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

by Denis Kudriashov

2016-05-09 13:37 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Wow, this is ugly. I like the real "self topSpec" call in the middle of > it. :) > > But even then, this is still a regular Pharo (dynamic) array, so no need > to parse itâ¦ but don't use it like this. :) > By parsing array I mean converting array into underlying object.

May 9, 2016

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

by Peter UhnÃ¡k

On Mon, May 9, 2016 at 1:22 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> No. Morphs are created by Adapters, Spec interpreter instantiates glues >> everything together. >> Regardless, there's no parsing involvedâ¦ what is there to parse? There >> are no literal arrays anywhere. >> The SpecLayout (that we called array last week), is not an array, it's a >> composition of real objects >> >> defaultSpec >> ^ SpecLayout composed >> newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: >> self toolbarHeight ] ] >> height: self toolbarHeight; >> newRow: [ :row | >> row >> newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 >> @ 1; >> addSplitter; >> newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ >> 1; >> addSplitter; >> newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] >> top: self toolbarHeight; >> yourself >> > > Maybe array approach deprecated? But in first demos of Spec it was like > this: > > CheckBoxExample class>>defaultSpec > > ^ { #ContainerModel. > #add:. { self topSpec. #layout:. #(#SpecLayoutFrame > bottomFraction: 0 > bottomOffset: 20) }. > #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: > 22) } > } > > (Actually it is from Pharo 5 image). > Wow, this is ugly. I like the real "self topSpec" call in the middle of it. :) But even then, this is still a regular Pharo (dynamic) array, so no need to parse itâ¦ but don't use it like this. :) Peter

May 9, 2016

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

by Denis Kudriashov

2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > No. Morphs are created by Adapters, Spec interpreter instantiates glues > everything together. > Regardless, there's no parsing involvedâ¦ what is there to parse? There are > no literal arrays anywhere. > The SpecLayout (that we called array last week), is not an array, it's a > composition of real objects > > defaultSpec > ^ SpecLayout composed > newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self > toolbarHeight ] ] > height: self toolbarHeight; > newRow: [ :row | > row > newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ > 1; > addSplitter; > newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ > 1; > addSplitter; > newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] > top: self toolbarHeight; > yourself > Maybe array approach deprecated? But in first demos of Spec it was like this: CheckBoxExample class>>defaultSpec ^ { #ContainerModel. #add:. { self topSpec. #layout:. #(#SpecLayoutFrame bottomFraction: 0 bottomOffset: 20) }. #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } } (Actually it is from Pharo 5 image).

May 9, 2016

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

by Peter UhnÃ¡k

On Mon, May 9, 2016 at 11:02 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I have maybe stupid question. Why Spec needs SpecInterpreter? If I > understand correctly it purpose is to parse literal array and create morphs > from it. Is it true? > If yes then why Spec not uses general literal array parser? (there is one > which was born from old discussion about external formats > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals) > No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together. Regardless, there's no parsing involvedâ¦ what is there to parse? There are no literal arrays anywhere. The SpecLayout (that we called array last week), is not an array, it's a composition of real objects defaultSpec ^ SpecLayout composed newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ] height: self toolbarHeight; newRow: [ :row | row newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1; addSplitter; newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1; addSplitter; newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] top: self toolbarHeight; yourself Peter > > 2016-05-04 8:19 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> >> this afternoon we will have a meeting with Peter and others to talk about >> cleaning Spec API. >> >> If you want/can join let us know >> >> else we can organise another skype. >> >> if you have ideas let us know too. >> >> Stef >> >> >> >

May 9, 2016

Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo)

by Esteban Lorenzano

> On 09 May 2016, at 11:10, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Search wise you can use GTSpotter to search help topic, I even added that myself as a plugin to GTSpotter at some point with even the ability to preview help inside GTSpotter. this would be something nice to add :) > > Look wise, sure pharo help isnt the prettiest thing but I would not it say it sucks, it does its job okish, it displays help text. yes, but we need something better, in the future. Esteban > > If you want docs that are looking very good, Pillar is doing already that and it outputs in the most portable formats, html and pdf , that makes it easy to take documentation where you cannot use pharo, on tablets and smartphones. > > As a pharo developer I am very much against of cramming things that already exist outside pharo image and do an incredible good job that would take years if not decades for pharo to catch up , instead of putting things inside to make things harder with close to zero benefit. > > Lets face it the only reason to put things inside the pharo image is with the promise that we will be modifying , improving and extending them. Documentation however is a large effort by itself , so why not instead of worrying about a Pharo Documentation API , worry about the actual documentation ? > > Personally I am more interested in reducing the complexity of Pharo and increasing its documentation than the opposite. > > Funny fact: I used to be a big proponent of onboard/in-image documentation but the great work of the Pillar devs made me change my mind completely. Pillar for me documentation wise is the way forward and it already works incredible well. I would not even complain if the help tool was completely replaced with the a link to the pillar documentation , it does not contain much documentation anyway, nowhere close to the amount and quality of documentation produced by Pillar. > > On Mon, May 9, 2016 at 10:45 AM Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > On 09 May 2016, at 09:37, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > > How about WebDoc (or similar) serving up the API with class comments to > > make it searchable on the web > > > > Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. > > Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). > > I don't think that any web interface can compete with that (unless it's powered by Pharo itself). > > > > In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. > > See http://files.pharo.org/doc/ <http://files.pharo.org/doc/> for WebDoc. > > I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers. > > > The wiki would also act as a place where the documentation can evolve > > until it is considered stable enough to include in the image. > > > > For this we have books imho. Simple documentation should be added to image. > > > > also have links to other blogs, etc. that may not be appropriate for > > in-image documentation > > > > I don't see why not, but it would be better to just copy the content without having to click (depends on the content). > >

May 9, 2016

Re: [Pharo-dev] FastTable easyList examples are broken

by Esteban Lorenzano

they work for me (latest Pharo5) > On 08 May 2016, at 21:31, stepharo <stepharo(a)free.fr> wrote: > > Hi > > > I started to play with FastTable and some of the examples are broken. > > For example exampleEasyList* > > > Stef > >

May 9, 2016