[Cuis-dev] Quick print & quick implementors

[Gerald Klix]

On 12/1/21 8:45 PM, Hernan Wilkinson via Cuis-dev wrote:
>>
>>
>>
>> Actually I would like to have both features available
>> in every CodeWindow, alas we are running out of portable hot keys.
>> (More on that topic below)
>>
> 
> yeah, me too. But as you said we are running out of shortcuts... we will do
> something, we have to think about it .-)
> 
> 
>> Both features should also be available as menu items.
>> Additionally having the "print to hover help" bound to
>> a key would be great, Ctrl-Shift-P comes to my mind.
>>
> 
> I use ctrl-shift-p in LiveTyping to show the types under cursor :-)
Thats a pitty, lets see if I find something different.
> 
> 
>> Actually -- Cuis then becoming more Pharo like -- I suggest
>> to bind the "print to hover help@ to Ctrl-P and
>> the old "print to insert" to Shift-Ctrl-P,
>> but I don't know whether this too drastic a change.
>> If the community is undecided in this point, we can do
>> what we always do in such a case: We should add a preference.
>>
> 
> hmm not sure about that change... do you think is it more usable with the
> hover help? I think we have to let time pass and see how everybody feels
> about this and if everybody see it as a better way to do it we can change
> the shortcuts
I can't remember one case, even in 1986/7 when I used Smalltalk/V,
that I did not delete the result of print-it.
OK maybe sometimes, I pressed Ctrl-x.
If you use it in the debugger, you always get nasty
questions about modified code.
IHMO: This change would make life much easier;
sometimes even the Pharo guys get something right :}
(Sorry could not resist)
> 
> 
>>
>> Now some words/rants about modifier-keys and mouse-buttons:
>> I have no idea why the VM does not map the Windows-key on
>> to `macOptionKey`, that would be immensely helpful.
>> The same goes for the Menu-key (I am aware that this might
>> give Mac-Users some ulcers).
>> Additionally I would like to see the non-standard-buttons
>> on my mice/trackballs reported somehow. Again this
>> is not present on a Mac, but they usual tablet lacks
>> all these features ...
>>
>> Enough complaints:
>> * Will the community (and Juan) support me, when
>> I try to add these to the X11-display driver?*
>>
> 
> Yeah! definitely!
> 
> Cheers!
> Hernan.
> 
> 
>> I don't know whether I get this working on Windows,
>> but I'll try.
>>
>>
>> HTH and Best Regards,
>>
>> Gerald
>>
>>
>>
>> On 12/1/21 3:50 PM, Hernan Wilkinson via Cuis-dev wrote:
>>> That's a good one! But we have to make it different because if we move it
>>> to CodeWindow the DebuggerWindow will have two handlers for that event.
>>> But I'll make it work also for the changes windows.
>>>
>>> Regarding the shift+click, I selected that one because all the others are
>>> already taken as you also discovered, but the double click looks like a
>>> good idea, thanks!
>>>
>>> On Wed, Dec 1, 2021 at 9:04 AM Gerald Klix <cuis.01 at klix.ch> wrote:
>>>
>>>> Hi Hernan,
>>>>
>>>> please find attached one solution for the shift-click conflict.
>>>> I suppose shift-double-click is probably a better one.
>>>>
>>>>
>>>> HTH,
>>>>
>>>> Gerald
>>>>
>>>>
>>>> On 12/1/21 11:01 AM, Gerald Klix via Cuis-dev wrote:
>>>>> +1
>>>>>
>>>>> Cool! If you move that feature up to CodeWindow, it's available
>>>>> even in change sorters.
>>>>>
>>>>> Please see attached change set.
>>>>>
>>>>>
>>>>> However shift-click already extends the current selection.
>>>>> I tried different modifiers, alas they are all taken.
>>>>> Morph>>doubleClick:localPosition: does not work either,
>>>>> probably, because the morph in question
>>>>> handles double-clicks by itself (it also implements
>>>>> triple-clicks).
>>>>>
>>>>> Perhaps we can check this and only invoke that functionality
>>>>> if the selection would not be changed by the shift click,
>>>>> or if the selection is empty ... Will try figure some
>>>>> smart way.
>>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Gerald
>>>>>
>>>>>
>>>>>
>>>>> On 11/30/21 11:23 PM, Hernan Wilkinson via Cuis-dev wrote:
>>>>>> Hi,
>>>>>>     I created two new features that I'm attaching to this email.
>>>>>> 1) If you do shift+click in the debugger over the code, you will get
>> the
>>>>>> same result as doing inspect on it but it will be shown as a hover
>> help.
>>>>>> Here is a link that shows how it works:
>>>>>> https://twitter.com/HernanWilkinson/status/1465079401641652225?s=20
>>>>>> 2) If you do shift+click in the browser, if the mouse is over a
>> message
>>>>>> send, it will show the implementors of that message, if it is over a
>>>>>> class,
>>>>>> it will open the browser over the class. Here also a link:
>>>>>> https://twitter.com/HernanWilkinson/status/1465079839916974085?s=20
>>>>>>
>>>>>> Doing this I realized that there is really no need to differentiate
>>>>>> sender
>>>>>> (cmd+n) from references to it (cmd+N), if the browser is smart enough
>> to
>>>>>> realize the cursor is on a selector it can show senders, if the cursor
>>>> is
>>>>>> over a class, it can show the references to it.
>>>>>> The same between implementors (cmd+m) and browse (cmd+b).
>>>>>> So I expanded the functionality of doing senders and implementors when
>>>>>> nothing is selected (something I did 2 year ago aprox) to check if the
>>>>>> cursor is over a selector or a class and act accordingly.
>>>>>>
>>>>>> Also in this .cs is a fix to PseudoClass that did now answer
>> superclass
>>>>>> (I'm sorry Juan to put everything in the same .cs :-) )
>>>>>>
>>>>>> I hope you like it!
>>>>>> Hernan.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>