October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT first impressions

by Esteban Lorenzano

> On 05 Oct 2014, at 18:24, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > Tudor Girba wrote: > Hi Esteban, > > I know it's a usability principle, but usability should also take into account culture. Programmers are not every-day users, and the assumptions we take should adapt to their needs. This is why it is worth exploring what might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, > > But programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. > cheers -ben > > Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Well, I donât know if it helps, but I cannot think on a single app in my life that does not have those ubiquitous copy/cut/paste options as part of their contextual menus. Not that because everybody does it we *have to* do it tooâ¦ but I do not see a reason to not follow the universal conventions in this case. Esteban > > Cheers, > Doru > > > > but I did not consider the case in which people go through multiple virtual boxes to get to the image. This is a legitimate issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> > <mailto:tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>> wrote: > > Hi HernÃ¡n, > > Thanks for the feedback. Just a question: Was there anything you > do like? :) > > The rest of the reply is inline. > > > On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com> <mailto:hernan.morales@gmail.com <mailto:hernan.morales@gmail.com>>> wrote: > > Sorry if following issues were reported. I have seen so many > mails about GT that I wanted to try it. These are my first > notes and personal tastes, don't take them as negative just > want to provide some feedback: > > - First weird thing: The Workspace doesn't open a Workspace > anymore, it opens a Playground window. > > > That is because it is still a work in progress. > > - When I select code, right click gives no "Copy, Cut, Delete" > commands. > > > This was reported. The menu is missing on purpose. I still have a > hard time understanding why a developer needs those menu entries, > but we will add them back. Btw, the shortcuts do work. > > Is an usability principle: A system should provide visual feedback > about what happens and about what it can do. How can we know what can or cannot do the playground? > But of course, using menus as documentation is not always a good > idea, soâ¦ we need to find a balance here :) > I always use OSX design guidelines as a base on what I want to do > (not that we should take it literally, but is always good to see > what others with time to invest have to say). And this is all what they say about > menus: https://developer.apple.com/library/mac/documentation/userexperience/concep… <https://developer.apple.com/library/mac/documentation/userexperience/concep…> > > Esteban > > > - Selecting an instance variable from the "State" tab, > completely shift the code view and scrolls to a new Inspector. > Is not that I would love to scroll back everytime to get a > view on my code. > > > The usage depends on the scenario in which you are. In most cases, > when you do want to drill through many objects, you are likely to > only use the playground as an entry point. When you build a more > elaborate piece of code in the playground, you typically do not > need to drill too much. In any case, if you want to scroll back, > there are also keybindings that allow you to navigate: > Cmd+Alt+Left/Right. > > - I cannot find how to close new Inspector tabs. > > > This is a feature that is already planned. > > - "Print it" seems broken. It seems to print evaluation result > but suddenly dissapears. > > > What do you mean? Can you elaborate on that? Print it should > behave like here: > > - Debugger buttons Into, Through, etc. > -- They are too small and close themselves for the importance > they have. > -- They have no caption, so you have to mouse over to know > what they do (until you get used to) > -- They are like "too distant" from the code view. > > > The debugger is not in the Pharo image, so I think you are trying > the Moose image. Is that so? > In any case, the positioning of the icons will be the same > everywhere in GT (to the right of the scope they relate to). We > are still fiddling with the right balance in the debugger. > > Cheers, > Doru > > > Cheers, > > HernÃ¡n > > > > > > -- www.tudorgirba.com <http://www.tudorgirba.com/> <http://www.tudorgirba.com/ <http://www.tudorgirba.com/>> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> <http://www.tudorgirba.com <http://www.tudorgirba.com/>> > > "Every thing has its own flow" > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Tudor Girba

Hi, On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > >> Hi Esteban, >> >> I know it's a usability principle, but usability should also take into >> account culture. Programmers are not every-day users, and the assumptions >> we take should adapt to their needs. This is why it is worth exploring what >> might or might not be needed. >> >> I cannot believe that programmers do not know the shortcuts, >> > > But programmers new to Pharo don't know the shortcuts. Menus enhance the > explorability of the system, and lower the cognitive load of remembering > everything all at once, and helps with video tutorials. > cheers -ben > Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Cheers, Doru > but I did not consider the case in which people go through multiple >> virtual boxes to get to the image. This is a legitimate issue, so these >> actions are back. >> >> Cheers, >> Doru >> >> >> On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com >>> <mailto:tudor@tudorgirba.com>> wrote: >>> >>> Hi HernÃ¡n, >>> >>> Thanks for the feedback. Just a question: Was there anything you >>> do like? :) >>> >>> The rest of the reply is inline. >>> >>> >>> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>> >>> Sorry if following issues were reported. I have seen so many >>> mails about GT that I wanted to try it. These are my first >>> notes and personal tastes, don't take them as negative just >>> want to provide some feedback: >>> >>> - First weird thing: The Workspace doesn't open a Workspace >>> anymore, it opens a Playground window. >>> >>> >>> That is because it is still a work in progress. >>> >>> - When I select code, right click gives no "Copy, Cut, Delete" >>> commands. >>> >>> >>> This was reported. The menu is missing on purpose. I still have a >>> hard time understanding why a developer needs those menu entries, >>> but we will add them back. Btw, the shortcuts do work. >>> >> >> Is an usability principle: A system should provide visual feedback >> about what happens and about what it can do. How can we know what >> can or cannot do the playground? >> But of course, using menus as documentation is not always a good >> idea, soâ¦ we need to find a balance here :) >> I always use OSX design guidelines as a base on what I want to do >> (not that we should take it literally, but is always good to see >> what others with time to invest have to say). And this is all >> what they say about >> menus: https://developer.apple.com/library/mac/documentation/ >> userexperience/conceptual/applehiguidelines/Menus/Menus.html >> >> Esteban >> >> >>> - Selecting an instance variable from the "State" tab, >>> completely shift the code view and scrolls to a new Inspector. >>> Is not that I would love to scroll back everytime to get a >>> view on my code. >>> >>> >>> The usage depends on the scenario in which you are. In most cases, >>> when you do want to drill through many objects, you are likely to >>> only use the playground as an entry point. When you build a more >>> elaborate piece of code in the playground, you typically do not >>> need to drill too much. In any case, if you want to scroll back, >>> there are also keybindings that allow you to navigate: >>> Cmd+Alt+Left/Right. >>> >>> - I cannot find how to close new Inspector tabs. >>> >>> >>> This is a feature that is already planned. >>> >>> - "Print it" seems broken. It seems to print evaluation result >>> but suddenly dissapears. >>> >>> >>> What do you mean? Can you elaborate on that? Print it should >>> behave like here: >>> >>> - Debugger buttons Into, Through, etc. >>> -- They are too small and close themselves for the importance >>> they have. >>> -- They have no caption, so you have to mouse over to know >>> what they do (until you get used to) >>> -- They are like "too distant" from the code view. >>> >>> >>> The debugger is not in the Pharo image, so I think you are trying >>> the Moose image. Is that so? >>> In any case, the positioning of the icons will be the same >>> everywhere in GT (to the right of the scope they relate to). We >>> are still fiddling with the right balance in the debugger. >>> >>> Cheers, >>> Doru >>> >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >>> >>> >>> -- www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >>> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >> > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] History of the .image

by stepharo

Hilaire I do not know if this is there but you may find that on the history book. Now soon we will have pharo bootstrapped in production :) You can ask guille to know where to look :) On 5/10/14 12:51, Hilaire wrote: > Le 04/10/2014 16:16, David T. Lewis a Ã©crit : >> On Sat, Oct 04, 2014 at 04:00:15PM +0200, Hilaire wrote: >>> Hello, >>> >>> I am curious. What is the history of the Pharo image? I know it is >>> forked from Squeak, but then from where does come the Squeak image? >>> How and when was it build from its source code definition? >>> When did it became an "evolving organism" as it is today? >>> >>> Thanks >>> >>> Hilaire >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/17995… >> >> >> >> > > Thanks for the pointer. But my curiosity targets technical > considerations. How and when was done the first image bootstrap, then at > this moment was the image became the base of development, or was a kind > of boostrap-image-build from source still done for some time. > > Hilaire >

Oct. 5, 2014

Re: [Pharo-dev] structuring widget examples

by stepharo

On 5/10/14 15:10, Tudor Girba wrote: > Hi Stef, > > Great. GT is already prepared for this :). If you define a <gtExample> > on the class side, you will get an "E.g." tab with those examples. > > It's called gtExample because we did not want to interfere with other > pragmas, but perhaps we can change it to <eg>, or <example>. What do > you think? for a given class I would like to have potentially multiple examples. I already have that in certain classes. Then since these examples are for core classes I do not really like the idea to get gt* Now first we should have many more and renaming a pragma is just the easy part of the game. Because I'm turning WidgetExamples into class methods examples and trying to understand the API of UITheme and reducing the mess. I want - UITheme to call widgets class methods - but I have to understand the theme impact on the API. a kind of gigantic task. but we will see. Stef > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 2:25 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I started to systematically defined widget example using the > pragram <exampleWidget> > > > rowPrototype > "Answer a prototypical row" > "self rowPrototype openInHand" > <exampleWidget> > > | sampleMorphs aRow | > sampleMorphs := (1 to: (2 + 3 atRandom)) collect: > [:integer | EllipseMorph new extent: ((60 + (20 atRandom)) > @ (80 + ((20 atRandom)))); color: Color random; setNameTo: ('egg', > integer asString); yourself]. > aRow := self inARow: sampleMorphs. > aRow setNameTo: 'Row'. > aRow enableDragNDrop. > aRow cellInset: 6. > aRow layoutInset: 8. > aRow setBalloonText: 'Things dropped into here will > automatically be organized into a row. Once you have added your > own items here, you will want to remove the sample colored eggs > that this started with, and you will want to change this balloon > help message to one of your own!'. > aRow color: Color veryVeryLightGray. > ^ aRow > > This means that GTool will get instances for free to play with and > the finder get really handy to browse widgets. > > If you want to join the effort you are welcome. > > Stef > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by HernÃ¡n Morales Durand

2014-10-03 17:03 GMT-03:00 stepharo <stepharo(a)free.fr>: > > On 3/10/14 18:56, HernÃ¡n Morales Durand wrote: > > > > I have the same feeling. "Pharo is yours, but I take the main > decisions". Actually it feels a little bit insulting, I am using Pharo > since several years in a domain which nobody works with Smalltalk, and > never got a survey request (except for some software engineering research). > And I bet there are people not in the Pharo/Moose/Seaside team that didn't > received any attention and they are doing significant experiences. > > You are paranoid. :) We know well people in Moose and Seaside and they > know that they can talk to us. > Just ask and we listen. I do not think that people understand what is our > life. We are not a team working on Pharo. We are a research team > fighting to get some time to push Pharo and Inria gives us some money to > pay engineers like igor, and esteban. > > I know that. What I am saying is: Why there is no voting process for libraries, tools, roadmaps, etc? Not for asking things to you but for getting an idea what's most wanted, where is the community. Some of you are scientists, you know the value of collecting data. I remembered there was a Pharo usage poll in 2012 : https://docs.google.com/forms/d/1sa01_h8_SFoPIrrXaAzpmmCBvnXgEpGzIyslnkcgTp… I like that route. Even if people with the money don't care, let us believe we have the data, opinions, ideas, etc. You know like a modern democracy :) Definitely I would help building a poll, it doesn't *have* to include a Consortium member but that would be really nice. We could try smart questions. Anyone? Why they don't write here? I suspect one of the reasons is Pharo is > being too motivated by software enineering research and not enough interest > for other giant domains like 3D, finance, expert systems, HPC, etc. People > perceive this. > > We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO. > Repeat after me. > We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO. > > We are just maintaining it and making sure that we can have a decent > compiler and infrastructure to build other systems. > > > Ok for now I disagree a little bit, but I don't want to go there, I don't think that would be a productive discussion. > How could we build finance, HPC, 3d without been experts. Do not dream > there are full team of researchers at Inria building real 3d engines. > Why would we go there? Seriously. > > Because there is big money in 3D? > >> >> > I see years passing but money never comes. You cannot expect big funding > if you keep doing things the same as always. > > > Exactly and do not dream about investors. > Now we work hard to set the consortium. If at the end of the journey, > people do not sponsor or participate then we will close it. > and we will look back and say that we did our best. We create an > autonomous entity that can manage Pharo but if we cannot pay an engineer > with it then this is ok too. But people should not complain that > open-source Pharo does not work. > We do not have mozilla or google behind us and if individuals do not > understand that they can get an impact = Pharo is yours > then what can we do. Just continue slower with less engineers. > > But there are entrepreneur networks like FounderDating and https://angel.co/ Of course they are not Google but they are a popular choice for initial investment. Someone using Pharo has passed the seed funding round? Or tried to present a business plan? Cheers, HernÃ¡n

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Ben Coman

Tudor Girba wrote: > Hi Esteban, > > I know it's a usability principle, but usability should also take into > account culture. Programmers are not every-day users, and the > assumptions we take should adapt to their needs. This is why it is worth > exploring what might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, But programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben > but I did > not consider the case in which people go through multiple virtual boxes > to get to the image. This is a legitimate issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > >> On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi HernÃ¡n, >> >> Thanks for the feedback. Just a question: Was there anything you >> do like? :) >> >> The rest of the reply is inline. >> >> >> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >> >> Sorry if following issues were reported. I have seen so many >> mails about GT that I wanted to try it. These are my first >> notes and personal tastes, don't take them as negative just >> want to provide some feedback: >> >> - First weird thing: The Workspace doesn't open a Workspace >> anymore, it opens a Playground window. >> >> >> That is because it is still a work in progress. >> >> >> - When I select code, right click gives no "Copy, Cut, Delete" >> commands. >> >> >> This was reported. The menu is missing on purpose. I still have a >> hard time understanding why a developer needs those menu entries, >> but we will add them back. Btw, the shortcuts do work. > > Is an usability principle: A system should provide visual feedback > about what happens and about what it can do. > How can we know what can or cannot do the playground? > But of course, using menus as documentation is not always a good > idea, soâ¦ we need to find a balance here :) > I always use OSX design guidelines as a base on what I want to do > (not that we should take it literally, but is always good to see > what others with time to invest have to say). > And this is all what they say about > menus: https://developer.apple.com/library/mac/documentation/userexperience/concep… > > Esteban > >> >> >> - Selecting an instance variable from the "State" tab, >> completely shift the code view and scrolls to a new Inspector. >> Is not that I would love to scroll back everytime to get a >> view on my code. >> >> >> The usage depends on the scenario in which you are. In most cases, >> when you do want to drill through many objects, you are likely to >> only use the playground as an entry point. When you build a more >> elaborate piece of code in the playground, you typically do not >> need to drill too much. In any case, if you want to scroll back, >> there are also keybindings that allow you to navigate: >> Cmd+Alt+Left/Right. >> >> >> - I cannot find how to close new Inspector tabs. >> >> >> This is a feature that is already planned. >> >> >> - "Print it" seems broken. It seems to print evaluation result >> but suddenly dissapears. >> >> >> What do you mean? Can you elaborate on that? Print it should >> behave like here: >> >> >> - Debugger buttons Into, Through, etc. >> >> -- They are too small and close themselves for the importance >> they have. >> -- They have no caption, so you have to mouse over to know >> what they do (until you get used to) >> -- They are like "too distant" from the code view. >> >> >> The debugger is not in the Pharo image, so I think you are trying >> the Moose image. Is that so? >> In any case, the positioning of the icons will be the same >> everywhere in GT (to the right of the scope they relate to). We >> are still fiddling with the right balance in the debugger. >> >> Cheers, >> Doru >> >> >> >> Cheers, >> >> HernÃ¡n >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014

New smalltalk-git mailing list

by Max Leske

Hi I just discovered that the original smalltalk-git mailing list somehow vanished. Iâve therefore recreated it. If you want to (re)join, please request access here (you need to be logged in): https://groups.google.com/forum/#!forum/smalltalk-git <https://groups.google.com/forum/#!forum/smalltalk-git> Cheers, Max

Oct. 5, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Ben Coman

Johan Brichau wrote: > Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. > However, I think itâs better to do feature detection instead of dialect detection. +1 and others agree... (though on the net its possible to find material to support any view) "test for features, not for platforms" http://programmers.stackexchange.com/questions/50876/are-there-any-best-pra… "The best bet is always to test for features, not versions, because it's difficult to screw that up and it allows for the possibility that things might be back-ported in future. " http://mac-os-x.10953.n7.nabble.com/CocoaApp-isThisTiger-td29619i20.html "The Autoconf approach to portability is to test for features, not for versions." http://en.wikipedia.org/wiki/Autoconf btw Johan, how would you handle a method-existence-based requirement rather than class-existence-based? ... > So, something like: > > ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ > stream := CharacterWriteStream on: (String new: 10) > ] ifFalse:[ > stream := WriteStream on: (String new: 10) > ] > > And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. > > cheers > Johan > > On 05 Oct 2014, at 09:00, stepharo <stepharo(a)free.fr> wrote: > >> Hi jan >> >> Thanks for the proposal. >> I thought about it and I'm against because it goes again the idea of dispatch. >> I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. >> Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. >> Let us see what other people think. >> >> Stef With the disclaimer that I haven't done cross platform Smalltalk yet, in general philosophy I agree with Stef. "A Mentoring Course On Smalltalk" regarding elimination of conditional logic says, "drawing design time distinctions at run time is intention obscuring by nature". ... >> >> On 4/10/14 22:14, Jan Vrany wrote: >>> Hi guys, >>> >>> I've just opened: >>> >>> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… >>> >>> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to >>> SmalltalkImage to ease multi-dialect development. You would need to get ALL dialects to implement the convention? >>> >>> RATIONALE: >>> >>> Commonly used approach to solve differences among dialect is to use a >>> sort of platform object and dispatch there for troublesome operations >>> that has to be specialized. This platform object is usually in platform >>> specific package. >>> Other option is to load some library like Grease or Sport. >>> >>> The problem of the first approach is that brings to much (unnecessary) >>> burden when used for two, three things. The amount of of the code and >>> management is way to bigger then the amount of the code that has to be >>> specialized. However if you do want to go the testing-for-versions, and your concern is management of separate packages, then perhaps it can all be done on one package. The following does not seem too onerous from a code perspective... ------------------ CrossPlatform>>platform ^ CurrentPlatform ifNil: [ "<--class variable" CurrentPlatform := self class subClasses detect: [ :candidatePlatformClass | candidatePlatformClass isCurrentPlatform CrossPlatform subclass: SomeCoolDialect. SomeCoolDialect>>isCurrentPlatform ^ (Smalltalk version includesSubstring: 'SomeCoolDialect') ------------------ CrossPlatform>>writeStreamOn: aString self platform writeSteamOn: aString SomeCoolDialect>>writeStreamOn: aString ^ CharacterWriteStream on: aString ------------------ Loading Grease/Sport on the other hand introduces a >>> dependency on an external package - not worth of for two or three >>> things. >>> >>> The proposed dialect testing messages would allow for simple, >>> #ifdef-like idiom like: "New #ifdef's which test for specific compilers or manufacturers or operating systems are unacceptable. All #ifdef's should test for features." https://www.cs.utah.edu/dept/old/texinfo/gdb/gdbint.html cheers -ben >>> >>> | stream | >>> ... >>> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk >>> isSomeCoolDialect]) ifTrue:[ >>> stream := CharacterWriteStream on: (String new: 10) >>> ] ifFalse:[ >>> stream := WriteStream on: (String new: 10) >>> ] >>> >>> The #respondsTo: check, while not nice, is required as at the moment not >>> all dialects could be trusted to have these testing messages. >>> >>> Putting these methods may not stick with Pharo standard (whatever it >>> is), but Smalltalk global is probably one of the >>> very few that are present in pretty much every Smalltalk implementation. >>> Other option would be to place them to the class side of an Object >>> (which is amost certainly present everywhere), however >>> >>> Smalltalk isPharo >>> >>> reads better than >>> >>> Object isPharo. >>> >>> Best, Jan >>> >>> >>> >> > > >

Oct. 5, 2014

Re: [Pharo-dev] [Pharo-fuel] Updates for Pharo4

by Max Leske

> On 04.10.2014, at 07:26, StÃ©phane Ducasse <stefoff(a)free.fr> wrote: > > > On 03 Oct 2014, at 22:21, Max Leske <maxleske(a)gmail.com> wrote: > >> I fixed a couple of issues and failing tests for Pharo4. Thereâs also a couple of new things (e.g. test cases for Context instead of MethodContext) that should be integrated into Pharo4. > > Let us know and we will do it ;) Yep, saw that you included the change, thanks. > Tx for your energy and constant push. My pleasure :) > >> >> Cheers, >> Max >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

Oct. 5, 2014

Re: [Pharo-dev] structuring widget examples

by Ben Coman

Tudor Girba wrote: > Hi Stef, > > Great. GT is already prepared for this :). If you define a <gtExample> > on the class side, you will get an "E.g." tab with those examples. > > It's called gtExample because we did not want to interfere with other > pragmas, but perhaps we can change it to <eg>, or <example>. What do you > think? NOT <eg>! I've no opinion on <example> versus <gtExample> - except that we shouldn't have too many varying forms of example. -ben > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 2:25 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I started to systematically defined widget example using the pragram > <exampleWidget> > > > rowPrototype > "Answer a prototypical row" > "self rowPrototype openInHand" > <exampleWidget> > > | sampleMorphs aRow | > sampleMorphs := (1 to: (2 + 3 atRandom)) collect: > [:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @ > (80 + ((20 atRandom)))); color: Color random; setNameTo: ('egg', > integer asString); yourself]. > aRow := self inARow: sampleMorphs. > aRow setNameTo: 'Row'. > aRow enableDragNDrop. > aRow cellInset: 6. > aRow layoutInset: 8. > aRow setBalloonText: 'Things dropped into here will > automatically be organized into a row. Once you have added your own > items here, you will want to remove the sample colored eggs that > this started with, and you will want to change this balloon help > message to one of your own!'. > aRow color: Color veryVeryLightGray. > ^ aRow > > This means that GTool will get instances for free to play with and > the finder get really handy to browse widgets. > > If you want to join the effort you are welcome. > > Stef > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014