[Pharo-project] What are the useful operations of implementors/senders that you use
Hi I would like that we do an analysis of what should stay in implementors Here are the menus in 1.2 and 1.4 Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool. Stef
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I would like that we do an analysis of what should stay in implementors
Here are the menus in 1.2 and 1.4
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'. That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n - if the message is multiple keyword, then this won't work... I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation. To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge
Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool.
Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no?
Stef
On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote:
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I would like that we do an analysis of what should stay in implementors
Here are the menus in 1.2 and 1.4
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method.
I did not pay attention to that because I always type the code but I see now.
In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'.
That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n
this is what I do :)
- if the message is multiple keyword, then this won't work...
We should fix that for any place in the system foo: #yyy to: does not find foo:to: :(
I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation.
Ok we will fix that.
To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge
Yes.
Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool.
Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no?
Yes but do we need spawn subprotocol? and friends. All instances... So let us focus on the most 40% most important features and add them to the browsers. So there should be a reasonable amount of used functionality. So let us know what you use most of the time or less and this will be good. Stef
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote:
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I would like that we do an analysis of what should stay in implementors
Here are the menus in 1.2 and 1.4
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method.
I did not pay attention to that because I always type the code but I see now.
In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'.
That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n
this is what I do :)
Then also remove implementors/senders from the method list menu...
- if the message is multiple keyword, then this won't work...
We should fix that for any place in the system foo: #yyy to: does not find foo:to: :(
This requires a minimal parsing of surrounding text, maybe shout like style is enough.
 I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation.
Ok we will fix that.
To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge
Yes.
Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool.
Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no?
Yes but do we need spawn subprotocol? and friends. All instances... So let us focus on the most 40% most important features and add them to the browsers. So there should be a reasonable amount of used functionality.
So let us know what you use most of the time or less and this will be good.
Stef
This reflects my very personnal use for the browsing category : 5) vital alt+b / alt+N (otherwise I have to type self/print it/select it/alt+b in Text) 4) often used: alt+m alt+n (including sub messages) alt+v (my own right to make mistake) inst var refs/defs (though I also browse it from text with alt+shift+n for refs) 3) casually used: alt+h - local implementors/senders - alt+i inheritance - class var ref/defs 2) rarely used; none 1) never used: all the rest For actions: 4) remove method (x) 3) toggle break on entry (it's not recommended for some kernel UI messages) 2) fileOut (but in some rare cases this is valuable, it must be able to filOut the whole list if there is no selection) - change category 1) all the rest But there is a bias, everything accessible thru more... will be less often used by construction. Of course, my flow is a bit different when using OB/RB. I'm not biggest OB fan, but I wonder like Marcus if maintaining two browsers is sustainable. 1) You have complaints from Lukas because of OB regressions at each upgrade 2) You get complaints for removed features from end users. A recipe for maximizing the complaints ;) While you could integrate OB in dev, core developers would fix OB on the fly and commit to local Pharo/PharoInbox. Then Lukas would select/correct/merge available fixes and officialize them on a new ConfigurationOfOB. Nicolas
I will wait a bit more and collect a list of essential action to the bug entry I created. Stef On Aug 9, 2011, at 7:28 PM, Nicolas Cellier wrote:
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote:
2011/8/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
I would like that we do an analysis of what should stay in implementors
Here are the menus in 1.2 and 1.4
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method.
I did not pay attention to that because I always type the code but I see now.
In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'.
That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n
this is what I do :)
Then also remove implementors/senders from the method list menu...
- if the message is multiple keyword, then this won't work...
We should fix that for any place in the system foo: #yyy to: does not find foo:to: :(
This requires a minimal parsing of surrounding text, maybe shout like style is enough.
I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation.
Ok we will fix that.
To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge
Yes.
Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool.
Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no?
Yes but do we need spawn subprotocol? and friends. All instances... So let us focus on the most 40% most important features and add them to the browsers. So there should be a reasonable amount of used functionality.
So let us know what you use most of the time or less and this will be good.
Stef
This reflects my very personnal use for the browsing category : 5) vital alt+b / alt+N (otherwise I have to type self/print it/select it/alt+b in Text) 4) often used: alt+m alt+n (including sub messages) alt+v (my own right to make mistake) inst var refs/defs (though I also browse it from text with alt+shift+n for refs) 3) casually used: alt+h - local implementors/senders - alt+i inheritance - class var ref/defs 2) rarely used; none 1) never used: all the rest
For actions: 4) remove method (x) 3) toggle break on entry (it's not recommended for some kernel UI messages) 2) fileOut (but in some rare cases this is valuable, it must be able to filOut the whole list if there is no selection) - change category 1) all the rest
But there is a bias, everything accessible thru more... will be less often used by construction.
Of course, my flow is a bit different when using OB/RB.
I'm not biggest OB fan, but I wonder like Marcus if maintaining two browsers is sustainable. 1) You have complaints from Lukas because of OB regressions at each upgrade 2) You get complaints for removed features from end users. A recipe for maximizing the complaints ;) While you could integrate OB in dev, core developers would fix OB on the fly and commit to local Pharo/PharoInbox. Then Lukas would select/correct/merge available fixes and officialize them on a new ConfigurationOfOB.
Nicolas
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'.
I also prefer the choice of actually sent messages to be picked from a list. A discontinuity with the standard browsers that is becoming irksome for me... For multi keywords it is possible to use the keyboard (both keyboard AND mouse should be available, not just one or the other) if you select a range that includes all keyword components... I also miss "Browse hierarchy" from implementors, for what it's worth. Not against improvements to the tools but feedback on changes should be expected! Regards, Gary
On Aug 9, 2011, at 6:50 PM, Gary Chambers wrote:
Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'.
I also prefer the choice of actually sent messages to be picked from a list.
ok I neer use that because I go faster with the keyboard. But we will added it.
A discontinuity with the standard browsers that is becoming irksome for me...
For multi keywords it is possible to use the keyboard (both keyboard AND mouse should be available, not just one or the other) if you select a range that includes all keyword components...
Yes that I really want to fix because I hate when it does not work.
I also miss "Browse hierarchy" from implementors, for what it's worth.
You will have it all the time with nautilus :)
Not against improvements to the tools but feedback on changes should be expected!
Yes!
Regards, Gary
participants (3)
-
Gary Chambers -
Nicolas Cellier -
Stéphane Ducasse