Add HighlightOnMouseEnter feature.

[BDisp]

I hope you like this.

[tig]

Ha! Neat.

When I saw your suggestion I started refactoring my system to be more flexible.

Before i saw this I finished it and pushed it.

Check it out! I didn't implement Hover, which is what I call what you show here.

[BDisp]

So you don't want any of this, right?

[tig]

Based on what I just pushed, I think there's a cleaner way to implement this hover effect. Why don't you look at my latest push and see if you can implement hover?

[BDisp]

If you already have an idea of how to do that, I think it's better to be you do that. Remember that the RadioGroup has a different implementation. If at end you need my help please say so.

[tig]

If you already have an idea of how to do that, I think it's better to be you do that. Remember that the RadioGroup has a different implementation. If at end you need my help please say so.

Take a look now.

Note both Button & Border...

[BDisp]

I prefer using the focus and hot focus on hover. But if you use a new color at least implement a better hot focus color for the hot string.

[BDisp]

The original border style isn't restore after the click even another border view is selected. In the video I changed the border to double and when the mouse is hover it show the border as double but when the mouse is outside the border is showing as single instead of double.

WindowsTerminal_o0NPXdQxAk.mp4

[tig]

I prefer using the focus and hot focus on hover. But if you use a new color at least implement a better hot focus color for the hot string.

This was just a temporary hack to have a very distinct look for testing.

[tig]

The original border style isn't restore after the click even another border view is selected. In the video I changed the border to double and when the mouse is hover it show the border as double but when the mouse is outside the border is showing as single instead of double.

WindowsTerminal_o0NPXdQxAk.mp4

Good catch.

I'm not convinced changing border style is the right effect anyway.

I designed the extensibility in the api to enable a view to do any number of things and implemented Border to change style just to demonstrate the API had the right flexibility.

With TrueColor we can do really subtle but cool things with the colors. I'd like to have a Color.MakeBright() api
for example.

[BDisp]

With TrueColor we can do really subtle but cool things with the colors. I'd like to have a Color.MakeBright() api
for example.

Maybe only changing the border color is more appropriated than change the border style.

[BDisp]

This was just a temporary hack to have a very distinct look for testing.

Can I change my PR to present a suggestion changing for this?

[tig]

With TrueColor we can do really subtle but cool things with the colors. I'd like to have a Color.MakeBright() api

for example.

Maybe only changing the border color is more appropriated than change the border style.

That's what I meant.

[BDisp]

I also fix a bug calling wrong method OnMouseEnter on the NewMouseLeaveEvent method.

[BDisp]

I may suggest for the HighlightStyle.Pressed using the same Focus/HotFocus foreground color but with a DarkGray background color. This will simulating a real pressed button. What do you think?

[BDisp]

I'm seeing a behavior where handling both HighlightStyle.Hover and HighlightStyle.Pressed the latest effect isn't be showing. That because the Button is getting focus on button pressed when it should be on a button clicked. So I suggest adding two new items on the HighlightStyle enum, like HighlightStyle.Released and HighlightStyle.ReleasedOutside. What do you think?

[tig]

I may suggest for the HighlightStyle.Pressed using the same Focus/HotFocus foreground color but with a DarkGray background color. This will simulating a real pressed button. What do you think?

Not a bad idea, but I'd rather investigate using "Color.MakeBright()" to avoid having to add more ColorScheme complexity. Just using DarkGrey means that I'd Focus already uses it, there'll be no effect.

[BDisp]

Not a bad idea, but I'd rather investigate using "Color.MakeBright()" to avoid having to add more ColorScheme complexity. Just using DarkGrey means that I'd Focus already uses it, there'll be no effect.

Right, but for some situations we can use the released effect instead of pressed. See my comment #31 (comment)

[BDisp]

Ok but I understand you have to call SetFocus without invoke Accept. Well I think definitively that only a "Color.MakeBright()" or whatever. It's complicated :-)

[BDisp]

@tig I did changes that do the HighlightStyle.Pressed show some effects.

[BDisp]

The problem was the ColorScheme being always changed on all HighlightStyle settings in the SetHighlight method without returning true to exit the HandlePressed method. So, the latest setting was always prevailed.

[BDisp]

See it working.

WindowsTerminal_RAKjp3TVxU.mp4

[tig]

This breaks the continuous press mode somehow.

Don't worry about it though. I want to merge gui-cs#3770 without "Hover" support because it's a nice-to-have that we can implement in a separate PR.

So I'll be taking the changes you made here that are good fixes and not taking the hover stuff.

[BDisp]

I don't like the behavior where pressing the mouse on the TextField and releasing the mouse on the Button, invoking the Accept event. I had added in this PR a workaround for this but you didn't considered.

WindowsTerminal_zBgpiakp49.mp4

With your decision of not taking the hover stuff the RadioGroup is broken. I like the effect. It's the same when you navigate by the keyboard which highlight the item where is cursor is.

If you think you still want this PR I will fix the error, otherwise is frustrating spend time for nothing.

[BDisp]

Ok I now see it was already merge. Can I submit a PR for this in the v2_develop? If yes I have to enable the Hover enum. What to do about that?

[BDisp]

Closing this because isn't more valid for this branch.

[tig]

Ok I now see it was already merge. Can I submit a PR for this in the v2_develop? If yes I have to enable the Hover enum. What to do about that?

Yeah, new Issue against v2_develop.

Note, I think the behavior you are noting is due to

• Mouse API makes it way too hard to track button pressed gui-cs/Terminal.Gui#3312

I do not want to fix this in a piecemeal way. I want to see if we can fix it at the core API level. I'm ok with leaving it partially broken until we come up with a great design that fundamentally fixes the mouse API such that a view can easily distinguish between when the mouse button was first pushed and when it's just remained pushed.