Bottomhover refactor idea

[Keith94]

What would you like to discuss?

Since the project was based around osc.lua standards I wanted to ask something.

The way bottomhover and bottomhover_zone works is similar to the way mpv handles the deadzonesize option in stock osc.lua.

So do you think we could squash the bottomhover options into just one? Remove the toggle completely and have deadzone values similar to previous Modernx forks:

https://github.com/dexeonify/mpv-config/blob/63b6156a536b24189d8793496e4959f41822a0b0/scripts/modernx.lua#L1300-L1307

[Samillion]

Good point. I've never actually tried the deadzonesize option.

get_align(1 - (2 * user_opts.deadzonesize)

function get_align(align, frame, obj, margin)
    return (frame / 2) + (((frame / 2) - margin - (obj / 2)) * align)
end

    -- deadzone above OSC
    local sh_area_y0, sh_area_y1
    sh_area_y0 = get_align(-1 + (2*user_opts.deadzonesize),
                           posY - osc_geo.h, 0, 0)
    sh_area_y1 = osc_param.playresy - user_opts.barmargin

Hmm. How would it be different though? I still don't quite understand the math behind it. In essence it makes everything between mouse position and osc top a deadzone in a negative value?

[Keith94]

Honestly not sure about the math portion, but according to docs

0 means the OSC will always popup with mouse movement in the window, and 1 means the OSC will only show up when the mouse hovers.

I guess it depends on what implementation you prefer since the end result is kinda similar to what we have. Deadzonesize=0.5 seems similar to bottomhover_zone=500 or so.

[Samillion]

Interesting. From a user's standpoint, which method do you think would be preferable?

I'll setup a no-config with osc.lua when I'm back home tomorrow to try it out, I honestly don't know which one is more user friendly, would love your take on it. If it's not a bother.

[Keith94]

I couldn't sleep so I was comparing the two behaviors just now. The big difference that stands out to me is that deadzonesize also affects the window title and controls.

For example, deadzonesize=0.75, moving your mouse from center of the screen to the top bar triggers it more quickly. For deadzonesize=1 you need to hover the top bar directly. Same with bottom controls.

By design the bottomhover_zone doesn't care about showing the top bar in respect to your cursor position except when hovering it directly.

My initial impression is that deadzonesize is more user-friendly since it adjusts both the top and bottom zones simultaneously. It also follows what mpv uses which some users might already be familiar with.

[Samillion]

That sounds really good. It would probably even make area based show easier. (ie: when you hover to top, only window title bar shows, not entire OSC).

I'll most likely apply this eventually. My delay would be for fixing up the old code, it's the next step right now, you'll start seeing PRs about a lot of logic simplifying and redundancy removals.

The real reason though, I need to understand how this works first. I glanced at it, it also accounts for video margins, which isn't applied yet on ModernZ.

Though if someone created a PR to apply all of that, I'd very much welcome it. Otherwise, it'll take some time.

The idea is 100% solid though. I just don't want to copy/paste blindly, because if something breaks, it'll apply unnecessary stress into trying to figure it out.

As I mentioned to you before, I hate math. 😆

[Keith94]

I completely understand you. Consider this a very low priority due to the complexity of the feature lol.

It would probably even make area based show easier.

This would be useful to have. I assume the code would involve a bit different math going that route instead. Could define set area boundaries or have fine adjustment for where the areas start and end.

Not sure yet what a good default behavior would be, but everyone here is free to discuss of course.

[Samillion]

I discovered that bottomhover is so much better, but it went unnoticed due to either me not seeing it or just cluttered code. I blame society and the sun was in my eyes. 😝

So, the original author for this feature deserves much credit, because they didn't just factor in bottomhover, they also addressed top area hover zone.

The issue is, only the bottomhover side of things was announced and documented.

I was only able to see it because I had to dissect that line to fix #216, and then, mind blown.

ModernZ/modernz.lua

Lines 2818 to 2820 in d3e2fc0

	local top_hover = window_controls_enabled() and (user_opts.window_title or user_opts.window_controls)
	if mouseY > osc_param.playresy - (user_opts.bottomhover_zone or 145)
	or (not (state.border and state.title_bar) or state.fullscreen) and (mouseY < 40 and top_hover) then

I added a top_hover check, because mouseY < 40 addresses top area hover.

So it can be easily configured with mouseY < user_opts.tophover_zone

This makes bottomhover_zone and tophover_zone much better, right? Because you can then customize it to the precise pixel height you want.

Which would then need to change the feature name from bottomhover to precise_hover, area_hover or something.

[Keith94]

That's a really good find.

This makes bottomhover_zone and tophover_zone much better, right?

So would be two separate options is what you're saying? Or one option to control both top and bottom?

[Samillion]

It can be either.

The difference being, top bar would have the same hover zone height as controls bar. Considering top bar height is 50 (not counting alpha shade), wouldn't it be optimal to have its own show hover zone?

[Keith94]

I agree that it would be optimal to be configured separately considering the height differences.

Sorry but I'm a little confused. Does that also mean that bottom and top zones would be triggered independently like you mentioned earlier? Or either zone would still trigger the full OSC on hover?