[Cuis-dev] Quick print & quick implementors

Fri Dec 3 05:34:17 PST 2021

I really forgot about the morph embedding feature.

Your proposal to use text-attributes for print-it made me think.
Embedded morph do not upset syntax highlighting,
so we could add a preference that embeds the text that
would be printed in a simple morph and embed that.
It can be deleted with one keystroke, even if the initial
selection got lost. Optionally such a morph could keep

   - keep a history of print it results
   - posses a button to redo the evaluation
   - a button to replace the morph with the result text
   - a button to explore/inspect the result

etc. pp.

Maybe package with a subclass of Workspace,
that has all those features is the best solution.

Best Regards,

Gerald

On 12/3/21 2:07 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> My 2 cents. I use printIt a lot and I really hated what they did in pharo.
> If we’re going to change it in Cuis, could we make it a preference?
> 
> Thanks,
> Luciano
> 
> On Thu, 2 Dec 2021 at 3:07 AM Gerald Klix via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
> 
>>
>>
>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> 
> 