What are the useful operations of implementors/senders that you use

> 2011/8/9 Stéphane Ducasse <[hidden email]>:
>> 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.

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

>
> On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote:
>
>> 2011/8/9 Stéphane Ducasse <[hidden email]>:
>>> 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 :)
>

>>  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 <[hidden email]>:
>>
>> On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote:
>>
>>> 2011/8/9 Stéphane Ducasse <[hidden email]>:
>>>> 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
>