[Cuis-dev] Quick print & quick implementors

Luciano Notarfrancesco luchiano at gmail.com
Fri Dec 3 05:18:00 PST 2021


Ah cool :)
If you were talking about printing to a balloon morph when *not* in a
workspace, that could make sense to me, but I really like traditional
workspaces and I use printIt a lot in workspaces, not only for text but
also for embedding morphs. It only bothers me sometimes the syntax
highlighting, and that could be fixed with a not-code text attribute.

On Fri, 3 Dec 2021 at 8:12 PM Hernan Wilkinson <hernan.wilkinson at 10pines.com>
wrote:

> we are not changing it... at least not for now :-)
>
> On Fri, Dec 3, 2021 at 10:09 AM Luciano Notarfrancesco via Cuis-dev <
> cuis-dev at lists.cuis.st> 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
>>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>
> --
> <https://10pines.com/>Hernán WilkinsonSoftware Developer & Coach
>
> Alem 896, Floor 6, Buenos Aires, Argentina
>
> +54 11 6091 3125
>
> @HernanWilkinson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211203/c0147643/attachment.htm>


More information about the Cuis-dev mailing list