[squeak-dev] Preference "Always open tools attached to cursor" (was: Default preferences)

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Mon Feb 7 22:27:54 UTC 2022


Hi Marcel, hi all,

> Well, I play the piano with both hands.

Me too. Still, I would love an alwaysAttach option. :P

> Consequently, there are different groups of users.

Now we're talking! :-) There at least three persons by now (including me) who have reported that they would like such a feature. What problem do you expect from giving them a preference to realize this dream, which would come with an expected added CYCLO of 1 or 2 only? :-)

> Until now, Squeak's keyboard-only support is rather sketchy. We should work on that.

That will be a useful goal, too, but a) don't let the perfect be the enemy of the good, and b) as a mouse-attracted user, I would not like the system or its designers re-educate me and imposing new habits to me. :-)

Jaromir:

> In such case I'd expect if I start a tool from the keyboard and continue with the keyboard (press an arrow e.g.) the windows 'dis-attaches' from the mouse silently and stays in its current position

Hm, I thought about this, but I am not sure. It's also a nice gesture to do the following: Cmd + P (preference browser, attaches to cursor), type a search term "workspace", and finish your mouse gesture, where you can drag the attached window to a useful size that matches the individual contents of the now-filled window. Can you reproduce that? :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-12-27T08:41:14+01:00, mail at jaromir.net wrote:

> Hi Marcel, Christoph and all,
> 
> a few more notes about preferences:
> 
> (1) sortMessageCategoriesAlphabetically - my suggestion would be to place starred *extensions categories behind "normal" categories; alphabetical ordering places them all before 'accessing' etc. In case of Object for example the list starts with *Deprecated and you scroll over a lot of extension categories before you get down to "normal" categories.
> 
> (2) what is CMD-s supposed to do in the Transcript window? Currently it clears the window without a way back - undo (CMD-z) doesn't restore it. CMD-l (lowercase L) also clears the Transcript but the undo works... Help's Keyboard Shortcuts doesn't help: CMD-s is supposed to "save" (I understand diffent windows have different sets of shortcuts but Help's Keyboard Shortcuts is the only info I have - or any beginner). Why not e.g. save Transcript's window contents similarly as Workspace's contents on Accept/Save/CMD-s or make it a preference?
> 
> (3) about the "always attach to cursor" mode suggested by Christoph earlier - because currently there's no strong support of keyboard only interaction, why not make it a preference: attach on mouse events / attach always? I still find the current 'attach on mouse events' mode confusing; I don't explicitely think how I start a tool, whether using a key or the mouse, you don't even have a choce always... so my brain often expects the tool under the cursor and it shows up somewhere else :)
> 
> (4) regarding the relative position of the tool being attached and the cursor - an offset of 25% would be better than 20% because in case of a debugger notifier window the 20% offset places the cursor over the Proceed button ;)
> 
> Thanks,
> 
> 
> ~~~
> ^[^    Jaromir
> 
> Sent from Squeak Inbox Talk
> 
> On 2021-12-10T10:39:34+01:00, marcel.taeumel at hpi.de wrote:
> 
> > Hi Jaromir --
> > 
> > Agreed. I am looking a better place to implement that 20% offset. The centered pop-up did already confuse me at times, too.
> > 
> > Other opinions about this?
> > 
> > Best,
> > Marcel
> > Am 10.12.2021 10:30:32 schrieb mail at jaromir.net <mail at jaromir.net>:
> > Hi Marcel,
> > 
> > > Hi Jaromir --
> > >
> > > > I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient
> > >
> > > Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?
> > >
> > 
> > The main reason I find it more convenient (or just less distracting) is when I open a window by clicking on a button or from the context menu near the top of the screen (or the left side) the attached window is partly outside my screen. Lower right would be even worse in this regard :) And upper left is dangerously close to the close button. But as I said, it's a small inconvenience for me and maybe even just me :)
> > 
> > > (And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)
> > 
> > I won't dispute this :D I just used this place to test the offset ;)
> > 
> > Thanks,
> > ~~~
> > ^[^ Jaromir
> > 
> > Sent from Squeak Inbox Talk
> > 
> > On 2021-12-10T10:14:29+01:00, marcel.taeumel at hpi.de wrote:
> > 
> > > Hi Jaromir --
> > >
> > > > I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient
> > >
> > > Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?
> > >
> > > (And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)
> > >
> > > Best,
> > > Marcel
> > > Am 09.12.2021 20:25:31 schrieb mail at jaromir.net :
> > > Hi Christoph, all,
> > >
> > > A small suggestion - current implementation attaches the new window centered around the cursor - I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient; Here's the change:
> > >
> > > attachMorph: m
> > > "Position the center of the given morph under this hand, then grab it.
> > > This method is used to grab far away or newly created morphs."
> > > | delta |
> > > self releaseMouseFocus. "Break focus"
> > > self showTemporaryCursor: nil.
> > > delta := m bounds extent // 5.
> > > m position: (self position - delta).
> > > m formerPosition: m position.
> > > targetOffset := m position - self position.
> > > self addMorphBack: m.
> > >
> > >
> > > ~~~
> > > ^[^ Jaromir
> > >
> > > Sent from Squeak Inbox Talk
> > >
> > > On 2021-12-07T21:30:09+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> > >
> > > > Hi Jaromir,
> > > >
> > > >
> > > > > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> > > >
> > > > Sounds wrong to me, nice catch! We should look into this.
> > > >
> > > >
> > > > Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.
> > > >
> > > > We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?
> > > >
> > > > If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)
> > > >
> > > >
> > > > > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> > > >
> > > >
> > > > This would be very welcome! We should also unify the Uppercase/lowercase of all categories.
> > > >
> > > >
> > > > Best,
> > > >
> > > > Christoph
> > > >
> > > >
> > > > ________________________________
> > > > Von: Squeak-dev im Auftrag von mail at jaromir.net
> > > > Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr
> > > > An: squeak-dev at lists.squeakfoundation.org; Taeumel, Marcel
> > > > Betreff: Re: [squeak-dev] Default preferences
> > > >
> > > > Hi Marcel,
> > > >
> > > > >
> > > > > >No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > > >
> > > > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> > > >
> > > > Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:
> > > >
> > > > self halt. self halt. self halt
> > > >
> > > > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> > > >
> > > > Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.
> > > >
> > > > This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)
> > > >
> > > > I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)
> > > >
> > > > Apologies for such a long message.
> > > >
> > > > Thanks a lot,
> > > >
> > > > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> > > >
> > > > ~~~
> > > > ^[^ Jaromir
> > > >
> > > > Sent from Squeak Inbox Talk
> > > >
> > > > On 2021-12-07T12:21:45+01:00, marcel.taeumel at hpi.de wrote:
> > > >
> > > > > Hi Jaromir --
> > > > >
> > > > > >No ? when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > > >
> > > > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 07.12.2021 11:56:45 schrieb Jaromir Matas :
> > > > > Checked already ?
> > > > > Yes ? improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent
> > > > > No ? when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > > > Thanks!
> > > > >
> > > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > > Sent: Tuesday, December 7, 2021 11:52
> > > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > > Subject: Re: [squeak-dev] Default preferences
> > > > >
> > > > > Hi Jaromir --
> > > > >
> > > > > Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 07.12.2021 11:05:36 schrieb Jaromir Matas :
> > > > > I?ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.
> > > > >
> > > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > > Sent: Tuesday, December 7, 2021 10:59
> > > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > > Subject: Re: [squeak-dev] Default preferences
> > > > >
> > > > > Hi Jaromir --
> > > > >
> > > > > Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?
> > > > >
> > > > > > I think it happened with some dialogues as well but can?t remember now.
> > > > >
> > > > > Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 07.12.2021 10:48:58 schrieb Jaromir Matas :
> > > > > Hi Marcel,
> > > > > I tried both do-it from the menu and via CTRL-d and they both behave erratically.
> > > > >
> > > > > I?m not sure it?s only the Debugger; I think it happened with some dialogues as well but can?t remember now.
> > > > > Thanks,
> > > > > Jaromir
> > > > >
> > > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > > Sent: Tuesday, December 7, 2021 10:35
> > > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > > Subject: Re: [squeak-dev] Default preferences
> > > > >
> > > > > My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 07.12.2021 10:33:32 schrieb Marcel Taeumel :
> > > > > Hi Jaromir --
> > > > >
> > > > > > E.g. try do-it (a few times):
> > > > >
> > > > > Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 07.12.2021 10:01:48 schrieb mail at jaromir.net :
> > > > > Hi all --
> > > > > >
> > > > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > > > >
> > > > > > Best,
> > > > > > Marcel
> > > > > I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):
> > > > >
> > > > > self halt. self halt
> > > > >
> > > > > The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)
> > > > >
> > > > > Best,
> > > > >
> > > > > ~~~
> > > > > ^[^ Jaromir
> > > > >
> > > > > Sent from Squeak Inbox Talk
> > > > >
> > > > > On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:
> > > > >
> > > > > > Hi all --
> > > > > >
> > > > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > > > >
> > > > > > Best,
> > > > > > Marcel
> > > > > > Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> > > > > > >> 1. Windowing
> > > > > > >> Personally, the first thing I do in every new image is to enable these prefs:
> > > > > > >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> > > > > > >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
> > > > > >
> > > > > > Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
> > > > > >
> > > > > > > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
> > > > > >
> > > > > > But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
> > > > > >
> > > > > >
> > > > > > >> 4. Editing
> > > > > > >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> > > > > > >> - Enclose selection with brackets -> true
> > > > > >
> > > > > > Again, very not OK for me.
> > > > > >
> > > > > > tim
> > > > > > --
> > > > > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > > > > Hackers have kernel knowledge.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------- next part --------------
> > > > > > An HTML attachment was scrubbed...
> > > > > > URL:
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------- next part --------------
> > > > > An HTML attachment was scrubbed...
> > > > > URL:
> > > > >
> > > > >
> > > >
> > > > -------------- next part --------------
> > > > An HTML attachment was scrubbed...
> > > > URL:
> > > >
> > > >
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:
> > >
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211210/7b2eafe7/attachment.html>
> > 
> >
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220207/f176c815/attachment.html>


More information about the Squeak-dev mailing list