[Cuis-dev] Quick print & quick implementors

Tue Dec 7 04:34:53 PST 2021

Perhaps I find some time to give it a shot.
We'l see what happens.

On 12/6/21 1:43 PM, Luciano Notarfrancesco wrote:
> Yes, that sounds good. I would make it a package in order to keep the base
> image simple. Actually at some point I tried it, and I don’t remember why
> exactly I didn’t continue using it, I think it might be because the
> embedded TextMorph didn’t resize correctly when resizing the Workspace.
> 
> On Fri, 3 Dec 2021 at 8:34 PM Gerald Klix <Gerald.Klix at klix.ch> wrote:
> 
>> 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
>>>>
>>>
>>>
>>
> 