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

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

by Alexandre Bergel

> So you can think of it as ctrl+l+enter . Saying that I will have another go > on undo , I really want to understand how undo works not just for this fix > but generally. I agree that the fix is not ideal as it is but unfortunately > my understanding of Pharo is very limited right now. No stress. We are here all learning :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2013

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

by Alexandre Bergel

I use Cmd-L almost as often than Cmd-P. Making it asking an obvious question which require a obvious answer is counter productive. If one is really afraid to loose the content, then use the Undo queue for this. So, Cmd-L should use the Undo queue, not asking more questions. Alexandre On Oct 14, 2013, at 10:41 AM, btc(a)openInWorld.com wrote: > Alexandre Bergel wrote: >> Hi! >> >> Thanks Kilon for working on the Contr-l key binding. I use this control key binding a lot, and actually, it is really rare when I do a mistake. Having to press OK whenever I do this sounds like a regression to me. Why not always inserting the text in the undo queue before replacing the text? >> >> Alexandre >> >> > > I originally had the same opinion, and I had a go getting undo to work but failed. So I tested kilon's slice and it seemed to not adversely affect my workflow. I wonder if a compromise might be the ability to acknowledge the alert dialog with <ctrl-l> - so you don't have to move your fingers from the shortcut, and still provides a guard against accidental reset. > -ben > >> >>> Le 13-10-2013 Ã 8:08, kilon <thekilon(a)yahoo.co.uk> >>> a Ã©crit : >>> >>> This is my first pharo bug fix so be gentle :D >>> >>> >>> https://pharo.fogbugz.com/f/cases/4993/Typing-cmd-L-cancel-all-typing-and-w… >>> <https://pharo.fogbugz.com/f/cases/4993/Typing-cmd-L-cancel-all-typing-and-w…> >>> >>> >>> As I explain in the link and in my commit log , I have added a confirm >>> dialog so the user in case he accidentally pressed CMD+L will click no and >>> his changes will not be lost. I have verified the bug fix with the latest >>> pharo build. >>> >>> >>> >>> -- >>> 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

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

by Alexandre Bergel

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. 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

Re: [Pharo-dev] default monospaced code font

by Esteban Lorenzano

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). 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] Render images - Porting from Cincom VW to Pharo

by Gustavo Jansen

any progress or clues? I have a similar problem. I'm dealing with a legacy code that takes a huge string and builds an executable file. I tried the solution with Base64MimeConverter, but it doesn't seem to convert the entire string. -- View this message in context: http://forum.world.st/Render-images-Porting-from-Cincom-VW-to-Pharo-tp46548… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2013

Re: [Pharo-dev] Is there a Roadmap for Pharo 3.0 and Pharo 4.0

by Marcus Denker

On Oct 15, 2013, at 12:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Oct 15, 2013, at 9:43 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > >> I really like the idea of roadmap. In an open source project people are free >> to work in anything they like , even bring new nice features of their design >> as long as they don't disturb the existing code. >> >> But the same people, including me, or even mere users , wonder where the >> software is heading. Even an exploration ship , that sets to explore new >> areas has goals. I would like to see in the pharo website a roadmap not just >> for 3 but even for pharo 4. I know that Stephane has given a presentation >> about pharo 3 roadmap , maybe you could link those slides. > > the problem with this is that we do not have a clear roadmap for Pharo4 (yet). > How it works now is: at the beginning of a year iteration we make a list of what we want, taking into account what emerged latest year (both new possibilities opened and new/old problems that emerged). > > That gives us what we can more or less call a "next release road map". And is "more or less" because situation can change. For example we wanted a complete revamp of Pharo3 L&F, and we wanted also a complete migration of Morph to be rendered with Athens, and reality showed that is not achievable this year... so it will wait until next one (and that does not means at all that we stopped work on that area, just that the completion of the task will take more time than expected). > So... what's the roadmap for Pharo4? No Idea :) > What we already know is that we made a huge move forward in infrastructure for Pharo3 (starting by Opal, but not restrained to that), and now we want to focus in the tools (but without doing *just* that, because there are lots of tasks to do in kernel, modularization, cleanups, etc.) > > in general, for pharo there is a vision document that shows the long (really long) term goals. Now I do not remember where is it, but should be somewhere in the pharo site (probably not visible enough). > The problem is that I think we already did a lot of that vision. We need a new one.

Oct. 15, 2013

Re: [Pharo-dev] Is there a Roadmap for Pharo 3.0 and Pharo 4.0

by Esteban Lorenzano

On Oct 15, 2013, at 9:43 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > I really like the idea of roadmap. In an open source project people are free > to work in anything they like , even bring new nice features of their design > as long as they don't disturb the existing code. > > But the same people, including me, or even mere users , wonder where the > software is heading. Even an exploration ship , that sets to explore new > areas has goals. I would like to see in the pharo website a roadmap not just > for 3 but even for pharo 4. I know that Stephane has given a presentation > about pharo 3 roadmap , maybe you could link those slides. the problem with this is that we do not have a clear roadmap for Pharo4 (yet). How it works now is: at the beginning of a year iteration we make a list of what we want, taking into account what emerged latest year (both new possibilities opened and new/old problems that emerged). That gives us what we can more or less call a "next release road map". And is "more or less" because situation can change. For example we wanted a complete revamp of Pharo3 L&F, and we wanted also a complete migration of Morph to be rendered with Athens, and reality showed that is not achievable this year... so it will wait until next one (and that does not means at all that we stopped work on that area, just that the completion of the task will take more time than expected). So... what's the roadmap for Pharo4? No Idea :) What we already know is that we made a huge move forward in infrastructure for Pharo3 (starting by Opal, but not restrained to that), and now we want to focus in the tools (but without doing *just* that, because there are lots of tasks to do in kernel, modularization, cleanups, etc.) in general, for pharo there is a vision document that shows the long (really long) term goals. Now I do not remember where is it, but should be somewhere in the pharo site (probably not visible enough). > > So what is the future of pharo ? > > Another request for the website would be a small collection of bullet points > about what makes Pharo special, in the about section there is a very general > description of what pharo is. I would like something more concrete. I want > specific features, specific libraries. Assume that people reading this have > no idea what smalltalk is and no idea what Squeak is. 10-30 bullet points > should be a good start. No lengthy descriptions, straight to the point. > > What you feel about this ? yep, that's a good point :) > > > > -- > View this message in context: http://forum.world.st/Is-there-a-Roadmap-for-Pharo-3-0-and-Pharo-4-0-tp4714… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 15, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 15, 2013

[pharo-project/pharo-core] 824bfe: 20624

by GitHub

Branch: refs/heads/2.0 Home: https://github.com/pharo-project/pharo-core Commit: 824bfeb8614fea972c345306599b6e8822528d43 https://github.com/pharo-project/pharo-core/commit/824bfeb8614fea972c345306… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-15 (Tue, 15 Oct 2013) Changed paths: M FileSystem-Core.package/UnixResolver.class/instance/preferences.st M FileSystem-Core.package/UnixResolver.class/methodProperties.json M NautilusRefactoring.package/NautilusRefactoring.class/instance/privatePullUpInstVarFrom..st M NautilusRefactoring.package/NautilusRefactoring.class/methodProperties.json A Polymorph-Widgets.package/EntryCompletion.class/instance/closeIfNotNeeded..st R Polymorph-Widgets.package/EntryCompletion.class/instance/closeIfNotOver..st M Polymorph-Widgets.package/EntryCompletion.class/methodProperties.json M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/selectFirstItem.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/methodProperties.json M Polymorph-Widgets.package/PluggableTextFieldMorph.class/instance/chooserHasFocus.st M Polymorph-Widgets.package/PluggableTextFieldMorph.class/instance/drawOn..st M Polymorph-Widgets.package/PluggableTextFieldMorph.class/methodProperties.json M ScriptLoader20.package/ScriptLoader.class/instance/commentForCurrentUpdate.st A ScriptLoader20.package/ScriptLoader.class/instance/script597.st A ScriptLoader20.package/ScriptLoader.class/instance/update20624.st M ScriptLoader20.package/ScriptLoader.class/methodProperties.json Log Message: ----------- 20624 11872 PreferenceStartup raises an exception on StackVM 2.0 Version On Raspberry https://pharo.fogbugz.com/f/cases/11872 11853 Inst Var Pull Up does not work https://pharo.fogbugz.com/f/cases/11853 11859 Backport 2.0: Issue 11549 PluggableTextMorph closes completion menu on keydown https://pharo.fogbugz.com/f/cases/11859

Oct. 15, 2013

[update 2.0] #20624

by Marcus Denker

20624 ----- 11872 PreferenceStartup raises an exception on StackVM 2.0 Version On Raspberry https://pharo.fogbugz.com/f/cases/11872 11853 Inst Var Pull Up does not work https://pharo.fogbugz.com/f/cases/11853 11859 Backport 2.0: Issue 11549 PluggableTextMorph closes completion menu on keydown https://pharo.fogbugz.com/f/cases/11859 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.780.diff http://ss3.gemstone.com/ss/Pharo20/NautilusRefactoring-MarcusDenker.80.diff http://ss3.gemstone.com/ss/Pharo20/FileSystem-Core-MarcusDenker.71.diff

Oct. 15, 2013