[Pharo-project] Initial experience coming from Squeak
I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with. And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing "good ideas" i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute? Suggestions: * Why shift for meta? On a Macbook (with one button), it's awkward to press shift+alt+click, and also disorienting to go back and forth from Squeak which is just alt+click. Is there a reason to not keep the convention? * what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually⦠Certainly not a big deal, but weird. I though of a few possible fixes: - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click) * bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow. * new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is. * Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok." Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an "unknown variable" popup, choose "define new class," click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - "refactor source->extract method" should be a single-line popup - and, "define new class->edit class definition" should be a multi-liner. Thanks for an awesome environment, and I will continue to contribute any way I can :) Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1799044... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
* Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok."
It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names?
Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an "unknown variable" popup, choose "define new class," click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol!  So:  - "refactor source->extract method" should be a single-line popup  - and, "define new class->edit class definition" should be a multi-liner.
I 100% agree on this, class definition from within the editor totally sucks. Unfortunately this is part of the compiler, not the browser so it requires a change to the parser. I propose the fix below, that also avoids the extra question of asking for the category name. This is unnecessary as it can be edited afterwards in the class definition anyway. http://code.google.com/p/pharo/issues/detail?id=2286 Name: Compiler-LukasRenggli.208 Author: lr Time: 9 April 2010, 8:23:45 am UUID: e0f99e58-08ce-46da-839d-88947b66d668 Ancestors: Compiler-StephaneDucasse.207 - simplify and improve the user experience for class definition while compiling a method Lukas -- Lukas Renggli www.lukas-renggli.ch
Thanks lukas Yes the code on the fly is terrible :) Fernando has been working on new version of textEditor and I will integrate them in 1.1 (with some bugs left) stef
* Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok."
It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names?
Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an "unknown variable" popup, choose "define new class," click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - "refactor source->extract method" should be a single-line popup - and, "define new class->edit class definition" should be a multi-liner.
I 100% agree on this, class definition from within the editor totally sucks. Unfortunately this is part of the compiler, not the browser so it requires a change to the parser. I propose the fix below, that also avoids the extra question of asking for the category name. This is unnecessary as it can be edited afterwards in the class definition anyway.
http://code.google.com/p/pharo/issues/detail?id=2286
Name: Compiler-LukasRenggli.208 Author: lr Time: 9 April 2010, 8:23:45 am UUID: e0f99e58-08ce-46da-839d-88947b66d668 Ancestors: Compiler-StephaneDucasse.207
- simplify and improve the user experience for class definition while compiling a method
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 9, 2010, at 8:26 AM, Lukas Renggli wrote:
* Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok."
It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names?
You could specialize the EntryFieldMorph Stef integrated in 1.1. It's a single line entry field, that when accepted with Character cr or escaped, announces it via Announcements. I've been wanting to implement a specialized SelectorWithArgumentsEntryField also, that heavlily uses the refactoring engine when the user enters input. Its in my todo list, but still couldn't find the right time. Fernando
Hi fernando I will integrate your changes + lukas and a couple of toher later today. Stef On Apr 9, 2010, at 9:45 AM, Fernando olivero wrote:
On Apr 9, 2010, at 8:26 AM, Lukas Renggli wrote:
* Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok."
It also annoys me sometimes too, but a few months back somebody was requesting exactly the opposite. The one-line input field does not work well if the method has more than one argument. I guess I need to build a dedicated editor for method names?
You could specialize the EntryFieldMorph Stef integrated in 1.1. It's a single line entry field, that when accepted with Character cr or escaped, announces it via Announcements.
I've been wanting to implement a specialized SelectorWithArgumentsEntryField also, that heavlily uses the refactoring engine when the user enters input. Its in my todo list, but still couldn't find the right time.
Fernando
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Sean, Thanks a lot for the valuable feedback! On Apr 9, 2010, at 05:57 , Sean P. DeNigris wrote:
I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with.
And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing "good ideas" i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute?
Normally I would do both. If you have code, commit it and create a ticket (not only for bugs but also for features). Then announce it in the mailing list. Since many people are busy, sometimes you don't get a response immediately, especially if it requires somebody loading the code and trying it out. In this case just send a reminder and explicitly ask people for feedback. For the list of suggestions you gave, you may want to wait for other feedback and then create single issues in the tracker for those that other people feel should be changed. Cheers, Adrian [...]
On Apr 9, 2010, at 5:57 AM, Sean P. DeNigris wrote:
I love the clean look with all the great developer features pre-installed (shout, OCompletion, etc.). It's been a pleasure to work with.
And, a few things stood out that didn't seem to work as well. I'm sharing them here because I wonder what your opinions are. Also, what is the policy about contributing "good ideas" i.e. new/altered features that are not bug fixes? Is it best to discuss them on the list like this, or submit a changeset right off the bat per http://code.google.com/p/pharo/wiki/HowToContribute?
Yes! We are open to a lot of suggestions. For example in 1.1 the way you define method category is waaaaaayyyyyyy better. Check it you will see (even if there is a small bug).
Suggestions: * Why shift for meta? On a Macbook (with one button), it's awkward to press shift+alt+click, and also disorienting to go back and forth from Squeak which is just alt+click. Is there a reason to not keep the convention?
I do not remember. What we did was to stop the halos popping up plague. You can get halos but only when you want.
* what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually⦠Certainly not a big deal, but weird. I though of a few possible fixes:
People already reported that to me informally A bug fix would be good. Can you open or check if there is bug entry?
- automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click)
* bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow.
sound like a good idea. suggestion: repost a mail with that title. open a bug entry. make noise so that ui aware people get a look :)
* new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is.
Good point. Same process. chekc the realstateAgent class
* Single/multi-line popups - when you're extracting a method via "refactor source," you get a huge multi-line popup window, which eats crs, so after you enter the name and hit return, you are still in the popup and must take your hands off the keyboard to click "ok." Now, fair enough, this might actually be a good thing in other circumstances, but - when you reference an unknown class, you get an "unknown variable" popup, choose "define new class," click through the category selection, you get a one-line popup to edit a paragraph-long class definition, lol! So: - "refactor source->extract method" should be a single-line popup - and, "define new class->edit class definition" should be a multi-liner.
It sucks!!!! I will integrate lukas changes.
Thanks for an awesome environment, and I will continue to contribute any way I can :)
Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1799044... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I filed bugs for these: Issue 2288: http://code.google.com/p/pharo/issues/detail?id=2288 : Sean P. DeNigris wrote:
* what is with the workflow of the default browser? When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced. But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually⦠Certainly not a big deal, but weird. I though of a few possible fixes: - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user) - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click)
Issue 2289: http://code.google.com/p/pharo/issues/detail?id=2289 : Sean P. DeNigris wrote:
* bizarre window changing - the (on Mac) Cmd+(hold arrow) to rotate through the open windows is pretty cool, but when you tap the arrow key (instead of holding it), it just goes back and forth between two windows, which I can't see a use for. It seems it would be more useful to have the behavior to be: if you hold down the Cmd key and repeatedly tap the arrow hit, the windows rotate one after the other until you get through them all and recycle and v.v. for the opposite direction arrow.
Issue 2290 : http://code.google.com/p/pharo/issues/detail?id=2290 : Sean P. DeNigris wrote:
* new windows e.g. workspaces appear wherever they feel like (is it a standard location?). It seems to flow better if they appeared where the user is already looking i.e. where the active hand is.
Sean P. DeNigris -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1819798... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
* what is with the workflow of the default browser?  When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced.  But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually⦠Certainly not a big deal, but weird.  I though of a few possible fixes:  - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user)  - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click)
Issue 2289: http://code.google.com/p/pharo/issues/detail?id=2289 :
1. Automatically selecting the text pane violates basic UI principles. In many cases this is not what you want, e.g. when you just browse existing code. 2. I don't see why not pre-selecting the template helps? I've quickly changed that, but clicking on it doesn't select it. However, whatever focus settings you've enabled in your Pharo image, double clicking onto the text pane selects everything. Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas Renggli wrote:
I don't see why not pre-selecting the template helps? I've quickly changed that, but clicking on it doesn't select it.
If the template is not pre-selected, single clicking off the template (in the pane below the bottom of the template) selects it. Also, I think pre-selecting when there's no possible way to make use of the pre-selection is kind of mean, like dangling a banana outside a monkey cage, lol. Sean -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1835637... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I don't see why not pre-selecting the template helps? I've quickly changed that, but clicking on it doesn't select it.
If the template is not pre-selected, single clicking off the template (in the pane below the bottom of the template) selects it.
As I said, I've removed the pre-selection and it does not work (or I don't understand it). Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas Renggli wrote:
I've removed the pre-selection and it does not work (or I don't understand it).
Yes, you're right (it was working for me because I had to click there once to deselect it, duh!). So maybe leaving it deselected and having the user double-click is the best compromise - no savings in steps, but more natural. Sean -- View this message in context: http://n4.nabble.com/Initial-experience-coming-from-Squeak-tp1799044p1835673... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
* what is with the workflow of the default browser?  When you click on a protocol, the method template appears in the bottom pane, all highlighted and ready to be replaced.  But because hovering over the pane doesn't give it the keyboard focus (like Squeak), you have to click in it, which unselects the template, which you then have to reselect manually⦠ Certainly not a big deal, but weird.  I though of a few possible fixes:  - automatically give the bottom pane the keyboard focus when working in the protocol column (which doesn't seem to need it (I like this one - fewest steps for the user)  - don't have the template pre-selected, so that clicking in the pane below the template selects it (easiest fix, requires one more user click)
Ha, the "click-for-focus" mosquito finally bit someone besides me. Sean, to live happily ever after, in Preferences, just enable mouseOverForKeyboardFocus. It solves all of the problems you mentioned above, reduces the overall effort needed to use the system because merely "pointing" at an object endows it with 100+ "mouse buttons" (left, middle, right, + the whole keyboard). It is more becoming of an object-oriented system, and if you can keep it on long enough to get used to it, I'll bet you'll never want to go back..
participants (6)
-
Adrian Lienhard -
Chris Muller -
Fernando olivero -
Lukas Renggli -
Sean P. DeNigris -
Stéphane Ducasse