- Pharo-users - lists.pharo.org

Re: [Pharo-users] On GUI design and how to benchmark it

by Thierry Goubier

Hi Sebastian, yes, I think some of it is interesting, and the way he focuses on a few benchmarks is not a bad way of classifying GUIs (and toolkits). You just have to remember that his focus is a lot more limited than expected at start: " ... In this thesis we want to investigate if the conclusion of the work on Biglook still holds true or if there are yet novel areas where FP can improve upon OOP in terms of GUI programming and what happens if OOP is completely taken out of the picture " Where Biglook is : " Probably the most directly related paper is âProgramming Graphical User Interfaces with Schemeâ [18] from 2003 that presents the widget library Biglook that combines object-oriented and classical functional styles for GUI programming " Which is later explained as OOP + Continuations (i.e. Smalltalk-80 style MVC GUI toolkit with blocks). What is generally worrying me in papers on GUI coming from the FP community (and this is not the first one I've seen) is that they are still trying onto recreating properly at best, in FP, the GUIs of the 80's (that is, MVC) (and they have to recreate because they don't want to admit that past great GUIs in FP were done in an abomination to them: a non-statically typed language called Lisp)(and they also conveniently forget the FP nature of Smalltalk on the way there... just look at how this paper makes Smalltalk the same variant of OOP as Java) It's so depressing :( They have good stuff (immutable, persistent structures are certainly a huge boost, as well as FRP) but we'll have to reinvent a GUI toolkit in Smalltalk to show the world how good those concepts are... In the meantime, I remember foundly the MMVC framework in VisualWorks as a very effective toolkit for business GUIs: limited, but effective for what it was intended for. Now, Morphic is so much more powerfull... that we mostly underuse it with basic widgets. Thierry Le 16/02/2015 13:45, Sebastian Sastre a Ã©crit : > Well yes, but is even worst that it doesnât even mention Douglas > Engelbartâs work which is the widely know and hugely influential The > Mother of All Demos <https://www.youtube.com/watch?v=yJDv-zdhzMY>/./ > / > / > But the part that is important and I think is valid is the one that > shows gradually how a GUI framework deals with incremental complexity > and learnability. > > These examples are a good framework to display a GUI's framework features: > > *Counter* > Challenges: understanding the basic ideas of a language/toolkit and the > essential scaffolding > > *Temperature Converter* > Challenges: working with bidirectional dataflow, working with > user-provided text input > > *Flight Booker* > Challenges: working with constraints > > *Timer* > Challenges: working with concurrency, working with competing user/signal > interactions, keeping the application responsive > > *CRUD* > Challenges: separating the domain and presentation logic, managing > mutation, building a non-trivial layout > > *Circle Drawer* > Challenges: implementing undo/redo functionality, custom drawing, > implementing dialog control (i.e. keeping the context between successive > GUI operations) > > *Cells* > Challenges: implementing change propagation, customizing a widget, > implementing a more authentic/involved GUI application > > And these are really good dimensions to benchmark the competitiveness of > generic GUI frameworks: > > *Dimensions of Evaluation* > > The following dimensions of evaluation are a subset of the dimensions > from the Cognitive Dimensions of Notations (CDs) > <http://www.cl.cam.ac.uk/~afb21/CognitiveDimensions/> framework which is > âan approach to analysing the usability of information artefactsâ. > > *Abstraction Level.* Types and availability of abstraction mechanisms > Does the system provide any way of defining new terms within the > notation so that it can be extended to describe ideas more clearly? Can > details be encapsulated? Does the system insist on defining new terms? > What number of new high-level concepts have to be learned to make use of > a system? Are they easy to use and easy to learn? > Each new idea is a barrier to learning and acceptance but can also make > complex code more understandable. For example, Java Swing, the > predecessor to JavaFX, employs a variation of the MVC design pattern in > its general architecture and in particular for each of its widgets. Such > being the case, there is a significant learning requirement to using the > widgets reasonably well and often much boilerplate involved (âthe system > insists on defining new termsâ) which does not pay off for simple > applications. On the other hand, for very complex applications the > MVC-architecture may make the code more understandable and manageable as > details can be encapsulated in the new terms âModel, View and Controllerâ. > Another example is a function. A function has a name and, optionally, > parameters as well as a body that returns a value following certain > computational steps. A client can simply refer to a function by its name > without knowing its implementation details. Accordingly, a function > abstracts the computational process involved in the computation of a > value. The learning barrier to the principle of a function is not great > but it can still make a lot of code much more understandable by hiding > unimportant details. > > *Closeness of Mapping.* Closeness of representations to domain > How closely related is the notation to the result it is describing resp. > the problem domain? Which parts seem to be a particularly strange way of > doing or describing something? > An example is the layout definition of a GUI. Languages that do not > provide a way to describe the layout in a nested resp. hierarchical > manner, and as such force the programmer to âlinearizeâ the code with > the introduction of meaningless temporary variables, make it hard to see > how the structure of the layout definition relates to the resulting > layout of the application. Not for nothing are XML-based view > specifications widespread for GUI-toolkits in languages without native > support for hierarchical layout expressions. > > *Hidden Dependencies.* Important links between entities invisible > Are dependencies between entities in the notation visible or hidden? Is > every dependency indicated in both directions? Could local changes have > confusing global effects? > If one entity cites another entity, which in turn cites a third, > changing the value of the third entity may have unexpected > repercussions. The key aspect is not the fact that A depends on B, but > that the dependency is not made visible. A well-known illustration of a > bad case of Hidden Dependencies is the fragile base class problem. In > (complex) class hierarchies a seemingly safe modification to a base > class may cause derived classes to malfunction. The IDE in general > cannot help discovering such problems and only certain programming > language features can help preventing them. Another example are > non-local side-effects in procedures, i.e. the dependencies of a > procedure with non-local side-effects are not visible in its signature. > > *Error-proneness.* Notation invites mistakes > To what extent does the notation influence the likelihood of the user > making a mistake? Do some things seem especially complex or difficult > (e.g. when combining several things)? > In many dynamic languages with implicit definitions of variables a > typing error in a variable name can suddenly lead to hard to find errors > as the IDE cannot always point out such an error due to the languageâs > dynamicity. Javaâs different calling semantics for primitive and > reference types may lead to mistakes if the programmer mixes them up. > Implicit null-initialization of variables can lead to null-pointer > exceptions if the programmer forgets to correctly initialize a variable > before its use. > > *Diffuseness.* Verbosity of language > How many symbols or how much space does the notation require to produce > a certain result or express a meaning? What sorts of things take more > space to describe? > Some notations can be annoyingly long-winded, or occupy too much > valuable âreal-estateâ within a display area. In Java before version 8 > in order to express what are lambdas today anonymous classes were > employed. Compared to Java 8âs lambdas these anonymous classes used to > be a very verbose way of encoding anonymous functions especially when > used in a callback-heavy setting like traditional GUI programming. > > *Viscosity.* Resistance to change > Are there any inherent barriers to change in the notation? How much > effort is required to make a change to a program expressed in the notation? > A viscous system needs many user actions to accomplish one goal. > Changing the return type of a function might lead to many code breakages > in the call sites of said function. In such a case an IDE can be of > great help. Creating a conceptual two-way data-binding by means of two > callbacks involves more repetition than a more direct way to define such > a dependency. > > *Commentary* > This part is not so much a dimension but a place to mention everything > else which is noteworthy and to give a conclusion. For instance, general > observations that do not fit into the above dimensions, impressions > during the development process, efficiency concerns of the resulting > code and potential improvements can be addressed. In addition, the > responsibilities of the other dimensionsâ results are assigned to the > paradigm, language, toolkit and the IDE. > > I think Pharo can score high on those, thatâs the point of sharing it here > > > > > >> On Feb 15, 2015, at 12:08 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Sebastian, >> >> a guy which starts by saying that no GUI toolkit of significance were >> written in FP, and forget to link or cite Garnet (by B. Myers) (Common >> Lisp) is, how to say, intriguing. >> >> Doesn't bode well for the well researched :( >> >> Thierry >> >> Le 15/02/2015 14:08, Sebastian Sastre a Ã©crit : >>> Hi guys, >>> >>> I saw the interest in GUI lately and today I come across this really >>> well researched master thesis paper that can put some light on how good >>> we can perform in the GUI spectrum in terms of practicality, >>> expressivity and productivity >>> >>> Introduction >>> >>> Even though OOP was born with the SIMULA programming language in the >>> 1960s [15], it was Smalltalk that coupled GUI development with the OOP >>> paradigm [25]. Smalltalkâs inventor Alan Kay was inspired by SIMULA, >>> among other influences, to create a new language for graphics-oriented >>> applications leveraging the OOP paradigm â and the rest is history [24]. >>> Ever since Smalltalk successfully showed the promise of OOP for GUI >>> development a great deal of subsequent OOP languages and, particularly, >>> object-oriented GUI toolkits came into existence and eventually into the >>> mainstream. Nearly all mainstream programming languages today directly >>> support the OOP paradigm and there is hardly any widely used GUI toolkit >>> that does not use OOP. Various popular examples of toolkits like Cocoa, >>> WinForms, Qt, wxWidgets, Tk, Swing and GTK+1 all seem to validate the >>> notion of OOP and GUI development being a good fit. >>> >>> continues: http://www.eugenkiss.com/projects/thesis.pdf >>> >>> And it seems it triggered this movement of people that are open to >>> receive implementations of the seven dimensions of this benchmark in his >>> repo: >>> >>> https://github.com/eugenkiss/7guis/wiki >>> >>> I beleive Pharo can score nicely there and if would be a Pharo >>> implementation there a whole new audience (that we probably aren't >>> reaching now) might take a serious try >>> >>> from mobile >>> >>> >> >> >

Feb. 16, 2015

Re: [Pharo-users] Roassal question

by Pierre CHANSON

2015-02-16 14:05 GMT-03:00 Werner Kassens <wkassens(a)libello.com>: > everything would be scaled automatically Yes I see now what you would like, the idea would be to place an X and Y axis around a collection of RTElements in a view. So I integrated a RTAxisAdaptedBuilder in the last version of Roassal2 for that. The RTAxisAdaptedBuilderExample>>example2 would correspond to your rectangles problem. I just changed for now the size of the rectangles because my axis don't yet adapt to small rectangle size (and it does not look nice). There is still some work to do on this Builder to make it efficient, like to choose wher to place the axis, the numbers of thicks or labels that I did not made yet. But like this you can easily browse the code to see how I used RTAxisConfiguration and Renderer (not yet very well use I have to admit), and we can discuss of how could we make it work as you want. Pierre â

Feb. 16, 2015

Re: [Pharo-users] Roassal question

by Werner Kassens

On 02/16/2015 05:18 PM, Pierre CHANSON wrote: > But about the axis, the idea would be to have axis from 0@0 or axis that > are placed near your elements ? > Using RTGrapher you can integrate axis easily that are placed for your > datas, but if we want particular axis to go in this view we will have to > use RTAxisConfiguration and RTAxisRenderer. Thank you Pierre. yes, the axis' should be placed near the elements eg at 500@500. i thought i could use one of the builders - like eg in the scatter plot examples, so that everything would be scaled automatically; but if this is not possible, may i ask, whether you have some hints how to use RTAxisConfiguration and RTAxisRenderer? it seems i have to delve further into roassal than i initially thought <g>. werner

Feb. 16, 2015

Re: [Pharo-users] Roassal question

by Pierre CHANSON

Hi Werner, With this I get my two Rectangles shapes in a view with their positions printed in popup. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view := RTView new. coll:=Array with: (Rectangle origin: 500@500 corner: 510@520) with: (Rectangle origin: 505@504 corner: 511@522). "Some colors" n := RTMultiLinearColorForIdentity new objects: (coll). "Integrating elements to the view" coll do: [ :r | view add: ((RTBox new color: [ :value | n rtValue: r]; width: r width; height: r height) elementOn: r )]. "Moving elements to their position and add a popup to show the position" view elements do: [ :e | e translateTo: e model center; @ (RTPopup text: [:el | el center])]. view inspect -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= But about the axis, the idea would be to have axis from 0@0 or axis that are placed near your elements ? Using RTGrapher you can integrate axis easily that are placed for your datas, but if we want particular axis to go in this view we will have to use RTAxisConfiguration and RTAxisRenderer. Pierre 2015-02-14 11:15 GMT-03:00 Werner Kassens <wkassens(a)libello.com>: > Hi, > i have a little problem, where i think roassal could perhaps be helpfull, > but i have to admit this is the very first time i looked into roassal, > hence i have a stupid question: > i have a collection of something like rectangles, lets say: > coll:=Array with: (Rectangle origin: 500@500 corner: 510@520) with: > (Rectangle origin: 505@504 corner: 511@522). > now i want to produce a graph that shows these rectangles together with > the x & y axis that show their positions (in a sensible way). any simple > hints how i could go about this task? > werner > >

Feb. 16, 2015

Re: [Pharo-users] recover lost changes

by Sean P. DeNigris

Hartmut wrote > Working with Pharo 3.0 I noticed for a while that I could not recover > class definitions (do it's) from the "Recent Changes". Now fixed in latest Pharo 3.0 and 4.0. Thank you Marcus :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/recover-lost-changes-tp4804929p4805928.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2015

Re: [Pharo-users] On GUI design and how to benchmark it

by Ignacio Sniechowski

Sebastian, Thanks for sharing this. I found the thesis interesting. There are several points that are worth take into account: He says when analyzing the possible outcomes of his thesis that: "Putting paradigms aside, another possible outcome is that the languageâs, the IDEâs and/or the toolkitâs role in GUI development is much more crucial than the role of the paradigm." Which I think is probably the case of Pharo. Also in another part: "The existence of GUI builders for nearly all popular GUI toolkits demonstrates that there are reasons for avoiding manual layout specifications in code. Of course, GUI builders have some inherent advantages9 such as easier discovery of all the widgets, immediate design feedback for prototyping and little need to learn the layout API which in principle allows non-programmers to create the layout. Still, the question is whether the paradigm, language (environment) or toolkit can reduce the demand for a GUI builder which would lead to simpler tooling requirements or, at least, to a convenient alternative for situations where for some reason or another a GUI builder cannot be used." And I think in the case if Pharo we should have a combination of both. Also the discussion of whether the UI toolkit should have an implementation language different of the DSM or if it should have the same is interesting. Again thanks for sharing. cheers Nacho *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* *Tel: (011) 4542-6714* On Sun, Feb 15, 2015 at 10:08 AM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > Hi guys, > > I saw the interest in GUI lately and today I come across this really well > researched master thesis paper that can put some light on how good we can > perform in the GUI spectrum in terms of practicality, expressivity and > productivity > > Introduction > > Even though OOP was born with the SIMULA programming language in the > 1960s [15], it was Smalltalk that coupled GUI development with the OOP paradigm > [25]. Smalltalkâs inventor Alan Kay was inspired by SIMULA, among other > influences, to create a new language for graphics-oriented applications > leveraging the OOP paradigm â and the rest is history [24]. Ever since > Smalltalk successfully showed the promise of OOP for GUI development a > great deal of subsequent OOP languages and, particularly, object-oriented GUI > toolkits came into existence and eventually into the mainstream. Nearly > all mainstream programming languages today directly support the OOP paradigm > and there is hardly any widely used GUI toolkit that does not use OOP. > Various popular examples of toolkits like Cocoa, WinForms, Qt, wxWidgets, > Tk, Swing and GTK+1 all seem to validate the notion of OOP and GUI development > being a good fit. > continues: http://www.eugenkiss.com/projects/thesis.pdf > > And it seems it triggered this movement of people that are open to receive > implementations of the seven dimensions of this benchmark in his repo: > > https://github.com/eugenkiss/7guis/wiki > > I beleive Pharo can score nicely there and if would be a Pharo > implementation there a whole new audience (that we probably aren't reaching > now) might take a serious try > > from mobile > > >

Feb. 16, 2015

Re: [Pharo-users] GSOC 2015 Call for Ideas

by Ben Coman

Looks like a great On Mon, Feb 16, 2015 at 3:48 AM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > Great! > > Forked repo, starred and PR sent: > https://github.com/pharo-project/pharo-project-proposals/pull/1 > > keep up the good work! > > > I see this is merged 19 hours ago, but it doesn't show on the page for me. e.g. "7GUIs" btw, * Perhaps pharo-users would be a less daunting mail list for students begin their enquiries on. * Any chance of having working urls so its easier to engage candidates with links to further info?

Feb. 16, 2015

Re: [Pharo-users] On GUI design and how to benchmark it

by Sebastian Sastre

Well yes, but is even worst that it doesnât even mention Douglas Engelbartâs work which is the widely know and hugely influential The Mother of All Demos <https://www.youtube.com/watch?v=yJDv-zdhzMY>. But the part that is important and I think is valid is the one that shows gradually how a GUI framework deals with incremental complexity and learnability. These examples are a good framework to display a GUI's framework features: Counter Challenges: understanding the basic ideas of a language/toolkit and the essential scaffolding Temperature Converter Challenges: working with bidirectional dataflow, working with user-provided text input Flight Booker Challenges: working with constraints Timer Challenges: working with concurrency, working with competing user/signal interactions, keeping the application responsive CRUD Challenges: separating the domain and presentation logic, managing mutation, building a non-trivial layout Circle Drawer Challenges: implementing undo/redo functionality, custom drawing, implementing dialog control (i.e. keeping the context between successive GUI operations) Cells Challenges: implementing change propagation, customizing a widget, implementing a more authentic/involved GUI application And these are really good dimensions to benchmark the competitiveness of generic GUI frameworks: Dimensions of Evaluation The following dimensions of evaluation are a subset of the dimensions from the Cognitive Dimensions of Notations (CDs) <http://www.cl.cam.ac.uk/~afb21/CognitiveDimensions/> framework which is âan approach to analysing the usability of information artefactsâ. Abstraction Level. Types and availability of abstraction mechanisms Does the system provide any way of defining new terms within the notation so that it can be extended to describe ideas more clearly? Can details be encapsulated? Does the system insist on defining new terms? What number of new high-level concepts have to be learned to make use of a system? Are they easy to use and easy to learn? Each new idea is a barrier to learning and acceptance but can also make complex code more understandable. For example, Java Swing, the predecessor to JavaFX, employs a variation of the MVC design pattern in its general architecture and in particular for each of its widgets. Such being the case, there is a significant learning requirement to using the widgets reasonably well and often much boilerplate involved (âthe system insists on defining new termsâ) which does not pay off for simple applications. On the other hand, for very complex applications the MVC-architecture may make the code more understandable and manageable as details can be encapsulated in the new terms âModel, View and Controllerâ. Another example is a function. A function has a name and, optionally, parameters as well as a body that returns a value following certain computational steps. A client can simply refer to a function by its name without knowing its implementation details. Accordingly, a function abstracts the computational process involved in the computation of a value. The learning barrier to the principle of a function is not great but it can still make a lot of code much more understandable by hiding unimportant details. Closeness of Mapping. Closeness of representations to domain How closely related is the notation to the result it is describing resp. the problem domain? Which parts seem to be a particularly strange way of doing or describing something? An example is the layout definition of a GUI. Languages that do not provide a way to describe the layout in a nested resp. hierarchical manner, and as such force the programmer to âlinearizeâ the code with the introduction of meaningless temporary variables, make it hard to see how the structure of the layout definition relates to the resulting layout of the application. Not for nothing are XML-based view specifications widespread for GUI-toolkits in languages without native support for hierarchical layout expressions. Hidden Dependencies. Important links between entities invisible Are dependencies between entities in the notation visible or hidden? Is every dependency indicated in both directions? Could local changes have confusing global effects? If one entity cites another entity, which in turn cites a third, changing the value of the third entity may have unexpected repercussions. The key aspect is not the fact that A depends on B, but that the dependency is not made visible. A well-known illustration of a bad case of Hidden Dependencies is the fragile base class problem. In (complex) class hierarchies a seemingly safe modification to a base class may cause derived classes to malfunction. The IDE in general cannot help discovering such problems and only certain programming language features can help preventing them. Another example are non-local side-effects in procedures, i.e. the dependencies of a procedure with non-local side-effects are not visible in its signature. Error-proneness. Notation invites mistakes To what extent does the notation influence the likelihood of the user making a mistake? Do some things seem especially complex or difficult (e.g. when combining several things)? In many dynamic languages with implicit definitions of variables a typing error in a variable name can suddenly lead to hard to find errors as the IDE cannot always point out such an error due to the languageâs dynamicity. Javaâs different calling semantics for primitive and reference types may lead to mistakes if the programmer mixes them up. Implicit null-initialization of variables can lead to null-pointer exceptions if the programmer forgets to correctly initialize a variable before its use. Diffuseness. Verbosity of language How many symbols or how much space does the notation require to produce a certain result or express a meaning? What sorts of things take more space to describe? Some notations can be annoyingly long-winded, or occupy too much valuable âreal-estateâ within a display area. In Java before version 8 in order to express what are lambdas today anonymous classes were employed. Compared to Java 8âs lambdas these anonymous classes used to be a very verbose way of encoding anonymous functions especially when used in a callback-heavy setting like traditional GUI programming. Viscosity. Resistance to change Are there any inherent barriers to change in the notation? How much effort is required to make a change to a program expressed in the notation? A viscous system needs many user actions to accomplish one goal. Changing the return type of a function might lead to many code breakages in the call sites of said function. In such a case an IDE can be of great help. Creating a conceptual two-way data-binding by means of two callbacks involves more repetition than a more direct way to define such a dependency. Commentary This part is not so much a dimension but a place to mention everything else which is noteworthy and to give a conclusion. For instance, general observations that do not fit into the above dimensions, impressions during the development process, efficiency concerns of the resulting code and potential improvements can be addressed. In addition, the responsibilities of the other dimensionsâ results are assigned to the paradigm, language, toolkit and the IDE. I think Pharo can score high on those, thatâs the point of sharing it here > On Feb 15, 2015, at 12:08 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Sebastian, > > a guy which starts by saying that no GUI toolkit of significance were written in FP, and forget to link or cite Garnet (by B. Myers) (Common Lisp) is, how to say, intriguing. > > Doesn't bode well for the well researched :( > > Thierry > > Le 15/02/2015 14:08, Sebastian Sastre a Ã©crit : >> Hi guys, >> >> I saw the interest in GUI lately and today I come across this really >> well researched master thesis paper that can put some light on how good >> we can perform in the GUI spectrum in terms of practicality, >> expressivity and productivity >> >> Introduction >> >> Even though OOP was born with the SIMULA programming language in the >> 1960s [15], it was Smalltalk that coupled GUI development with the OOP >> paradigm [25]. Smalltalkâs inventor Alan Kay was inspired by SIMULA, >> among other influences, to create a new language for graphics-oriented >> applications leveraging the OOP paradigm â and the rest is history [24]. >> Ever since Smalltalk successfully showed the promise of OOP for GUI >> development a great deal of subsequent OOP languages and, particularly, >> object-oriented GUI toolkits came into existence and eventually into the >> mainstream. Nearly all mainstream programming languages today directly >> support the OOP paradigm and there is hardly any widely used GUI toolkit >> that does not use OOP. Various popular examples of toolkits like Cocoa, >> WinForms, Qt, wxWidgets, Tk, Swing and GTK+1 all seem to validate the >> notion of OOP and GUI development being a good fit. >> >> continues: http://www.eugenkiss.com/projects/thesis.pdf <http://www.eugenkiss.com/projects/thesis.pdf> >> >> And it seems it triggered this movement of people that are open to >> receive implementations of the seven dimensions of this benchmark in his >> repo: >> >> https://github.com/eugenkiss/7guis/wiki <https://github.com/eugenkiss/7guis/wiki> >> >> I beleive Pharo can score nicely there and if would be a Pharo >> implementation there a whole new audience (that we probably aren't >> reaching now) might take a serious try >> >> from mobile >> >> > >

Feb. 16, 2015

Tide does not load via Workspace: #UHE >> FileDoesNotExist

by Nic

Hi, I try to follow the following step by step: .../Tide/tide-doc-master/documentation.pier.html in step 1.3.1. |Metacellonew configuration:'Tide'; version:#development; repository:'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main'; load. it starts loading until: | ZnClient new url: url; downloadTo: outputFileName. url = 'https://github.com/tide-framework/tide/zipball/master' outputFileName= '/tmp/github-tideframeworktidemaster.zip' I get the following in the FileDoesNotExist in the method: FileHandle>>streamError reference exists ifFalse: [FileDoesNotExist signalWith: reference]. self error: 'Unable to open file ' , reference printString Please can you tell me what I miss .. my assumption was, that the output file would be created during loading. Regards, Nic System: Windows 7 Image: Pharo3.0 Latest update: #30862

Feb. 16, 2015

Re: [Pharo-users] Learning Spec

by Craig

Sven, Thanks for this, I was unaware of the MultiColumnListModel. I notice that setting colors has no effect here either. I remember from the video that overriding theme colors is still an issue in Spec, but I can move forward. Craig -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 16 February 2015 12:30 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Learning Spec This is the easiest way that I know to show a simple table. MultiColumnListModel new items: #(('x coordinate' 'y coordinate' 'z coordinate')(1 2 3)(4 5 6)(7 8 9)); displayBlock: [ :x | x collect: #asString ]; setSelectedIndex: 2; title: 'My table'; openWithSpec. > On 15 Feb 2015, at 22:36, Craig <craig(a)hivemind.net> wrote: > > Hi Sven, > > I count myself as a beginner with Pharo, although I've been dabbling with Pharo UI choices for a few months now. > Like Sebastian, I wrote Spec off as too immature for prime-time, but I > too come from the commercial world, so maybe my expectations were unrealistic. > > So I took the time to learn Spec. My very first requirement is to display some data in a grid or table like manner, so I took a look at the TreeModel, and tried to adapt one of the examples to fit. However, whenever I try to add a third column to the model, I get a "Subscript Out of Bounds". > I also tried to change the oddRowColor, but it had no effect. > > I hope that is specific enough for you. > > Craig > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On > Behalf Of Sven Van Caekenberghe > Sent: 13 February 2015 11:12 AM > To: Any question about pharo is welcome > Subject: [Pharo-users] Learning Spec > > Hi, > > > From now on it is forbidden to complain about Spec in general, unspecific terms unless you have taken the time to learn about it. Here is a guide to documentation about Spec, most recent first. > > > There is an excellent presentation by Johan Fabry did during the last Pharo Days, 'Using Spec to Build a UI'. *MUST WATCH* (the video is not yet fully public, but soon will be, the link should work though): > > http://youtu.be/OL23s9ZUIR0?list=PL4actYd6bfnz98ngrKALwwStl3C3odEKG > > The slides are also not yet available, but soon will be (the talk is much better that the slides on their own). > > > This draft chapter 'Spec: a framework for describing user interfaces' for an upcoming book: > > > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInP > rogress/lastSuccessfulBuild/artifact/Spec/Spec.pier.html > > > Look in the image. > > Browse the hierarchy below AbstractWidgetModel in the category Spec-Core-Widgets in Pharo 4, look at the protocols called 'protocol' & 'protocol-events' mainly. Look for references to each class. Trace senders of methods until you arrive at examples. Study the examples, play with them, change them. > > The UI of most tools in Pharo is also implemented using Spec. Browse the hierarchy below ComposableModel to find them. (Komitter, Versionner, Critics, Metacello, the old Eye Inspectors, ..). Watch and learn. > > > The cool Spec website: > > http://spec.st > > > Read some cool articles like: > > https://medium.com/concerning-pharo/rediscovering-the-ux-of-the-legend > ary-hp-35-scientific-pocket-calculator-d1d497ece999 > > See the section 'HP35CalculatorModel' for the Spec part. > > > The following papers (some older ones refer to API that has changed): > > 'Seamless Composition and Reuse of Customizable User Interfaces with Spec' > > http://rmod.lille.inria.fr/archives/papers/Ryse13a-SCICO-Spec.pdf > > 'Spec - A Framework for the Specification and Reuse of UIs and their Models' > > > http://rmod.lille.inria.fr/archives/papers/Ryse12b-Spec-IWST12-Final.p > df > > 'Spec â Technical Report' > > > http://rmod.lille.inria.fr/archives/reports/Ryse12a-SpecTechReport.pdf > > > Use the image to build a couple of simple UIs using Spec. You will be surprised to learn that it is not that difficult. Just go with the flow, don't try to enforce your world view on it, wait until you are further along. > > > Have fun ! > > > Sven > > > PS: Once you have done all the above, you are most welcome to help improve Spec by discussing specific, concrete issues. > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > >

Feb. 16, 2015