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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30486 Home: https://github.com/pharo-project/pharo-core

Oct. 15, 2013

[pharo-project/pharo-core] 27a6be: 30486

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 27a6be66160010c5da49ffe0b4788632246a15a8 https://github.com/pharo-project/pharo-core/commit/27a6be66160010c5da49ffe0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-15 (Tue, 15 Oct 2013) Changed paths: M Collections-Atomic.package/AtomicSharedQueue.class/instance/signaling/signalNoMoreItems.st M Kernel-Processes.package/Delay.class/class/snapshotting/shutDown.st M Kernel-Processes.package/Delay.class/class/snapshotting/startUp.st M Kernel-Processes.package/Delay.class/class/timer process/handleTimerEvent.st M Kernel-Processes.package/InputEventFetcher.class/instance/initialize-release/startUp.st A Kernel-Processes.package/Semaphore.class/instance/initialize-release/consumeAllSignals.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script141.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30486.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30486 11874 Deadly Delay and Startup Interaction https://pharo.fogbugz.com/f/cases/11874 http://files.pharo.org/image/30/30486.zip

Oct. 15, 2013

Re: [Pharo-dev] bug: [4993] Typing cmd+L cancel all typing and we can't undo it [Terminated]

by Camillo Bruni

On 2013-10-15, at 14:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 15, 2013, at 1:41 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> I use Cmd-L almost as often than Cmd-P > > I got to know Cmd-l only because I got so upset of randomly loosing code. > It's the most horrible thing I ever saw in the system. > I never used it *ever*, but lost code *many* *many* times by accident without > even understanding what happened. > > I hate it. I follow the exact same reasoning :P

Oct. 15, 2013

Re: [Pharo-dev] bug: [4993] Typing cmd+L cancel all typing and we can't undo it [Terminated]

by Marcus Denker

On Oct 15, 2013, at 1:41 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I use Cmd-L almost as often than Cmd-P I got to know Cmd-l only because I got so upset of randomly loosing code. It's the most horrible thing I ever saw in the system. I never used it *ever*, but lost code *many* *many* times by accident without even understanding what happened. I hate it. Marcus

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Camillo Bruni

processing.org uses monospaced font, these are the art guys that have more sense graphics than any one this mailinglist (BTW, how many of you have visited an art school?) Besides Smalltalk, I don't know any other language that would use proportial fonts. After that, anybody who really knows how to use Pharo can modify it. The newcomer is the only one you target... On 2013-10-15, at 13:57, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Interesting discussion. I'll raise a few issues. > > Le 15/10/2013 13:29, Esteban Lorenzano a Ã©crit : >> well... fonts and UX in general are two different (yet related) issues. >> >> UX is a huge an complicated task, and has to be taken very seriously if we want to succeed. To allow the appropriate/productive/happy flows in an environment requires a lot of effort and to put all the pieces together. >> Yes, I know, that sounds so general that is like not saying anything :) >> Here is the concrete: Put all the UX pieces together requires a lot of effort usually not taken into account. That's how the UX evolved more or less the same way as morphic: a patch over a patch without much thinking about the issue, just takign what is there and parching/extending as needed. As morphic, the current UX in pharo is broken: there is no coherence between tools and sometimes even inside the same tool (for example nautilus has different behavior inside the code panel than in the list panels on top). >> This is not the fault of any tool, just a consequence of how evolution was managed until now. > > Some of the thing most forgot is that when you do a GUI, what takes time is not doing it, it's polishing it. Making sure all small things play together nicely, and that you've spent days trying to get that drag and drop to work in the perfect way, with the right feedback and all (and focus navigation, and...). > >> So, we wanted a better UX for Pharo3 that included: a new Theme, new Icon set, and new tools that worked well together. But task demonstrated to be a hard to beat beast, and we just moved forward in small areas (there is for example a new centralized menu coming along with a new spotlight). >> And there is a prototype of a new theme and also some icons that where thought specially and that will fit nicely. But they will not be ready this year and after thinking a while (and getting feedback of people in community), we decided, for Pharo3: >> >> - adopt the glamour theme. This is a step forward our current one because glamour guys (specially Doru) continued working on it to have a really clean and simple theme. > > Is it the default theme coming with the latest 3.0, with that flat look? Hate it because it breaks one HCI guideline visual cue: feedback when pressing on a GUI element (scrollbars, buttons); there is none in that theme. > > There it looks like a step backward, coming back to the squeak look (which turned me away from squeak for many years: yes that's not rational but can't get over it. Pharo was the first to give me back the feedback at the GUI level) > >> - adopt the EclipsePack theme because is an iconset specially thought for programming that plays very well together. No matter if you do not like Eclipse (even if I think you are missing the relevance of Eclipse and a lot of good ideas that we could take from them), is about creating a unified vision. The old icon set (famfam) was not intended for programming environment and also there were a lot of different icons incorporated anarchically. > > Iconset are hard. But some of the Eclipse iconset are downright ugly (packages). > >> - adopt a monospaced font for coding (right now Source Code Pro) and a non-monospaced for the rest (right now Open Sans). > > Hum. Once you're set on a non-monospaced font for coding, as most smalltalkers have, going back to a monospaced font will hurt... I'm not even using a monospaced font for coding in C :( > >> The objective is to offer a L&F that where visual elements plays well together. > > Work on that is the real key. Not sure the theme changes are part of it, however. > > I value more a drive to get everything Spec-iffied: tends to create a lot of common look and feel because applications tend to behave in the same way. > >> And there is another more important (IMHO) objective: to offer newcomers an environment easier to approach. Pharo (and all Smalltalk-inspired environments) is already very alien for newcomers. We get a lot of power in exchange of that alienish stuff, but very often the curve of learning or acceptance is too high and people that could step closer to us are pushed away. So, my idea is to keep been as alien as possible in the things that make us Pharo and be the less alien possible in the rest: A nice L&F that can be feel as "some kind" familiar, is part of it. > > It's a good objective, but... There is something there; Pharo is different enough in it's approach that trying to match Eclipse won't work and may even disrupt more, because you will make it alike where it is not. > >> Said so... well you still can switch back to the old and ugly (IMO) L&F executing some lines of code in your workspace. > > Or a setting somewhere :) > >> Same to fonts: monospaced fonts is the worldwide accepted way of present source code. Why should we stay different? > > I wouldn't be so sure of that. > >> In any case, please give it a chance before drop it (once I can actually see why the fonts are not really applied) and we'll see how it works. > > I will :) But, I'd be frank, here none of us is a HCI specialist, and it shows. Sorry, but it does. No usability testing, no look into HCI guidelines, but, at the same time, probably the most advanced GUI toolkit available (Morphic), some of the best mind when it comes to architecturing GUI code (and code on average), and the most productive environment around. > > If you want to make it familiar, look into Dolphin and VisualWorks and copy that :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Oct. 15, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30485 Home: https://github.com/pharo-project/pharo-core

Oct. 15, 2013

[pharo-project/pharo-core] ed1d4d: 30485

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: ed1d4dfeec7a6420d2a949225179476e8741cb70 https://github.com/pharo-project/pharo-core/commit/ed1d4dfeec7a6420d2a94922… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-15 (Tue, 15 Oct 2013) Changed paths: M Fuel-Core.package/FLAnalyzer.class/class/accessing/defaultGlobalSymbols.st R Manifest-Core.package/extension/CompiledMethod/instance/textBehavior.st R Manifest-Core.package/extension/TClassDescription/instance/textBehavior.st M Manifest-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st M Morphic-Base-Worlds.package/WorldMorph.class/class/system startup/shutDown.st M Morphic-Base-Worlds.package/WorldMorph.class/class/system startup/startUp.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script140.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30485.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Text-Edition.package/EditorFindReplaceDialogWindow.class/class/initializing/cleanUp.st M Text-Edition.package/EditorFindReplaceDialogWindow.class/class/initializing/initialize.st R Text-Edition.package/EditorFindReplaceDialogWindow.class/class/initializing/startUp.st Log Message: ----------- 30485 11883 Clean 2 classes from Startup and Shutdownlist each https://pharo.fogbugz.com/f/cases/11883 11884 Remove global ImageImports https://pharo.fogbugz.com/f/cases/11884 11882 Small cleanup in Manifest https://pharo.fogbugz.com/f/cases/11882 http://files.pharo.org/image/30/30485.zip

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Goubier Thierry

Interesting discussion. I'll raise a few issues. Le 15/10/2013 13:29, Esteban Lorenzano a Ã©crit : > well... fonts and UX in general are two different (yet related) issues. > > UX is a huge an complicated task, and has to be taken very seriously if we want to succeed. To allow the appropriate/productive/happy flows in an environment requires a lot of effort and to put all the pieces together. > Yes, I know, that sounds so general that is like not saying anything :) > Here is the concrete: Put all the UX pieces together requires a lot of effort usually not taken into account. That's how the UX evolved more or less the same way as morphic: a patch over a patch without much thinking about the issue, just takign what is there and parching/extending as needed. As morphic, the current UX in pharo is broken: there is no coherence between tools and sometimes even inside the same tool (for example nautilus has different behavior inside the code panel than in the list panels on top). > This is not the fault of any tool, just a consequence of how evolution was managed until now. Some of the thing most forgot is that when you do a GUI, what takes time is not doing it, it's polishing it. Making sure all small things play together nicely, and that you've spent days trying to get that drag and drop to work in the perfect way, with the right feedback and all (and focus navigation, and...). > So, we wanted a better UX for Pharo3 that included: a new Theme, new Icon set, and new tools that worked well together. But task demonstrated to be a hard to beat beast, and we just moved forward in small areas (there is for example a new centralized menu coming along with a new spotlight). > And there is a prototype of a new theme and also some icons that where thought specially and that will fit nicely. But they will not be ready this year and after thinking a while (and getting feedback of people in community), we decided, for Pharo3: > > - adopt the glamour theme. This is a step forward our current one because glamour guys (specially Doru) continued working on it to have a really clean and simple theme. Is it the default theme coming with the latest 3.0, with that flat look? Hate it because it breaks one HCI guideline visual cue: feedback when pressing on a GUI element (scrollbars, buttons); there is none in that theme. There it looks like a step backward, coming back to the squeak look (which turned me away from squeak for many years: yes that's not rational but can't get over it. Pharo was the first to give me back the feedback at the GUI level) > - adopt the EclipsePack theme because is an iconset specially thought for programming that plays very well together. No matter if you do not like Eclipse (even if I think you are missing the relevance of Eclipse and a lot of good ideas that we could take from them), is about creating a unified vision. The old icon set (famfam) was not intended for programming environment and also there were a lot of different icons incorporated anarchically. Iconset are hard. But some of the Eclipse iconset are downright ugly (packages). > - adopt a monospaced font for coding (right now Source Code Pro) and a non-monospaced for the rest (right now Open Sans). Hum. Once you're set on a non-monospaced font for coding, as most smalltalkers have, going back to a monospaced font will hurt... I'm not even using a monospaced font for coding in C :( > The objective is to offer a L&F that where visual elements plays well together. Work on that is the real key. Not sure the theme changes are part of it, however. I value more a drive to get everything Spec-iffied: tends to create a lot of common look and feel because applications tend to behave in the same way. > And there is another more important (IMHO) objective: to offer newcomers an environment easier to approach. Pharo (and all Smalltalk-inspired environments) is already very alien for newcomers. We get a lot of power in exchange of that alienish stuff, but very often the curve of learning or acceptance is too high and people that could step closer to us are pushed away. So, my idea is to keep been as alien as possible in the things that make us Pharo and be the less alien possible in the rest: A nice L&F that can be feel as "some kind" familiar, is part of it. It's a good objective, but... There is something there; Pharo is different enough in it's approach that trying to match Eclipse won't work and may even disrupt more, because you will make it alike where it is not. > Said so... well you still can switch back to the old and ugly (IMO) L&F executing some lines of code in your workspace. Or a setting somewhere :) > Same to fonts: monospaced fonts is the worldwide accepted way of present source code. Why should we stay different? I wouldn't be so sure of that. > In any case, please give it a chance before drop it (once I can actually see why the fonts are not really applied) and we'll see how it works. I will :) But, I'd be frank, here none of us is a HCI specialist, and it shows. Sorry, but it does. No usability testing, no look into HCI guidelines, but, at the same time, probably the most advanced GUI toolkit available (Morphic), some of the best mind when it comes to architecturing GUI code (and code on average), and the most productive environment around. If you want to make it familiar, look into Dolphin and VisualWorks and copy that :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 15, 2013

Re: [Pharo-dev] default monospaced code font

by Sven Van Caekenberghe

On 15 Oct 2013, at 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > well... fonts and UX in general are two different (yet related) issues. > > UX is a huge an complicated task, and has to be taken very seriously if we want to succeed. To allow the appropriate/productive/happy flows in an environment requires a lot of effort and to put all the pieces together. > Yes, I know, that sounds so general that is like not saying anything :) > Here is the concrete: Put all the UX pieces together requires a lot of effort usually not taken into account. That's how the UX evolved more or less the same way as morphic: a patch over a patch without much thinking about the issue, just takign what is there and parching/extending as needed. As morphic, the current UX in pharo is broken: there is no coherence between tools and sometimes even inside the same tool (for example nautilus has different behavior inside the code panel than in the list panels on top). > This is not the fault of any tool, just a consequence of how evolution was managed until now. > So, we wanted a better UX for Pharo3 that included: a new Theme, new Icon set, and new tools that worked well together. But task demonstrated to be a hard to beat beast, and we just moved forward in small areas (there is for example a new centralized menu coming along with a new spotlight). > And there is a prototype of a new theme and also some icons that where thought specially and that will fit nicely. But they will not be ready this year and after thinking a while (and getting feedback of people in community), we decided, for Pharo3: > > - adopt the glamour theme. This is a step forward our current one because glamour guys (specially Doru) continued working on it to have a really clean and simple theme. > - adopt the EclipsePack theme because is an iconset specially thought for programming that plays very well together. No matter if you do not like Eclipse (even if I think you are missing the relevance of Eclipse and a lot of good ideas that we could take from them), is about creating a unified vision. The old icon set (famfam) was not intended for programming environment and also there were a lot of different icons incorporated anarchically. > - adopt a monospaced font for coding (right now Source Code Pro) and a non-monospaced for the rest (right now Open Sans). I agree with everything, except the monospaced font. When, where, how was this decided ? I didn't see any discussion about this. I would be very surprised if you, or anyone else of the key developers, used that font. Anyone else having an opinion about the mono spaced font ? It is not by erasing all differences with other systems that we will gain traction ! BTW: I don't see the any monospaced font in 30484, luckily ;-) > The objective is to offer a L&F that where visual elements plays well together. > And there is another more important (IMHO) objective: to offer newcomers an environment easier to approach. Pharo (and all Smalltalk-inspired environments) is already very alien for newcomers. We get a lot of power in exchange of that alienish stuff, but very often the curve of learning or acceptance is too high and people that could step closer to us are pushed away. So, my idea is to keep been as alien as possible in the things that make us Pharo and be the less alien possible in the rest: A nice L&F that can be feel as "some kind" familiar, is part of it. > > Said so... well you still can switch back to the old and ugly (IMO) L&F executing some lines of code in your workspace. > > Same to fonts: monospaced fonts is the worldwide accepted way of present source code. Why should we stay different? > > In any case, please give it a chance before drop it (once I can actually see why the fonts are not really applied) and we'll see how it works. > > Esteban > > > On Oct 15, 2013, at 12:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 15 Oct 2013, at 08:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> the issue that sets the new Pharo 3.0 look&feel uses a monospaced font >>> for the code. It is only a coincidence that it is not set this way in >>> the prebuild Pharo image. >>> >>> I have big doubts if this is the way to go. I think that proportional >>> fonts are more natural for Smalltalk and without them the code is >>> harder to read and not so beauty. I think that something like elastic >>> tabstops would be much better solution. >>> http://tibleiz.net/code-browser/elastic-tabstops.html >> >> Yeah, I can't imagine many Smalltalkers liking a mono-spaced font, I personally hate it. >> >>> On the other way, it is only my personal opinion and if you think that >>> the Eclipse-like look will attract more new users... >> >> I don't like Eclipse ;-) But like Marcus says, it is just a different icon set. We want win any points on originality or personality though, which is a missed opportunity. > >

Oct. 15, 2013

Re: [Pharo-dev] bug: [4993] Typing cmd+L cancel all typing and we can't undo it [Terminated]

by Benjamin

Ben On Oct 15, 2013, at 1:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Kilon, > > Sorry for the late reply. The Cmd-L is useful as soon as you evaluate code in your code browser. Consider the following scenario that I am very sure you am facing every single day: > > 1 - Define a method on a class: > -=-=--=-=--=-=--=-=- > foo > ^ 1 + 2 > -=-=--=-=--=-=--=-=- > > 2 - It often happen that you want to know the value of some expression in the method body. Select "1 + 2" and press Cmd-P. It prints you the value 3, great. > > 3 - Click on a different method or close the browser. And you get this stupid question "Code has been modified. What do you want to do". Isn't it obvious what I want to do? The browser is asking me whether I may want to accept the method, even if it is not compilable (i.e., the code "^ 1 + 2 3" is not proper smalltalk). So stupid it is. Even worse: if you press backspace to remove the 3, the code browser is still notifying you the source code has changed, even if the content is the same. Not in Nautilus :P > > This is so frustrating. I am sure you are facing this questions many times a day. Cmd-L is here to help (but it poorly helps, I agree). After you have evaluated "1 + 2" and have "3" displayed, you can press Cmd-L to restore the original method content and makes the browser forget that I have modified the method body. No more question is asked when I delete the browser or select a different method. > > Now, making Cmd-L raises a question would simply makes the bidding not useful at all. Igor showed me this bidding, which makes me suspect he uses it since he knows it. I think Lukas was using it as well. Making the browser ask yet another question such as "your content is about to be deleted, are you sure you want to continue" does not make the environment more intelligent in my opinion, but just more talkative. > > As your original post suggest, the text editor needs improvement. For example, if Cmd-L is really disturbing you, then remove it, but make sure the browser does not complain when the text content is the same than the original method (or class definition). This would be great actually. > > On a slightly different front, I have seen that the create temporary method is broken. Last time I've seen this was many years ago... > > Alexandre > > > On Oct 14, 2013, at 10:05 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > >> Definetly not a regression. If you make a mistake your work is gone, bye bye, >> hasta la vista baby. Personally I dont use, or see myself using CMD+L on a >> daily basis. Its highly unlikely that I will code in several lines of code >> and will want to discard them completely. In 99/100 cases I just slightly >> change, edit the code. So we definitely have a different workflow on this >> one. >> >> You are much better coders than me, so I understand you may use that feature >> heavily. >> >> Undo was my first goal too, but trying to understand how undo is implemented >> felt like hammering my face on a wall. The amount of spaggetication in the >> code is beyond understanding for me, on the 1 hour I invested of finding a >> bug fix. So I spent like 50 minutes trying to understand undo, failed >> miserably, spent rest 10 implementing the dialog box. And yes I am not very >> smart or good coder. >> >> I will try to take another look at undo today and have another go at this, >> but If I found no solution I will leave the fix as it is. Chances are I wont >> figure this out, so don't hold your breath. >> >> Bottom line is that in case of proper software the user should not allowed >> to do things that are unrecoverable without a prompt. So not implementing a >> fix at all, at least for me is considered very bad. But this is just my >> personal opinion. >> >> >> >> -- >> View this message in context: http://forum.world.st/bug-4993-Typing-cmd-L-cancel-all-typing-and-we-can-t-… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Oct. 15, 2013