Smalltalk › Squeak › Squeak - Dev

bad UI bug introduced with recent list highlightiong changes.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

31 messages Options

Eliot Miranda-2

bad UI bug introduced with recent list highlightiong changes.

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.

best,

Eliot

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

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.

Else, we need a kind-of “second selection”

Best
-Tobias

timrowledge

Re: bad UI bug introduced with recent list highlightiong changes.

On 02-04-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.

err, run that one by me again? That sounds awfully, terribly, wrong.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Manual Writer's Creed: Garbage in, gospel out.

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

On 03.04.2015, at 00:58, tim Rowledge <[hidden email]> wrote:

> On 02-04-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.
>
> err, run that one by me again? That sounds awfully, terribly, wrong.
>

So when you rightclick on something you need some feedback on what you rightclick
to assure you you clicked on the right thing, right?

In osx this is done by a kind-of secondary selection (a border instead of a
full color highlight) that leaves the primary selection untouched.

Since this is afaik only available in one of our widgets that support
selection AND context menus, I think changing the selection is fine.

Best
-Tobias

Eliot Miranda-2

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Tobias Pape

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.

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

best,

Eliot

timrowledge

Re: bad UI bug introduced with recent list highlightiong changes.

Gonna have to agree with Eliot on this. This is a big departure from long established UI rules. We have menus that apply to the selected item and the list they’re in. Changing to item-under-the-pointer even when not selected is going to be very confusing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A computer's attention span is only as long as its extension cord.

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Eliot Miranda-2

On 03.04.2015, at 01:36, Eliot Miranda <[hidden email]> wrote:

I disagree. I really want the menu for the thing *I am pointing to*.

See attached OSX Finder picture. gemstone is selected but I right-clicked on X11, so I
want a menu for X11, not for gemstone.

> 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.

The thing in this scenario is that the filtering should not reset before the rightclick
is recognized for the intended element, right?

>
> 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

Bildschirmfoto 2015-04-03 um 01.41.23.PNG (56K) Download Attachment

Nicolas Cellier

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by timrowledge

2015-04-03 1:42 GMT+02:00 tim Rowledge <[hidden email]>:

Gonna have to agree with Eliot on this. This is a big departure from long established UI rules. We have menus that apply to the selected item and the list they’re in. Changing to item-under-the-pointer even when not selected is going to be very confusing.

tim

Hello Tobias,

I agree with Eliot and Tim.

Windows UI did force selection under the pop-up and I never liked it.

For example, when we want to fileout all the methods, it's mandatory to select none. This is now impossible.

I note that the change list which is capable of multiple selections does not have this auto-select annoyance.

For windows-addict make it a preference, but be sure old guys like us will never highlight it ;)

Nicolas

--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A computer's attention span is only as long as its extension cord.

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Tobias Pape

On 03.04.2015, at 01:55, Tobias Pape <[hidden email]> wrote:

>
> 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.
>
> I disagree. I really want the menu for the thing *I am pointing to*.
>
> See attached OSX Finder picture. gemstone is selected but I right-clicked on X11, so I
> want a menu for X11, not for gemstone.
>

Another example. There's a text and I have a selection on a word. When I rightclick on
another word, I want a context menu for the latter, not the former (that is how it
works on OSX and Windows, AFAIK)

[snip]

Best
-Tobias

Eliot Miranda-2

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Tobias Pape

On Thu, Apr 2, 2015 at 4:55 PM, Tobias Pape <[hidden email]> wrote:

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.

I disagree. I really want the menu for the thing *I am pointing to*.

*NO*. I don't want to have to reposition my bloody mouse pointer every time I want to select from a menu. If *you* want this, make it a preference that is *off* by default.

See attached OSX Finder picture. gemstone is selected but I right-clicked on X11, so I
want a menu for X11, not for gemstone.

> 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.

The thing in this scenario is that the filtering should not reset before the rightclick
is recognized for the intended element, right?

Whether filtering stays on or not seems independent of whether I've issued a menu clock. But it's bloody confusing when the list changes under the menu when I issue the menu click.

>
> 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

best,

Eliot

Eliot Miranda-2

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Eliot Miranda-2

You know, we're supposed to be trying to get Squeak 4.5 and Squeak 5 released and instead there's a sudden slew of major UI changes. This really doesn't help. How long are these UI changes going to continue? Surely the right time for this kind of innovation is early in the release cycle.

On Thu, Apr 2, 2015 at 3:43 PM, 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.

--
best,
Eliot

best,

Eliot

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

On 03.04.2015, at 02:05, Eliot Miranda <[hidden email]> wrote:

> You know, we're supposed to be trying to get Squeak 4.5 and Squeak 5 released and instead there's a sudden slew of major UI changes. This really doesn't help. How long are these UI changes going to continue? Surely the right time for this kind of innovation is early in the release cycle.

Sorry, I didn't do a thing here; I just said that it matches my experience
and is current UI lingua franca…
Heck, I just took on some tests nobody cares about…

Best
-Tobias

Chris Muller-3

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Eliot Miranda-2

On Thu, Apr 2, 2015 at 7:05 PM, Eliot Miranda <[hidden email]> wrote:
> You know, we're supposed to be trying to get Squeak 4.5 and Squeak 5
> released and instead there's a sudden slew of major UI changes. This really
> doesn't help. How long are these UI changes going to continue? Surely the
> right time for this kind of innovation is early in the release cycle.

Yes, earlier is always better for everything. Don't worry, we can
resolve this with a preference if we need to. However we have a wave
of exquisite-talent energy flowing in at the moment. Can we keep
going just bit longer? With the exception of my own few commit
bungles, the quality of the contributions has, IMO, been very good.
This wave coincided with the 4/30 release target date announcement.
These are image-level things that will set 4.6 apart from 4.5, so we
can think of it as "release work".

At this point in the release cycle trying our best with quality is
paramount. When this wave dies down, we'll know we're ready. Then
we'll all hammer on a release-candidate, figure out our look and
preferences, strip and clean (including changes file this time) and
then All-In-One it.

timrowledge

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Tobias Pape

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

marcel.taeumel (old)

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Eliot Miranda-2

I guess that I changed that because it started to annoy me recently as I highlighted the hovered item in lists and played around with providing item-specific balloon texts. No additional click needed there.

Providing a context menu for the current selection without honoring the mouse position poses kind of a gap and -- imho -- makes an interface harder to use.

But for the sake of backwards compatibility, I will make it a preference. We should also think about letting the model decide and giving it the clicked item instead of just requesting a menu for some click.

Best,
Marcel

marcel.taeumel (old)

Re: bad UI bug introduced with recent list highlightiong changes.

Preference added: http://forum.world.st/The-Trunk-Morphic-mt-813-mcz-td4817132.html

It's disabled by default. ;-)

Best,
Marcel

Nicolas Cellier

Re: bad UI bug introduced with recent list highlightiong changes.

2015-04-03 9:06 GMT+02:00 Marcel Taeumel <[hidden email]>:

Preference added:
http://forum.world.st/The-Trunk-Morphic-mt-813-mcz-td4817132.html

It's disabled by default. ;-)

Best,
Marcel

You rock :)

--
View this message in context: http://forum.world.st/bad-UI-bug-introduced-with-recent-list-highlightiong-changes-tp4817074p4817135.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.

Tobias Pape

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Eliot Miranda-2

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.

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

signature.asc (1K) Download Attachment

Eliot Miranda-2

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by marcel.taeumel (old)

Hi Marcel,

thank you!! It is very Turing to reposition the mouse to get it over the right selection when one has learned the other stile over the last 8 years. It bring a preference is the only way I can see of making the system usable for existing users. I guess my insistence on the preference to default to the old behaviour is too strong. I'd be happy if I could set the preference. So ignore that part. I was annoyed and frustrated when I wrote that ;-)

Eliot (phone)

On Apr 2, 2015, at 11:53 PM, Marcel Taeumel <[hidden email]> wrote:

> I guess that I changed that because it started to annoy me recently as I
> highlighted the hovered item in lists and played around with providing
> item-specific balloon texts. No additional click needed there.
>
> Providing a context menu for the current selection without honoring the
> mouse position poses kind of a gap and -- imho -- makes an interface harder
> to use.
>
> But for the sake of backwards compatibility, I will make it a preference. We
> should also think about letting the model decide and giving it the clicked
> item instead of just requesting a menu for some click.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/bad-UI-bug-introduced-with-recent-list-highlightiong-changes-tp4817074p4817131.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Eliot Miranda-2

Re: bad UI bug introduced with recent list highlightiong changes.

In reply to this post by Tobias Pape

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
>
>
>
>