September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] getting rid of these boring questions and popup

by Schwab,Wilhelm K

Stef, I'm all for trying things like this, but have my reservation about replacing a good text editor; adding alternatives is fine, of course. Are you going to be in Orlando for OOPSLA? I do not have funding to register, but live close enough that it would be a shame not to meet up on a free evening for you. Not only would I enjoy meeting you and others, but I would like to give you a brief tour of Dolphin's IDE (such as its definition/code/comment panes) and a few goodies that I have found helpful. There are some simple changes we could make that would greatly enhance the usability of the browsers and other tools. Events or announcements added to the tools would enable extensions like those that can be very effective in the Dolphin IDE. I would welcome an opportunity to demonstrate some simple changes that would help us. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, September 12, 2009 12:03 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] getting rid of these boring questions and popup I agree. :) I would love to have that. this is why we should really have a system to experiment these ideas. Stef On Sep 12, 2009, at 6:15 PM, Philippe Marschall wrote: > StÃ©phane Ducasse wrote: >> well for this we will have to rewrite paragraphEditor :) So in making >> pharo moves forward we will have to accept losing some feedback. > > The feedback is still there. The piece of code is still marked as a > problem. It just doesn't get in your way. > >> But yes your idea is cool. > > You'll have to do more than that. I think this whole 80ies style > browser that's based on scrolling, clicking and popups doesn't cut it > anymore and adding more tabs and buttons isn't gonna fix it. > > Example, why is the browser the size it currently is? Because that was > more or less full screen in the 80ies. Consequence you'll always have > to resize and scroll when you open a browser because the category and > class panes are too small. I see how this was cool, exciting and new > in the 80ies but today it gets in my way. > > Example, I want to go to a method in a class. Either I click '--all--' > and scroll, scroll, look, scroll, scroll back or I click through the > protocols until I found on it. When I'm in Eclipse and want to open a > variable or method declaration I hit Ctrl + O, Eclipse shows me a > short outline of the class. Like in Firefox Awesome Bar it filters the > list as I type part of the name. Once I select something it closes and > goes there. Zero mouse activity. Zero additional window. When I'm in a > method and want to go to a method invoked there either I Ctrl + click > it or I hit F3. When I want to see the hierarchy of a class or the > inheritance of a method I just do Ctrl + T and an inline window opens. > It closes when I select something or hit Esc. Pharo stacks so many > windows on top of each other that you're never going to find your way > back. So at the end of the day you just close dozens of windows. > > Short anecdote, I our current project we don't ask the user for > confirmation, ever. If he decides to delete Migros, we do it without > asking. The previous version of the product did but users just > developed a reflex to click popups away without even reading them. > > And don't get me started on breakpoints. Or blocking the UI. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Schwab,Wilhelm K

Philippe, I am not an eclipse user, so I could be missing something, just as I think people who have not worked with Dolphin's IDE cannot fully appreciate its robustness. However, I find it hard to believe the scrollbars and time-tested methods of text editing can be rendered obsolete with a few keyboard shortcuts. You would no doubt find some of my methods too long; I respond that the alternative has too many entry points. The extra entry points are all the more offensive to me without Dolphin's ability to apply multile categories to methods - again, something one has to experience to fully appreciate. The idea of non-modally flagging offending code is well taken, but I find two flaws: (1) the highlighting itself could easily "get in my way" by adding visual clutter; (2) you seem to assume there is at most one rule violation. You say that adding panes will not fix things, but it seems that a pane showing the broken rules is exactly what is needed. An alternative might be a drop-down of broken rules, whith the selection (defaulting to nothing) highlighting the code breaking that rule. I agree that the current browser's panes are not optimally sized. However, I doubt that there is a univeral preference that will satisfy all users. Further, I have never like "system browsers" in Smalltalk systems; a filtered class hierarchy browser is vastly superior IMHO. Again going back to Dolphin, it's use of tabs for the various browser panes is subtly but vastly superior to Squeak and Pharo's use of buttons to change the pane contents. The difference is that multiple views on a selection (class, class+method, class+method+instance variable, etc.) can be "open" at the same time. It becomes much easy to use one browser to edit a method, go to the class definition to view/copy variable names, go back to the code to keep typing, and not have to accept the method along the way. Any promise to provide summaries or alternate representation of code always makes me nervous; it is fine as an option, but not as a replacement for text editing. I format my code in particular ways, including (especially!!!) comments, and that formatting is analogous to phrasing in music. In porting a lot of my Dolphin code in recent months, I have been reminded of how important my month-year tagged comments can be - they helped me find three long-standing bugs in just the past week. For two of those bugs, the seeds of the solution were suggested by the comments themselves. I like my code and my scrollbars. Version history can provide some of the same assistance, but it gets clobbered by compressing changes and requires one to compare the versions and/or read through a machine's efforts to present the differences. The comments I leave for myself are designed to be useful to me in the future, and have stood the test of time. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall Sent: Saturday, September 12, 2009 11:16 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] getting rid of these boring questions and popup StÃ©phane Ducasse wrote: > well for this we will have to rewrite paragraphEditor :) So in making > pharo moves forward we will have to accept losing some feedback. The feedback is still there. The piece of code is still marked as a problem. It just doesn't get in your way. > But yes your idea is cool. You'll have to do more than that. I think this whole 80ies style browser that's based on scrolling, clicking and popups doesn't cut it anymore and adding more tabs and buttons isn't gonna fix it. Example, why is the browser the size it currently is? Because that was more or less full screen in the 80ies. Consequence you'll always have to resize and scroll when you open a browser because the category and class panes are too small. I see how this was cool, exciting and new in the 80ies but today it gets in my way. Example, I want to go to a method in a class. Either I click '--all--' and scroll, scroll, look, scroll, scroll back or I click through the protocols until I found on it. When I'm in Eclipse and want to open a variable or method declaration I hit Ctrl + O, Eclipse shows me a short outline of the class. Like in Firefox Awesome Bar it filters the list as I type part of the name. Once I select something it closes and goes there. Zero mouse activity. Zero additional window. When I'm in a method and want to go to a method invoked there either I Ctrl + click it or I hit F3. When I want to see the hierarchy of a class or the inheritance of a method I just do Ctrl + T and an inline window opens. It closes when I select something or hit Esc. Pharo stacks so many windows on top of each other that you're never going to find your way back. So at the end of the day you just close dozens of windows. Short anecdote, I our current project we don't ask the user for confirmation, ever. If he decides to delete Migros, we do it without asking. The previous version of the product did but users just developed a reflex to click popups away without even reading them. And don't get me started on breakpoints. Or blocking the UI. Cheers Philippe _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

I agree. :) I would love to have that. this is why we should really have a system to experiment these ideas. Stef On Sep 12, 2009, at 6:15 PM, Philippe Marschall wrote: > StÃ©phane Ducasse wrote: >> well for this we will have to rewrite paragraphEditor :) >> So in making pharo moves forward we will have to accept losing some >> feedback. > > The feedback is still there. The piece of code is still marked as a > problem. It just doesn't get in your way. > >> But yes your idea is cool. > > You'll have to do more than that. I think this whole 80ies style > browser > that's based on scrolling, clicking and popups doesn't cut it anymore > and adding more tabs and buttons isn't gonna fix it. > > Example, why is the browser the size it currently is? Because that was > more or less full screen in the 80ies. Consequence you'll always > have to > resize and scroll when you open a browser because the category and > class > panes are too small. I see how this was cool, exciting and new in the > 80ies but today it gets in my way. > > Example, I want to go to a method in a class. Either I click '--all--' > and scroll, scroll, look, scroll, scroll back or I click through the > protocols until I found on it. When I'm in Eclipse and want to open a > variable or method declaration I hit Ctrl + O, Eclipse shows me a > short > outline of the class. Like in Firefox Awesome Bar it filters the > list as > I type part of the name. Once I select something it closes and goes > there. Zero mouse activity. Zero additional window. When I'm in a > method > and want to go to a method invoked there either I Ctrl + click it or I > hit F3. When I want to see the hierarchy of a class or the inheritance > of a method I just do Ctrl + T and an inline window opens. It closes > when I select something or hit Esc. Pharo stacks so many windows on > top > of each other that you're never going to find your way back. So at the > end of the day you just close dozens of windows. > > Short anecdote, I our current project we don't ask the user for > confirmation, ever. If he decides to delete Migros, we do it without > asking. The previous version of the product did but users just > developed > a reflex to click popups away without even reading them. > > And don't get me started on breakpoints. Or blocking the UI. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Philippe Marschall

StÃ©phane Ducasse wrote: > well for this we will have to rewrite paragraphEditor :) > So in making pharo moves forward we will have to accept losing some > feedback. The feedback is still there. The piece of code is still marked as a problem. It just doesn't get in your way. > But yes your idea is cool. You'll have to do more than that. I think this whole 80ies style browser that's based on scrolling, clicking and popups doesn't cut it anymore and adding more tabs and buttons isn't gonna fix it. Example, why is the browser the size it currently is? Because that was more or less full screen in the 80ies. Consequence you'll always have to resize and scroll when you open a browser because the category and class panes are too small. I see how this was cool, exciting and new in the 80ies but today it gets in my way. Example, I want to go to a method in a class. Either I click '--all--' and scroll, scroll, look, scroll, scroll back or I click through the protocols until I found on it. When I'm in Eclipse and want to open a variable or method declaration I hit Ctrl + O, Eclipse shows me a short outline of the class. Like in Firefox Awesome Bar it filters the list as I type part of the name. Once I select something it closes and goes there. Zero mouse activity. Zero additional window. When I'm in a method and want to go to a method invoked there either I Ctrl + click it or I hit F3. When I want to see the hierarchy of a class or the inheritance of a method I just do Ctrl + T and an inline window opens. It closes when I select something or hit Esc. Pharo stacks so many windows on top of each other that you're never going to find your way back. So at the end of the day you just close dozens of windows. Short anecdote, I our current project we don't ask the user for confirmation, ever. If he decides to delete Migros, we do it without asking. The previous version of the product did but users just developed a reflex to click popups away without even reading them. And don't get me started on breakpoints. Or blocking the UI. Cheers Philippe

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

well for this we will have to rewrite paragraphEditor :) So in making pharo moves forward we will have to accept losing some feedback. But yes your idea is cool. Stef On Sep 12, 2009, at 4:49 PM, Philippe Marschall wrote: > StÃ©phane Ducasse wrote: >> Hi guys >> >> I would like what you think of these wonderful popups that try to >> help >> to > > Just do what Eclipse does. Highlight it as a problem and offer a quick > fix (Ctrl + 1). > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] May be some problems with MC history

by StÃ©phane Ducasse

Thanks dave. So far I found my way (but I will have a look) and I'm reading carefully the code to see the implication for the loading of the closure fixes. Stef On Sep 12, 2009, at 3:45 PM, David T. Lewis wrote: > On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote: >>> a couple of bugs when understanding the history based merge (ugly) >> >> It is not a merge operation, as I said in my mail. You are merely >> applying the changes representing a delta between two versions >> manually. That's all, no magic involved. >> >>> ? ? ? ?- adding the new method to a cs does not work if you did >>> not install >>> the code before (ok) >>> ? ? ? ?- class definition are not added (yeah) in the changeset. >>> Really cool! >> >> I don't understand what this has to do with change-sets? >> >> Class definitions are part of the patch that is calculated by >> Monticello. My guess is that the class didn't change for the delta >> you >> calculated. To illustrate, in the example above the changes between >> b.1 and b.2 don't show a class change that happened between a.1 and >> b.1, even if the delta depends on it. >> >> I use what I described all the time, it is maybe a bit tricky, but >> works really well. > > Stef, > > I don't know if this is helpful or not, but FYI Edgar De Cleene has > produced the list of change sets corresponding to the MC update stream > for Squeak trunk. See this thread on squeak-dev: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/13936… > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Philippe Marschall

StÃ©phane Ducasse wrote: > Hi guys > > I would like what you think of these wonderful popups that try to help > to Just do what Eclipse does. Highlight it as a problem and offer a quick fix (Ctrl + 1). Cheers Philippe

Sept. 12, 2009

Re: [Pharo-project] May be some problems with MC history

by David T. Lewis

On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote: > > a couple of bugs when understanding the history based merge (ugly) > > It is not a merge operation, as I said in my mail. You are merely > applying the changes representing a delta between two versions > manually. That's all, no magic involved. > > > ? ? ? ?- adding the new method to a cs does not work if you did not install > > the code before (ok) > > ? ? ? ?- class definition are not added (yeah) in the changeset. Really cool! > > I don't understand what this has to do with change-sets? > > Class definitions are part of the patch that is calculated by > Monticello. My guess is that the class didn't change for the delta you > calculated. To illustrate, in the example above the changes between > b.1 and b.2 don't show a class change that happened between a.1 and > b.1, even if the delta depends on it. > > I use what I described all the time, it is maybe a bit tricky, but > works really well. Stef, I don't know if this is helpful or not, but FYI Edgar De Cleene has produced the list of change sets corresponding to the MC update stream for Squeak trunk. See this thread on squeak-dev: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/13936… Dave

Sept. 12, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by StÃ©phane Ducasse

for pharo images since they are nicely packaged. http://code.google.com/p/pharo/wiki/MorphicExtrasSorting PharoMorphicExtras -> MorphExamplesAndDemos PharoSound -> SoundMorphicUserInterface Sound Thanks >> > Do you want these packages in all Pharo images or just for PBE? Where > can I find these packages? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] Getting Pharo 1.0 released

by Damien Cassou

On Fri, Sep 11, 2009 at 7:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes we should ask damien to add the demosAndSampleMorph package in the > script. > + Sound also. Do you want these packages in all Pharo images or just for PBE? Where can I find these packages? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 12, 2009