Smalltalk › Pharo › Pharo Smalltalk Developers

Playground key binding...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

stepharo

Playground key binding...

Hi

a really handy keybinding was

CMD-b on class to browse a class
such key binding was smart enough to see that when this is not a
class binding but a symbol
it was performing an implementor

Why should I know when the system can do it for me?

Same CMD-m is doing first a implementor if the receiver was a
symbol and then
a class browse when this is a binding. This one is still working.

I would like to get the behavior **I** implemented in Pharo 30 back.
Why we cannot keep the good things we do?

Stef

Guillermo Polito

Re: Playground key binding...

I agree,

I think that "browse class or trait” and “implementors” should both be => “go to implementation”
And “senders” and “class references” should both be => “look for references”

The only difference is that today one works for selectors and the other for classes. But we can be polymorphic in the UI also, can’t we? :)

Afterwards, we could discuss if it is worth it to have two shortcuts for the same thing :).

> On 19 ene 2016, at 9:44 a.m., stepharo <[hidden email]> wrote:
>
> Hi
>
> a really handy keybinding was
>
> CMD-b on class to browse a class
> such key binding was smart enough to see that when this is not a class binding but a symbol
> it was performing an implementor
>
> Why should I know when the system can do it for me?
>
> Same CMD-m is doing first a implementor if the receiver was a symbol and then
> a class browse when this is a binding. This one is still working.
>
> I would like to get the behavior **I** implemented in Pharo 30 back.
> Why we cannot keep the good things we do?
>
> Stef
>

Tudor Girba-2

Re: Playground key binding...

In reply to this post by stepharo

Hi,

The current logic is not specific to the playground, it is the same in all other tools. This probably got lost before we introduced GT because I do not find the logic in Pharo 3.0 either.

It would be interesting to salvage this logic. Could someone point me to it?

Cheers,
Doru

> On Jan 19, 2016, at 9:44 AM, stepharo <[hidden email]> wrote:
>
> Hi
>
> a really handy keybinding was
>
> CMD-b on class to browse a class
> such key binding was smart enough to see that when this is not a class binding but a symbol
> it was performing an implementor
>
> Why should I know when the system can do it for me?
>
> Same CMD-m is doing first a implementor if the receiver was a symbol and then
> a class browse when this is a binding. This one is still working.
>
> I would like to get the behavior **I** implemented in Pharo 30 back.
> Why we cannot keep the good things we do?
>
> Stef
>

--
www.tudorgirba.com
www.feenk.com

"When people care, great things can happen."

Sven Van Caekenberghe-2

Re: Playground key binding...

In reply to this post by Guillermo Polito

> On 19 Jan 2016, at 09:58, Guillermo Polito <[hidden email]> wrote:
>
> I think that "browse class or trait” and “implementors” should both be => “go to implementation”
> And “senders” and “class references” should both be => “look for references”

Excellent analysis and simplification of actions and terminology !

And please also add/maintain CMD-Click for the first and maybe CMD-Shit-Click for the second, everywhere.

stepharo

Re: Playground key binding...

In reply to this post by Guillermo Polito

Le 19/1/16 09:58, Guillermo Polito a écrit :
> I agree,
>
> I think that "browse class or trait” and “implementors” should both be => “go to implementation”
> And “senders” and “class references” should both be => “look for references”
>
> The only difference is that today one works for selectors and the other for classes. But we can be polymorphic in the UI also, can’t we? :)

Yes this is all my point.

>
> Afterwards, we could discuss if it is worth it to have two shortcuts for the same thing :).
>
>> On 19 ene 2016, at 9:44 a.m., stepharo <[hidden email]> wrote:
>>
>> Hi
>>
>> a really handy keybinding was
>>
>> CMD-b on class to browse a class
>> such key binding was smart enough to see that when this is not a class binding but a symbol
>> it was performing an implementor
>>
>> Why should I know when the system can do it for me?
>>
>> Same CMD-m is doing first a implementor if the receiver was a symbol and then
>> a class browse when this is a binding. This one is still working.
>>
>> I would like to get the behavior **I** implemented in Pharo 30 back.
>> Why we cannot keep the good things we do?
>>
>> Stef
>>
>
>

stepharo

Re: Playground key binding...

In reply to this post by Tudor Girba-2

May be it was in Pharo 20.
I changed the logic associated with the keybinding.
I will see if I can dive into it but I would like to finish the Pharo
tour chapter first

Le 19/1/16 11:31, Tudor Girba a écrit :

> Hi,
>
> The current logic is not specific to the playground, it is the same in all other tools. This probably got lost before we introduced GT because I do not find the logic in Pharo 3.0 either.
>
> It would be interesting to salvage this logic. Could someone point me to it?
>
> Cheers,
> Doru
>
>
>
>> On Jan 19, 2016, at 9:44 AM, stepharo <[hidden email]> wrote:
>>
>> Hi
>>
>> a really handy keybinding was
>>
>> CMD-b on class to browse a class
>> such key binding was smart enough to see that when this is not a class binding but a symbol
>> it was performing an implementor
>>
>> Why should I know when the system can do it for me?
>>
>> Same CMD-m is doing first a implementor if the receiver was a symbol and then
>> a class browse when this is a binding. This one is still working.
>>
>> I would like to get the behavior **I** implemented in Pharo 30 back.
>> Why we cannot keep the good things we do?
>>
>> Stef
>>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "When people care, great things can happen."
>
>
>
>
>
>