[Cuis-dev] Quick print & quick implementors

Mon Dec 6 04:43:41 PST 2021

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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211206/5cb92c8f/attachment.htm>