For some time now I've been occasionally irritated by a bug in the way lists seem to work. When it happens it really grates. It doesn't always seem to happen, which somehow made me sort of ignore it and adapt.
Today I actually took a look to see if I was imagining things and perhaps it was always how lists behaved - but no, it is a change since the 4.5 release. I first see the issue in a 4.6 15102 image but I haven't tried any more precise searching as yet. What happens is that after selecting an item in a list - the obvious easy test is in a Browser - I <menu> and the selection is jumped to where the pointer is as I <Menu>. What used to happen - what should happen - is that the selection *stays where I put it*. I selected it for a reason; that being that I wanted it selected. If I move around and hit <Menu> later, with the pointer having moved around a bit, I still want the same thing selected. It's especially annoying when you get a combination of a) having thre menu buttons in the correct order b) a mouse with a sensitive scroll-wheel-middle-button c) the list scrolling madly because your finger moves microscopically as you press the scroll-wheel-middle-button So before I dig into looking for this, does anyone remember anything about this being done deliberately? A preference being changed that might cause it? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: PNG: Pass Noxious Gas |
> On 2019-12-30, at 1:04 PM, tim Rowledge <[hidden email]> wrote: > > So before I dig into looking for this, does anyone remember anything about this being done deliberately? A preference being changed that might cause it? Of course, as soon as I hit send I notice the preference 'Menu request updates list/tree selection. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SEXI: Sign EXtend Integer |
> Of course, as soon as I hit send I notice the preference 'Menu request updates list/tree selection.
... which I would vote to be set to false by default. Stef |
Le lun. 30 déc. 2019 à 22:31, Stéphane Rollandin <[hidden email]> a écrit : > Of course, as soon as I hit send I notice the preference 'Menu request updates list/tree selection. This preference is matching the feel of M$ Windows UI... Some Windows afficionado might want it, in order to have consistent feel across apps. I don't see why we should impose M$ as the default. |
> On 2019-12-30, at 1:36 PM, Nicolas Cellier <[hidden email]> wrote: > > > > Le lun. 30 déc. 2019 à 22:31, Stéphane Rollandin <[hidden email]> a écrit : > > Of course, as soon as I hit send I notice the preference 'Menu request updates list/tree selection. > > ... which I would vote to be set to false by default. > > Stef > > This preference is matching the feel of M$ Windows UI... > Some Windows afficionado might want it, in order to have consistent feel across apps. > I don't see why we should impose M$ as the default. > Mac approach is a bit 'intersting' about it too. If I have something selected and then move the pointer over another item and <menu> it shows a sort-of selection box for that new item, leaves the original selected and seems to ignore (some of) the menu action I might choose. No idea who thought that was a logical combination. But still, I'm happier with the Squeak option disabled. Of course, now I have to save my modified preferences and share them to all the different images I am using... wonder how I could do that... let's see, maybe a filesaver dialog to save the file somewhere shared, and one to load from somewhere other than the image working directory? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Calling her stupid would be an insult to stupid people. |
But still, I'm happier with the Squeak option disabled. Of course, now I have to save my modified preferences and share them to all the different images It's already shared automatically, to "all the different images" in the same dev sandbox (directory), you shouldn't need to do _anything_. But since what you really meant is, "all of Tim's various directories," the correct answer is "add it to your build script." The wrong answer is, - "Open a Preferences window, - click "Save To Disk" button - navigate to first desired directory, DON'T get this wrong (yeah, right...) - click "OK" to accept the default name - Repeat from the third step, above, for EACH additional desired directory, and DON'T miss any directories" (yeah, right...) I am using... wonder how I could do that... Squeak's FileBrowser window a tool *designed* to do file management. A few drag and drops, to do all the above. I, myself, would still stick to the build script, but at least FileBrowser is 10X better at file management than the Preferences browser. "Responsibilities," you know.... let's see, maybe a filesaver dialog to save the file somewhere shared, and one to load from somewhere other than the image working directory? So you're *guaranteed* to have to go through that popup **unnecessarily** at LEAST once for each image, because you only need to select a file for the Save OR the Load, not both. So the theoretical PEAK efficiency of this UI function is 50%, which is horrible. Tim, please *demand* an IDE design and experience worthy of 2020 Squeak, not Windows 95. - Chris |
> On 2019-12-30, at 9:33 PM, Chris Muller <[hidden email]> wrote: > > But since what you really meant is, "all of Tim's various directories," Yes. Because I work in many places on many machines. Which is different that how you work. So I need different solutions. I don't think like you. So I need different solutions. > The wrong answer is, > > - "Open a Preferences window, > - click "Save To Disk" button > - navigate to first desired directory, DON'T get this wrong (yeah, right...) > - click "OK" to accept the default name > - Repeat from the third step, above, > for EACH additional desired directory, > and DON'T miss any directories" (yeah, right...) Or actually correctly set preferences after taking a look around for new ones etc click 'save to disk' click 'accept' unless I want to change the name > > I am using... wonder how I could do that... > > Squeak's FileBrowser window a tool *designed* to do file management. The FileSaverDialogue uses the same components to do the same job of moving around the file tree if you need to do that. Whilst in the bigger picture the entire preferences system needs rewriting, right now we don't have time. I've offered a small improvement to a tool you claim not to use. If people don't like it, it won't be in the release. I. Don't. Care. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Plan to be spontaneous tomorrow. |
In reply to this post by Nicolas Cellier
Hmm... the actual reason for ENABLING that preference by default is that it saves you a click on many occasions. Just yellow-click a selector, for example, and pick an option. No need for an additional red click. Even better: YELLOW mouse down, mouse move to the desired menu item, YELLOW mouse up and you are done with a single click. :-D Best, Marcel
|
> On 2020-01-06, at 2:55 AM, Marcel Taeumel <[hidden email]> wrote: > > Hmm... the actual reason for ENABLING that preference by default is that it saves you a click on many occasions. Just yellow-click a selector, for example, and pick an option. No need for an additional red click. > > Even better: YELLOW mouse down, mouse move to the desired menu item, YELLOW mouse up and you are done with a single click. :-D I see the potential advantages, really, I do. And with the latest 19315 updates and the newest VM the really, really, annoying jumping around of the list that was (almost certainly) caused by the scrollwheel event insanity has gone and thus this option is tolerable, sort of. The problem with it as an idea is that with some item selected in the list you have to go back precisely to that item when you want to use the menu, or you get to use the menu on a newly (and probably surprisingly) selected item. And of course you lose the prior selection as a side-effect. In a long list that can be very irritating! The way we use menus in the browser for example makes that extremely distracting - you might be looking at SHTextStylerST80>>#createTextAttributesForPixelHeight: and press <menu> in the method list expecting copy the reference for the method (to paste here...) and you find you actually got the reference for SHTextStylerST80>>#environment:. Or perhaps you wanted the 'senders of...' and get a strange looking list of options not at all related to #createTextAttributesForPixelHeight: So yes, it potentially saves you a <select> but costs you the extra time and concentration to <menu> in exactly the right place instead of just anywhere in the list. The way Mac OS seems to handle that is a bit convoluted but probably a bit less annoying in the end; you have a selection, move the pointer to some other item and press<menu> - the 'new' item is border-selected rather than solid-selected, and the menu item clicked on applies to that new selection BUT the old selection is returned to. It sounds really weird but it works... ok. ish. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Trancelators interpret messages from the dead |
Personally, I'm happy with the default preference. But I can understand your point, Tim, it's all a question about habits :) So I like having preferences for those things. > So yes, it potentially saves you a <select> but costs you the extra time and concentration to <menu> in exactly the right place instead of just anywhere in the list.
I like to press escape anywhere over the list to do this. Ideal on a laptop with touchpad only: You only need to move the cursor to the approximate position, most of the rest can be done using the keyboard ...
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Montag, 6. Januar 2020 23:48:15 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Annoying list morph selection/menu click bug > On 2020-01-06, at 2:55 AM, Marcel Taeumel <[hidden email]> wrote: > > Hmm... the actual reason for ENABLING that preference by default is that it saves you a click on many occasions. Just yellow-click a selector, for example, and pick an option. No need for an additional red click. > > Even better: YELLOW mouse down, mouse move to the desired menu item, YELLOW mouse up and you are done with a single click. :-D I see the potential advantages, really, I do. And with the latest 19315 updates and the newest VM the really, really, annoying jumping around of the list that was (almost certainly) caused by the scrollwheel event insanity has gone and thus this option is tolerable, sort of. The problem with it as an idea is that with some item selected in the list you have to go back precisely to that item when you want to use the menu, or you get to use the menu on a newly (and probably surprisingly) selected item. And of course you lose the prior selection as a side-effect. In a long list that can be very irritating! The way we use menus in the browser for example makes that extremely distracting - you might be looking at SHTextStylerST80>>#createTextAttributesForPixelHeight: and press <menu> in the method list expecting copy the reference for the method (to paste here...) and you find you actually got the reference for SHTextStylerST80>>#environment:. Or perhaps you wanted the 'senders of...' and get a strange looking list of options not at all related to #createTextAttributesForPixelHeight: So yes, it potentially saves you a <select> but costs you the extra time and concentration to <menu> in exactly the right place instead of just anywhere in the list. The way Mac OS seems to handle that is a bit convoluted but probably a bit less annoying in the end; you have a selection, move the pointer to some other item and press<menu> - the 'new' item is border-selected rather than solid-selected, and the menu item clicked on applies to that new selection BUT the old selection is returned to. It sounds really weird but it works... ok. ish. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Trancelators interpret messages from the dead
Carpe Squeak!
|
> On 2020-01-06, at 2:58 PM, Thiede, Christoph <[hidden email]> wrote: > > I like to press escape anywhere over the list to do this. Ideal on a laptop with touchpad only: You only need to move the cursor to the approximate position, most of the rest can be done using the keyboard ... Even there one has a problem - what about us left-handers? I have the mouse on my left and the Esc is at top-left of the keyboard - so hitting Esc actually involves either letting go of the mouse or using my *right* hand all the way across the keyboard. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim BASIC is to computer programming as QWERTY is to typing. |
Not sure whether it helps the left-handed, but there is a context menu hardware key on most PC keyboards between Alt Gr and the right Windows and Ctrl keys. Shouldn't Squeak handle this key like it handles Esc for the menus at the moment? tim Rowledge <[hidden email]> schrieb am Di., 7. Jan. 2020, 00:05:
|
+1 but I think that there is no such thing on a Mac keyboard Le mar. 7 janv. 2020 à 09:16, Jakob Reschke <[hidden email]> a écrit :
|
> On 2020-01-07, at 1:04 AM, Nicolas Cellier <[hidden email]> wrote: > > +1 but I think that there is no such thing on a Mac keyboard Exactly... nor on most linux keyboard layouts I imagine tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Airline Food |
Free forum by Nabble | Edit this page |