find class is broken...
Locked
 
|
Hi All, whenever I hit Command-f in the browser's System Category pane to invoke FInd Class, instead the Find In Method dialog comes up. This is driving me nuts because to get back to the class dialog I often lose focus and end up deselecting the class. (and while we're at it, how easy is it to implement Form>>copyToClipboard ? this was tedious to produce; here are my "focus" preferences, I also have multi-window browsers turned on)  _,,,^..^,,,_ best, Eliot |
|
|
Hi Eliot, if you see the Find Method dialog, I think you do not have focused the system category pane. Did you make a click in it before (or hover it, provided that #mouseOverToKeyboardFocus is enabled)? I'm using the Find Class dialog everyday and it always works fine. > how easy is it to implement Form>>copyToClipboard You could open an Inspector on the Window and say `self lookFocused exportAsPNG` or something like this. For clipboard support, we would need to implement this on VM side first. This was already one point of my "possible VM improvements" list ... :-) If you really want to, here is a hack that already works today: morph :=Sent from the Squeak - Dev mailing list archive at Nabble.com.
Carpe Squeak!
|
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot, if you see the Find Method dialog, I think you do not have focused the system category pane. Did you make a click in it before (or hover it, provided that #mouseOverToKeyboardFocus is enabled)? I'm using the Find Class dialog everyday and it always works fine.
You could open an Inspector on the Window and say `self lookFocused exportAsPNG` or something like this. For clipboard support, we would need to implement this on VM side first. This was already one point of my "possible VM improvements" list ... :-) If you really want to, here is a hack that already works today:
morph :=
If Nabble wasn't so stubborn, you could watch the result here:
Best, Sent from the Squeak - Dev mailing list archive at Nabble.com.
Carpe Squeak!
|
|
|
In reply to this post by Christoph Thiede
On Sat, Sep 19, 2020 at 6:59 AM Christoph Thiede <[hidden email]> wrote:
I am hovering over the system category window of course. (Selecting isn't an option; it changes the selection). There is definitely a bug. This is new behaviour. I have the same settings I've had for several years and hovering in the wsyste, categories window and hitting command F always brought up the FInd Class dialog. Now it doesn't. _,,,^..^,,,_ best, Eliot |
|
|
Can you reproduce this in a fresh trunk image? Which preferences do you have changed? I cannot reproduce this; the only related experience I am aware of is when you use a hierarchy browser instead of a normal one. I got a few times irritated when hovering the left pane as usual and pressing <cmd>f,
ignoring that a hierarchy browser has no system category pane ... But that's probably not what you are describing. :-)
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 19. September 2020 21:20:28 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] find class is broken... On Sat, Sep 19, 2020 at 6:59 AM Christoph Thiede <[hidden email]> wrote:
I am hovering over the system category window of course. (Selecting isn't an option; it changes the selection). There is definitely a bug. This is new behaviour. I have the same settings I've had for several
years and hovering in the wsyste, categories window and hitting command F always brought up the FInd Class dialog. Now it doesn't.
_,,,^..^,,,_
best, Eliot
Carpe Squeak!
|
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot, I'm familiar with Squeak's focus settings..
Since you're looking to Find Class (which navigates to a new class selection), is it a big deal that the class is deselected? By "in" the System Category pane, do you mean the mouse pointer? Cmd+f is going to invoke on whatever pane has keyboard focus. As Christoph mentioned, Mouse over for keyboard focus will make it follow the mouse, which I would highly recommend. Functional pointing increases input leverage by an order of magnitude, the most powerful way to use Squeak, while also partially unwinding the dreadful coupling between widget focus, application-function, window z-ordering! Squeak's is the only IDE (with the right settings) capable of delineating these functions with independent, unambiguous gestures. Regards, Chris
|
|
|
In reply to this post by Christoph Thiede
> On 2020-09-19, at 12:40 PM, Thiede, Christoph <[hidden email]> wrote: > > Can you reproduce this in a fresh trunk image? Which preferences do you have changed? I can see the problem in a 5.3 image with no updates. There is some weird interaction between where you last selected anything and what cmd-f offers. I'd have to guess at some relationship to the focus follows mouse stuff - except the preferences don't show me any pref that seems to have anything to do with 'focus follows mouse', which I'd swear used to be there. Select a class and then a method; move the cursor back to the category list and cmd-f - you'll get the dialogue for the method list. Select in the method text pane, move the cursor to the category list and cmd-f will get you a text find dialogue (with a truly terrible pair of title & query strings). We seem to be making a rather convoluted set of UI choices these days. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Rules for Optimization: 1. Don't; 2. (for experts only) Don't Yet |
|
|
On Sat, Sep 19, 2020 at 5:18 PM tim Rowledge <[hidden email]> wrote:
"Focus Follows Mouse" is the original name for the setting, "Windows' Contents Are Always Active". Marcel did quite a bit of work which included renaming that. Select a class and then a method; move the cursor back to the category list and cmd-f - you'll get the dialogue for the method list. Select in the method text pane, move the cursor to the category list and cmd-f will get you a text find dialogue (with a truly terrible pair of title & query strings). The above is the correct behavior when Mouse over for keyboard focus is disabled. The last-clicked widget got keyboard focus and keyboard input. I made a video several years ago explaining all the related settings in detail. Insane input leverage is available, if you're willing to crank up the settings. For example, imagine the power of having EVERY PIXEL on your desktop being ready for ANY INPUT, regardless of window z-ordering, simply by moving pointer there and pressing a mouse or keyboard button. I believe Click for focus is such a naturally painful (mal)design for users, that it was instrumental in the death of PC's for personal computing. It's still around because people often prefer familiarity, even if it hurts. - Chris |
|
|
UI preferences are so personal it makes my head spin. We have almost had global nuclear wars over arguments about text editor choices, let alone actually interesting UI aspects.
> On 2020-09-19, at 4:47 PM, Chris Muller <[hidden email]> wrote: > For example, imagine the power of having EVERY PIXEL on your desktop being ready for ANY INPUT, regardless of window z-ordering, simply by moving pointer there and pressing a mouse or keyboard button. > Here you see, we differ. It's likely partly due to growing up using RISC OS and the original ST-80 UI (similar but not the same, which makes for 'interesting' habit/reflexes) where basically the keyboard focus was set by clicking in a text field and mouse focus what where ever the cursor sat. RISC OS permits windows to be active (for mouse or keyboard) at any point in the Z stack but you do still have to click in that text field. Very-old ST-80 MVC was mouse focus within the active window and IIRC keyboard focus in the text view under the mouse. I *think* I remember work at PPS to actually formalise some idea of a text focus for ObjectWorks 4.0 - but that's so long ago who knows if I'm right. The thing that would drive me nuts - and I have experience of trying to use a workstation set up that way in the past - is the keyboard focus sliding around as the mouse drifts across because of the cable being stiff or pulled by gravity etc. Yes, ok, a bluetooth mouse wouldn't usually do that but half the time they don't do *anything* right. Similarly I really, really, dislike the 'menu button selects a list item' thing that we currently have (and that Apple do, too) because I want the damn thing I selected to be selected until I actually select something else. Grrrrr. Damn; this is all reminding me how much I miss arguing UI with Jef Raskin. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim You never really learn to swear until you learn to drive in Silicon Valley |
|
|
On Sun, Sep 20, 2020 at 2:53 AM tim Rowledge <[hidden email]> wrote: UI preferences are so personal it makes my head spin. We have almost had global nuclear wars over arguments about text editor choices, let alone actually interesting UI aspects. |
|
|
Thats perfect!
Dave On Sun, Sep 20, 2020 at 09:37:17AM +0200, karl ramberg wrote: > Relevant xkce > https://xkcd.com/1172/ > > Best, > Karl > > On Sun, Sep 20, 2020 at 2:53 AM tim Rowledge <[hidden email]> wrote: > > > UI preferences are so personal it makes my head spin. We have almost had > > global nuclear wars over arguments about text editor choices, let alone > > actually interesting UI aspects. > > > > > On 2020-09-19, at 4:47 PM, Chris Muller <[hidden email]> wrote: > > > For example, imagine the power of having EVERY PIXEL on your desktop > > being ready for ANY INPUT, regardless of window z-ordering, simply by > > moving pointer there and pressing a mouse or keyboard button. > > > > > > > Here you see, we differ. It's likely partly due to growing up using RISC > > OS and the original ST-80 UI (similar but not the same, which makes for > > 'interesting' habit/reflexes) where basically the keyboard focus was set by > > clicking in a text field and mouse focus what where ever the cursor sat. > > RISC OS permits windows to be active (for mouse or keyboard) at any point > > in the Z stack but you do still have to click in that text field. Very-old > > ST-80 MVC was mouse focus within the active window and IIRC keyboard focus > > in the text view under the mouse. > > > > I *think* I remember work at PPS to actually formalise some idea of a text > > focus for ObjectWorks 4.0 - but that's so long ago who knows if I'm right. > > The thing that would drive me nuts - and I have experience of trying to > > use a workstation set up that way in the past - is the keyboard focus > > sliding around as the mouse drifts across because of the cable being stiff > > or pulled by gravity etc. Yes, ok, a bluetooth mouse wouldn't usually do > > that but half the time they don't do *anything* right. > > > > Similarly I really, really, dislike the 'menu button selects a list item' > > thing that we currently have (and that Apple do, too) because I want the > > damn thing I selected to be selected until I actually select something > > else. Grrrrr. Damn; this is all reminding me how much I miss arguing UI > > with Jef Raskin. > > > > > > tim > > -- > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > > You never really learn to swear until you learn to drive in Silicon Valley > > > > > > > > > |
|
|
In reply to this post by timrowledge
> For example, imagine the power of having EVERY PIXEL on your desktop being ready for ANY INPUT, regardless of window z-ordering, simply by moving pointer there and pressing a mouse or keyboard button. I grew up using MS Windows, the beast that made "click for focus" the defacto disaster it is today. Not everyone is willing to change how they work, but a few years ago I got a tendonitis that really made me notice that I was doing, literally, hundreds upon hundreds, of extra clicks every day for no other purpose than reassigning keyboard focus, which, as you know, have to even be "strategic clicks" (window title bars, borders, etc.) to avoid suffering unwanted selection change, otherwise having to click yet again just to "get back" to what I as looking at. Not only the pain, but I realized what a total time sink it was. The only way to escape was I had to be willing to change, which actually turned out a lot easier than I thought... |
|
|
On Sun, Sep 20, 2020 at 5:14 PM Chris Muller <[hidden email]> wrote:
Hover to select is one of the greatest causes of user confusion that I encounter. Most windows users are used to clicking and moving the cursor out of the way so they can see. Now imagine a text box. As a user you click on it so that you can type into it. You move your mouse away to type into the box BUT NOTHING HAPPENS. Why because your moving the mouse away from the text field took focus away from the text field. Or you click and start typing but your mouse pointer is in the way so you move it and now nothing you type goes into the field. We worked around this issue by locking some of the important fields when a user selects it but not all of them so it's not consistent. We also have the issue that if your mouse happens to be hovering above a button things work for a minute but then stop working because the button is capturing keystrokes. The user only moved their mouse. They didn't mean to hover over a button or they clicked a button and got the result they expected but had no reason to move their mouse cursor off the button afterwards. While I understand the unnecessary click argument and the harm that clicking does to your wrist, there is still a lot to be said for consistency, user understanding, and user experience. Just my 2c. Ron Teitelbaum |
|
|
Plus, moving away from host feel is disruptive... Unless we deliver a SqueakNOS. Le lun. 21 sept. 2020 à 15:12, Ron Teitelbaum <[hidden email]> a écrit :
|
|
|
In reply to this post by Ron Teitelbaum
I believe you're describing defacto habits ingrained into everyone from years of using Microsoft's original UI design than a qualitative critique of this particular design aspect. Yes, familiarity can matter (see below), but the concept of "Point to what you want to interact with," is such a natural way of thinking and working for a human user. Having keyboard focus decoupled and way off somewhere else than where the users' attention has since moved, often leads users to a similar confusion that you described, but just from the other direction -- the user wondering why nothing is happening when typing into a field -- but this time because the list in which they last clicked just to check something real-quick still has the keyboard focus. This is basically what happened to Eliot..
Coupling it to the mouse pointer helps remove all confusion about where keyboard focus is, and is a natural concept that can be assimilated in about a day. Dump Windows for Linux, and the behavior can be extended into the host system, too. Now, maybe for a single-use Form with a few fields used by external users for something simple, designing it click-for-focus may be worth aligning to Microsoft's defacto. But for all-day developer work involving multiple, multi-paned windows, allocating power to pointing makes the system feel "light and responsive" instead of heavy and cumbersome. For me, anyway... :) Best, Chris On Mon, Sep 21, 2020 at 8:12 AM Ron Teitelbaum <[hidden email]> wrote: > > > On Sun, Sep 20, 2020 at 5:14 PM Chris Muller <[hidden email]> wrote: >>> >>> > For example, imagine the power of having EVERY PIXEL on your desktop being ready for ANY INPUT, regardless of window z-ordering, simply by moving pointer there and pressing a mouse or keyboard button. >>> > >>> >>> Here you see, we differ. It's likely partly due to growing up using RISC OS and the original ST-80 UI ... >> >> >> I grew up using MS Windows, the beast that made "click for focus" the defacto disaster it is today. Not everyone is willing to change how they work, but a few years ago I got a tendonitis that really made me notice that I was doing, literally, hundreds upon hundreds, of extra clicks every day for no other purpose than reassigning keyboard focus, which, as you know, have to even be "strategic clicks" (window title bars, borders, etc.) to avoid suffering unwanted selection change, otherwise having to click yet again just to "get back" to what I as looking at. Not only the pain, but I realized what a total time sink it was. The only way to escape was I had to be willing to change, which actually turned out a lot easier than I thought... >> >> > Hover to select is one of the greatest causes of user confusion that I encounter. Most windows users are used to clicking and moving the cursor out of the way so they can see. > > Now imagine a text box. As a user you click on it so that you can type into it. You move your mouse away to type into the box BUT NOTHING HAPPENS. Why because your moving the mouse away from the text field took focus away from the text field. > > Or you click and start typing but your mouse pointer is in the way so you move it and now nothing you type goes into the field. We worked around this issue by locking some of the important fields when a user selects it but not all of them so it's not consistent. > > We also have the issue that if your mouse happens to be hovering above a button things work for a minute but then stop working because the button is capturing keystrokes. The user only moved their mouse. They didn't mean to hover over a button or they clicked a button and got the result they expected but had no reason to move their mouse cursor off the button afterwards. > > While I understand the unnecessary click argument and the harm that clicking does to your wrist, there is still a lot to be said for consistency, user understanding, and user experience. > > Just my 2c. > > Ron Teitelbaum |
|
|
On Tue, Sep 22, 2020 at 1:20 AM Chris Muller <[hidden email]> wrote:
Then explain how "mouse over to focus" can work on a multi touch interface? Every time you touch something the focus moves to where you touch. Multi touch is the most used interface in the world, and it is click to focus. Best, Karl
|
|
|
> On 22.09.2020, at 07:11, karl ramberg <[hidden email]> wrote: > > > > On Tue, Sep 22, 2020 at 1:20 AM Chris Muller <[hidden email]> wrote: > I believe you're describing defacto habits ingrained into everyone from years of using Microsoft's original UI design than a qualitative critique of this particular design aspect. Yes, familiarity can matter (see below), but the concept of "Point to what you want to interact with," is such a natural way of thinking and working for a human user. > > Then explain how "mouse over to focus" can work on a multi touch interface? > Every time you touch something the focus moves to where you touch. > Multi touch is the most used interface in the world, and it is click to focus. I don't know, but my phone distinguishes lightly touched, touched, and long touched and has dedicated effects for each of these (namely hover, click, and every now and then, context menu). -tobias > > Best, > Karl > > > > Having keyboard focus decoupled and way off somewhere else than where the users' attention has since moved, often leads users to a similar confusion that you described, but just from the other direction -- the user wondering why nothing is happening when typing into a field -- but this time because the list in which they last clicked just to check something real-quick still has the keyboard focus. This is basically what happened to Eliot.. > > Coupling it to the mouse pointer helps remove all confusion about where keyboard focus is, and is a natural concept that can be assimilated in about a day. Dump Windows for Linux, and the behavior can be extended into the host system, too. > > Now, maybe for a single-use Form with a few fields used by external users for something simple, designing it click-for-focus may be worth aligning to Microsoft's defacto. But for all-day developer work involving multiple, multi-paned windows, allocating power to pointing makes the system feel "light and responsive" instead of heavy and cumbersome. For me, anyway... :) > > Best, > Chris > > > > On Mon, Sep 21, 2020 at 8:12 AM Ron Teitelbaum <[hidden email]> wrote: > > > > > > On Sun, Sep 20, 2020 at 5:14 PM Chris Muller <[hidden email]> wrote: > >>> > >>> > For example, imagine the power of having EVERY PIXEL on your desktop being ready for ANY INPUT, regardless of window z-ordering, simply by moving pointer there and pressing a mouse or keyboard button. > >>> > > >>> > >>> Here you see, we differ. It's likely partly due to growing up using RISC OS and the original ST-80 UI ... > >> > >> > >> I grew up using MS Windows, the beast that made "click for focus" the defacto disaster it is today. Not everyone is willing to change how they work, but a few years ago I got a tendonitis that really made me notice that I was doing, literally, hundreds upon hundreds, of extra clicks every day for no other purpose than reassigning keyboard focus, which, as you know, have to even be "strategic clicks" (window title bars, borders, etc.) to avoid suffering unwanted selection change, otherwise having to click yet again just to "get back" to what I as looking at. Not only the pain, but I realized what a total time sink it was. The only way to escape was I had to be willing to change, which actually turned out a lot easier than I thought... > >> > >> > > Hover to select is one of the greatest causes of user confusion that I encounter. Most windows users are used to clicking and moving the cursor out of the way so they can see. > > > > Now imagine a text box. As a user you click on it so that you can type into it. You move your mouse away to type into the box BUT NOTHING HAPPENS. Why because your moving the mouse away from the text field took focus away from the text field. > > > > Or you click and start typing but your mouse pointer is in the way so you move it and now nothing you type goes into the field. We worked around this issue by locking some of the important fields when a user selects it but not all of them so it's not consistent. > > > > We also have the issue that if your mouse happens to be hovering above a button things work for a minute but then stop working because the button is capturing keystrokes. The user only moved their mouse. They didn't mean to hover over a button or they clicked a button and got the result they expected but had no reason to move their mouse cursor off the button afterwards. > > > > While I understand the unnecessary click argument and the harm that clicking does to your wrist, there is still a lot to be said for consistency, user understanding, and user experience. > > > > Just my 2c. > > > > Ron Teitelbaum > > |
|
|
In reply to this post by Karl Ramberg
> Then explain how "mouse over to focus" can work on a multi touch interface? > Every time you touch something the focus moves to where you touch.
> Multi touch is the most used interface in the world, and it is click to focus.
I believe the difference is that on touch screens, you have kind of random access to every point of the screen, whereas when using a mouse, every click requires you to move the cursor until you reach the desired
point, which introduces an additional level of indirection. Probably you cannot find an ultimative design concept for different input methods - just remember how successful Microsoft was with its Universal Windows Platform ...
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von karl ramberg <[hidden email]>
Gesendet: Dienstag, 22. September 2020 07:11:37 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] find class is broken... On Tue, Sep 22, 2020 at 1:20 AM Chris Muller <[hidden email]> wrote:
Then explain how "mouse over to focus" can work on a multi touch interface?
Every time you touch something the focus moves to where you touch.
Multi touch is the most used interface in the world, and it is click to focus.
Best,
Karl
Carpe Squeak!
|
|
|
Also consider that focus is decoupled from mouse position so as to enable focus shift thru keyboard. What i most hate like Tim is that operate menu (pop up) is coupled with select (it's a select and operate). Operate is already requiring some motion to pick the right menu item, so i find the coupling really tiring, focus on position accurately twice, once for where we press the button, and once where we release the button... We already focused once when selecting, so doing it twice is just too many. Le mar. 22 sept. 2020 à 13:12, Thiede, Christoph <[hidden email]> a écrit :
|
|
|
In reply to this post by Karl Ramberg
By reversing the touch vs. tap+touch for accessing the meta-layer. But this would not be enough to make touch interfaces useful for authoring use-cases, while complicating its primary use-case as a consumption kiosk.
Not for complex IDE's. Only simple modal things like checking in to your flight or adding cherry syrup to your coke. :) Nicolas wrote: > Also consider that focus is decoupled from mouse position so as to enable focus shift thru keyboard. Good point. If the focus shift is done on #mouseEnter, it could still be shifted away, and then the next time the user "pointed" at something, would snap focus to whatever they pointed at. The mouse remains the main tool for setting focus, and the keyboard a sub input device. You could accidentally bump the mouse as long as it didn't knock it into a totally different widget. - Chris |
| Free forum by Nabble | Edit this page |