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

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Tudor Girba

Thanks for bringing this up. Yes, we should care about usability. And I agree that usability is attainable as long as you approach it with consistent discipline. It's similar to designing code: you start asking questions, figure out what the right questions are, and then stick to it. I like Steve Krug's Don't make me think book. However, please keep in mind that the lessons in the book apply specifically to the web. An environment like Pharo should not obey exactly the same things. But, as Esteban says, let's focus on the future, and keep usability high in our list of concerns. Even if we might not know how to do it now, simply sticking with it will make us better in the long run. Cheers, Doru On Fri, Jan 3, 2014 at 10:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi Sebastian, > > I feel your pain :) > > we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance > what we have currently. > Nowâ¦ one of the biggest problems we have is that people is so used to the > old tools that they donât even realise that we can do a lot better. And > most possible some people will react violently to any changeâ¦ but well, we > will do it anyway, with your help. > Letâs all together build a better IDE for the future :) > > Esteban > > On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> > wrote: > > Guys is no mystery that we have some issues with UI. > > It's not so bad either, we have many things that are light years ahead of > other but we consistently miss some really basic stuff from the > Human-Computer-Interactcion point of view. > > The community is biased towards engineering and unbalanced regarding to > design so this is no surprise (why this happens is another interesting > conversation). > > UI is not that hard when you know what to pay attention to but we need > first to decide if we care about usability and the developer experience at > all. > > This fantastic talk from Steve Krug exposes what's the least you can do > for the usability of any software. > > > http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… > > sebastian <https://about.me/sebastianconcept> > > o/ > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Configuration trouble

by Diego Lont

Hi all, Due to the release of Seaside 3.1 some projects have fallen over. I thought I give a heads up. The error message I got was from the CI-server for my project (QCMagritte) was: *** Warning: Warning: This package depends on the following classes: GRDelegatingStream You must resolve these dependencies before you will be able to load these definitions: GRCountingStream count greaseNext:putAll:startingAt: initialize next next: nextPut: nextPutAll: reset greaseNext:putAll:startingAt: Basically, this means that you try to load 2 different versions of Seaside in your configuration: 3.0.9 and/or 3.1 into Pharo. This problem may have occurred in the past as well when we moved the configuration to its own place. So if people get this error: please fix your configuration. Most of the projects I can access the configuration (Magritte3, Pier3, TwitterBootstrap, QCMagritte) have different version for loading 3.1 or 3.0.9. If people have trouble fixing this: we can take a look at your configuration. For instance: I see on the CI-server that the smalltalkhub project has this problem, but I can imagine this is the case for private projects as well, as the "#stable" symbolic version now points to a different numbered version. Note: for gemstone the stable version is changed into 3.0.10 â¦ for people who use seaside on gemstone: it might be needed that a different version for gemstone should be added. Cheers, Diego

Jan. 3, 2014

Re: [Pharo-dev] Question about ANSI Smalltalk

by Jan Vrany

Thanks for explanation. Jan On 03/01/14 10:19, Marcus Denker wrote: > > On 03 Jan 2014, at 10:15, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> Hi Marcus (and others) >>> >>> On 20 Dec 2013, at 23:10, vfclists . <vfclists(a)gmail.com >>> <mailto:vfclists@gmail.com>> wrote: >>> >>>> Anyone noticed or tried Gravel? >>>> >>>> https://github.com/gravel-st/gravel >>>> >>> >>> "Gravel aims to be fullyANSI Smalltalk >>> <http://wiki.squeak.org/squeak/172> compatible.â >>> >>> â> the author has no clue. >>> >>> Marcus >> >> I know your time is precious but still I would like to understand >> the above statement. I mean, why >> >> "Gravel aims to be fullyANSI Smalltalk <http://wiki.squeak.org/squeak/172> compatible.â >> >> means the author is clueless. >> > > Clueless is the wrong word: what I meant is that people will read it as âItâs ANSI Smalltalk, so it > it Smalltalkâ. While you can make an Ansi Compatible system that clearly does not do what you > think a Smalltalk should do (e.g. have become: or a thisContext). > > I am sure the authors know that, too. So clueless is the wrong term. > > Marcus >

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Esteban Lorenzano

On 03 Jan 2014, at 10:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 03 Jan 2014, at 01:01, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Changes reads >> Merge writes >> > >> In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code). >> >> It's functionally correct but the UI can be soooo much better with some tuning. >> >> I'll post something that might help us on this subject >> >> > The whole Monticello Browser should not existâ¦ amen maybeâ¦ somedayâ¦ not so farâ¦ (?) > > Marcus

Jan. 3, 2014

Re: [Pharo-dev] Don't make me think (the one thing you shouldn't ignore about user interfaces)

by Esteban Lorenzano

Hi Sebastian, I feel your pain :) we are aiming to focus Pharo 4 in âmodularisation and toolsâ, to enhance what we have currently. Nowâ¦ one of the biggest problems we have is that people is so used to the old tools that they donât even realise that we can do a lot better. And most possible some people will react violently to any changeâ¦ but well, we will do it anyway, with your help. Letâs all together build a better IDE for the future :) Esteban On 03 Jan 2014, at 01:13, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Guys is no mystery that we have some issues with UI. > > It's not so bad either, we have many things that are light years ahead of other but we consistently miss some really basic stuff from the Human-Computer-Interactcion point of view. > > The community is biased towards engineering and unbalanced regarding to design so this is no surprise (why this happens is another interesting conversation). > > UI is not that hard when you know what to pay attention to but we need first to decide if we care about usability and the developer experience at all. > > This fantastic talk from Steve Krug exposes what's the least you can do for the usability of any software. > > http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-abou… > > sebastian > > o/ > > > > >

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Marcus Denker

On 03 Jan 2014, at 01:01, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Changes reads > Merge writes > > In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code). > > It's functionally correct but the UI can be soooo much better with some tuning. > > I'll post something that might help us on this subject > > The whole Monticello Browser should not existâ¦ Marcus

Jan. 3, 2014

Re: [Pharo-dev] [Issue tracker] Help needed for reviews

by Marcus Denker

On 03 Jan 2014, at 00:04, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 02/01/2014 20:37, Marcus Denker a Ã©crit : >> I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed >> in between, too. > > > For me this is weird, I can't understand the logic. > Merge: shows you the changes then let your merge > Change: shows some other sort of changes I don't understand. > >From then the change was made *other* changes have been done. âChangeâ will show *all* differences, both the ones other integrations did to the package as well as the changes of the slice. In addition, there is still some bug that when e.g moving classes the *extending* packages are bot dirty and there might be some inconsistencies. Marcus

Jan. 3, 2014

Re: [Pharo-dev] Question about ANSI Smalltalk

by Marcus Denker

On 03 Jan 2014, at 10:15, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi Marcus (and others) > > >> On 20 Dec 2013, at 23:10, vfclists . <vfclists(a)gmail.com >> <mailto:vfclists@gmail.com>> wrote: >> >>> Anyone noticed or tried Gravel? >>> >>> https://github.com/gravel-st/gravel >>> >> >> "Gravel aims to be fullyANSI Smalltalk >> <http://wiki.squeak.org/squeak/172> compatible.â >> >> â> the author has no clue. >> >> Marcus > > I know your time is precious but still I would like to understand > the above statement. I mean, why > > "Gravel aims to be fullyANSI Smalltalk <http://wiki.squeak.org/squeak/172> compatible.â > > means the author is clueless. > Clueless is the wrong word: what I meant is that people will read it as âItâs ANSI Smalltalk, so it it Smalltalkâ. While you can make an Ansi Compatible system that clearly does not do what you think a Smalltalk should do (e.g. have become: or a thisContext). I am sure the authors know that, too. So clueless is the wrong term. Marcus

Jan. 3, 2014

Question about ANSI Smalltalk

by Jan Vrany

Hi Marcus (and others) > > On 20 Dec 2013, at 23:10, vfclists . <vfclists(a)gmail.com > <mailto:vfclists@gmail.com>> wrote: > >> Anyone noticed or tried Gravel? >> >> https://github.com/gravel-st/gravel >> > > "Gravel aims to be fullyANSI Smalltalk > <http://wiki.squeak.org/squeak/172> compatible.â > > â> the author has no clue. > > Marcus I know your time is precious but still I would like to understand the above statement. I mean, why "Gravel aims to be fullyANSI Smalltalk <http://wiki.squeak.org/squeak/172> compatible.â means the author is clueless. Thank you very much. Jan

Jan. 3, 2014

printString and asString

by Otto Behrens

Hi, I've run into one of my favorite problems in Smalltalk and decided to try the list. Please don't shoot me on this one; perhaps you've run into it yourself. If there are discussions that I should read, please send me some info. My first assumption is that the difference between printString and asString is that printString may be more elaborate than asString, but often they are the same. Do you agree? 1. In Pharo, the default implementation of asString is ^ self printString. 2. printString normally calls self printOn: aStream. (Pharo and GemStone. Yay, consistency!) 3. In Pharo, the default printOn: writes the class name prefixed with 'a' or 'an'. 4. In GemStone, the default implementation of printOn: writes self asString to the stream. My second assumption is one should never override printString. Rather override printOn:. Agreed? In Pharo, we have very few classes that overrides printString. One problem area is UUID. It overrides asString, printOn: and printString, with a similar approach to GemStone in printOn:. In GemStone, there's a big heap of inconsistency. Character also overrides all 3 methods, with an apparent awful inconsistency there! In Pharo, I get infinite recursion when I override printOn: to call asString. I get infinite recursion problems in GemStone when I override asString and call printString. So with my strategy to develop in Pharo and deploy in GemStone, we have to be very careful. Most often, overriding printString and / or asString has to do with performance. If we have a simple object, we don't want to override printOn: that creates a stream, prints an instanceVariable (already a string) to it, and then throw away the stream. My suggestion is that we should get consistency. Decide on a way and follow that. To me, this makes sense: 1. Keep the default printString that calls printOn:. 2. Override asString to return a simple representation of the object, if you have one. Don't create streams in here, or go wild with string concatenations. Practically, many objects will return a simple string, which could be one instVar. 3. Override printOn: to return a representation concatenating parts of the object as strings. Use this if you want to print a more elaborate description than asString. 4. Change Object >> asString return 'a' or 'an', class name. 5. Change Object >> printOn: to write self asString to the stream. 6. Fix printString overrides (more work in GemStone than Pharo) 7. Normally use printString, but use asString where you are concerned about performance. In some cases, you may have a longer printString... Well, thanks for reading this far. Looking forward to your answers. Otto

Jan. 3, 2014