bad UI bug introduced with recent list highlightiong changes.

> Hi Tobias,
>
>
> On Apr 3, 2015, at 4:20 AM, Tobias Pape <[hidden email]> wrote:
>
>> Hi Eliot
>>
>> On 03.04.2015, at 01:36, Eliot Miranda <[hidden email]> wrote:
>>
>>> On Thu, Apr 2, 2015 at 3:56 PM, Tobias Pape <[hidden email]> wrote:
>>>
>>> On 03.04.2015, at 00:43, Eliot Miranda <[hidden email]> wrote:
>>>
>>>> Hi All,
>>>>
>>>>   since the hover highlight changes, where the list element under the mouse that would be selected if one clicks is highlighted in light blue appears to have caused a bad bug.  If one does a right-button clock to bring up a menu the system can end up selecting the item under the mouse before putting up the menu.  This is *wrong*.  The mouse click to bring up a menu should /not/ change the selection.
>>>
>>> The rightclick must change the selection, at
>>> least _temporarily_ to highlight for what item the menu is constructed.
>>>
>>> The menu is constructed for *the selected item*, not for the item under the mouse click.   Try this.  Run the debugger on a large class.  In the instance variables list type some chaacter to select inst vars beginning with that name, then select one, then try and issue a right-click to explore the selected inst var.  Poof, the filtered inst vars disappear, to be replaced by all inst vars, and then explore applies to some completely unintended selection that isn't even in the list one thought one was selecting from.
>>
>> I thought about what you described there once again, and just to report my experience,
>> this scenario is the exact time I use the #menuButtonInToolPane preference. When I have
>> an out-of-sight element I want a menu for (or no selection at all), I find it really convenient
>> to have this little button above the scroll bar. Also, it is explicit: when I click on
>> this menu thing, I don't point at something else but the "I want a menu now" button.
>
> That makes sense and one could soon learn to use that effectively.  But if still means a mouse move before issuing the menu click, and I suspect I'll still find that tiring.
>
> Sorry for shouting when I raised this thread.  
>

>>
>> HTH
>> Best
>>   -Tobias
>>
>>> Please, please, please fix this quickly.  The system is /very/ difficult for me to use right now.
>>>
>>>
>>> Else, we need a kind-of “second selection”
>>>
>>> No we don't.  Issuing a red button/left button click changes selections.  Issuing *other* mouse button clicks *should not*.  Right?  It's simple.  Right?
>>>
>>> Best
>>>       -Tobias

> On Apr 2, 2015, at 20:51, tim Rowledge <[hidden email]> wrote:
>
> I notice that - at least on my iMac, in Mail - using a right-click in the list of messages opens a menu that treats the item under the pointer as the selected item. And after making any choice from the menu it appears to actually change the selection, whether the choice refers specifically to an item or just the list. Indeed, it changes the selection if you move away from the menu to make no choice.
> I think that’s rather annoying now that I’ve noticed it. It’s treating the right click as a select-then-menu but presenting it visually inconsistent with that action. Not smart.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> dilate - live long
>
>
>

> On Apr 3, 2015, at 12:00, tim Rowledge <[hidden email]> wrote:
>
>
>> On 03-04-2015, at 10:41 AM, Ken G. Brown <[hidden email]> wrote:
>>
>> I think what Mail is doing is honoring any previous selection and treating a cntl-click menu selection as a separate operation, then puts you back to the state you were in before you initiated the action.
>> You get to operate either on the single message under the pointer at the time you cntl-click if it isn’t the current selection, or else the current selection if the pointer is over any part of the current selection, which may be more than one message.
>>
>> To me this seems a bit better than losing the current selection when doing the cntl-click menu operation.
>
> I’d agree with that last part if it were what appears to actually happen. But on my iMac it just isn’t the sequence.
>
> A
> B
> C-selected
> D
>
> right-click over A and the outline box appears around A, the menu appears. Make any choice - even no-choice - and A becomes the selected item and C is deselected.
>
> One of the problem with discussing these things is that they often seem quite different in different contexts and what looks a great idea in one situation is a disaster in another. I one doesn’t use the case where it looks good you’re not going to be much in favour of the idea.
>
> Where I *can* see this working well is in cases where there is a list that does not produce a selection affecting some content view. Imagine a list of items where you are able to choose from a few menu options relating to each one ( err, maybe delete/save/pass-to-supervisor) - then, right-click to open a menu specifically referring to the item under the pointer seems like it might make sense.
>
> Further out, I can imagine that we could make the concept work within the normal tools after some fairly major rejigging of how they work. Right now the whole usage pattern in the lists used in Browsers etc is that the menu acts on the list itself or *the selection previously set*. That, by the way, results in some bugs in places where the code doesn’t bother to check for a selection - try fileout in a browser message list where there is no selection.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Oxymorons: Good grief
>
>
>

>
> On 03-04-2015, at 10:23 AM, Chris Muller <[hidden email]> wrote:
>> The "power of pointing" is a wonderful UI gesture.  It's so energy
>> efficient for the user.  A simple nudge of the mouse can spawn a lot
>> of output and, then, simply moving away (one more nudge) reclaims all
>> the screen space.  Sometimes I like to pop up even /interactive/
>> panels my Maui apps by merely pointing.
>>
>> What is remarkable to me is how underrated it is.  I guess Windows'
>> click-for-focus pretty much blew it out of the water..
>>
> Except that it is an unholy pain if your pointing device has any reason to wander on its own; like a stiff cable, a sloping surface, an accidental nudge from a moving hand, a cat, an earthquake, psychokinetic leakage etc. All of which have annoyed me at some time.

> On Tue, Apr 7, 2015 at 2:07 PM, tim Rowledge <[hidden email]> wrote:
>>
>> On 03-04-2015, at 10:23 AM, Chris Muller <[hidden email]> wrote:
>>> The "power of pointing" is a wonderful UI gesture.  It's so energy
>>> efficient for the user.  A simple nudge of the mouse can spawn a lot
>>> of output and, then, simply moving away (one more nudge) reclaims all
>>> the screen space.  Sometimes I like to pop up even /interactive/
>>> panels my Maui apps by merely pointing.
>>>
>>> What is remarkable to me is how underrated it is.  I guess Windows'
>>> click-for-focus pretty much blew it out of the water..
>>>
>> Except that it is an unholy pain if your pointing device has any reason to wander on its own; like a stiff cable, a sloping surface, an accidental nudge from a moving hand, a cat, an earthquake, psychokinetic leakage etc. All of which have annoyed me at some time.
>
> Those are rare events compared to switching focus.  A minimally
> competent input device setup such as a laptop with a trackpad would
> reduce it from rare to never.

>>>> The "power of pointing" is a wonderful UI gesture.  It's so energy
>>>> efficient for the user.  A simple nudge of the mouse can spawn a lot
>>>> of output and, then, simply moving away (one more nudge) reclaims all
>>>> the screen space.  Sometimes I like to pop up even /interactive/
>>>> panels my Maui apps by merely pointing.
>>>>
>>>> What is remarkable to me is how underrated it is.  I guess Windows'
>>>> click-for-focus pretty much blew it out of the water..
>>>>
>>> Except that it is an unholy pain if your pointing device has any reason to wander on its own; like a stiff cable, a sloping surface, an accidental nudge from a moving hand, a cat, an earthquake, psychokinetic leakage etc. All of which have annoyed me at some time.
>>
>> Those are rare events compared to switching focus.  A minimally
>> competent input device setup such as a laptop with a trackpad would
>> reduce it from rare to never.
>
> But I - like quite a lot of people - don’t use a laptop. Don’t even own one. Meeses are where it’s at, dude! Whatever next - a suggestion to use one of those dreadful Selker Trackpoint monstrosities?
>
> One of the big complexifiers of modern UI design is catering for the reality of so many different ways of interacting with a system. Telling people to use a trackpad just isn’t practical.