console.lua: update the select layout

[guidocella]

console.lua: improve the hovered item calculation with background-box

Follow up to c438732 which improved the calculation with the default outline-and-shadow. We can make the calculation accurate for background-box too without making semitransparent rectangle backgrounds overlap by adding margin between items.

We could calculate the height of each item to make them perfectly adjacent by rendering each one with compute_bounds, but that takes 15ms per render, so 20 lines would take 300ms, which is too slow.

Instead add a fixed 0.1 * opts.font_size to each item's height. This ensures the backgrounds don't overlap with tall CJK text or track circles and --osd-shadow-offset=0. Add this to outline-and-shadow too since it looks better with some margin between the items. Then add the rectangle offset to the height depending on the border style.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[na-na-hi]

Instead add a fixed 0.1 * opts.font_size to each item's height. This ensures the backgrounds don't overlap with tall CJK text or track circles and --osd-shadow-offset=0.

How do you ensure that the "tall characters" are at most 10% larger than normal characters, but not more?

[guidocella]

You don't, it's a heuristic. It works with the fonts I tried and can be increased if it doesn't work with some others.

[na-na-hi]

You don't, it's a heuristic. It works with the fonts I tried and can be increased if it doesn't work with some others.

"Works for me" isn't a good enough justification when it changes the appearance significantly:

It now looks very different from console, especially when the gaps and item background width don't even have the same size. No other menu-like UI do anything like this.

[guidocella]

Well it was kasper's request to do it like this. I don't use background-box personally.

[kasper93]

LGTM

[kasper93]

You don't, it's a heuristic. It works with the fonts I tried and can be increased if it doesn't work with some others.

"Works for me" isn't a good enough justification when it changes the appearance significantly: It now looks very different from console, especially when the gaps and item background width don't even have the same size. No other menu-like UI do anything like this.

It's is improvement over current status, feel free to come up with better ideas for this problem. @guidocella said that compute_bounds is too slow to work with, so we are quite limited in what we can do here. Otherwise we could match the spacing or draw background separately, but we would need a bounding box for this, which is apparently no-go.

[na-na-hi]

It's is improvement over current status

It has appearance regression and not 100% improvement.

Otherwise we could match the spacing or draw background separately, but we would need a bounding box for this, which is apparently no-go.

Here is a bounding box that doesn't require compute_bounds:

You already know the total height of the box because you know the number of lines. The width can simply be the whole window width.

[kasper93]

You already know the total height of the box because you know the number of lines. The width can simply be the whole window width.

It has appearance regression and not 100% improvement.

See, I find separate buttons with separate background just as nice.

We could compute bounds of longest string in selections, but it still means that we need to draw custom background and disable the style of default background, but I guess this can be done, wit tags for the events.

[guidocella]

This looks fine to me too by making them look like separate buttons and not drawing more background width than necessary for each item. We will also add --osd-selected-back-color to give a different background color only to the selected item, this will be simpler if we don't have to draw ourselves. Also if we don't override libass' border style and libass/libass#688 is ever closed it will have rounded corners for free.

Computing the longest width is too slow with something like 10k properties. And if you compute the width only of current matches, the background width would change as you scroll.

[na-na-hi]

It has appearance regression and not 100% improvement.

Which one has larger appearance change, especially compared to regular console?

See, I find separate buttons with separate background just as nice.
This looks fine to me too by making them look like separate buttons and not drawing more background width than necessary for each item.

It's not nice when they have different width. As I already said no other menus look like this.

We will also add --osd-selected-back-color to give a different background color only to the selected item, this will be simpler if we don't have to draw ourselves. Also if we don't override libass' border style and libass/libass#688 is ever closed it will have rounded corners for free.

I don't see how is this complicated. You draw the selected item background over the whole background. And if you really think rounded corners are important enough here (and not just bringing it up for the sake of argument), you can draw them already, there is no need to wait for libass.

Computing the longest width is too slow with something like 10k properties. And if you compute the width only of current matches, the background width would change as you scroll.

There is no problem if you make the background fixed width, like I originally mentioned.

I will end my remark by pointing out that the uosc playlist selection menu uses the drawing methods I mentioned and looks much better than this PR. It additionally calculates the longest item's width, but we don't have to do that and instead keep it a constant width to avoid width calculation.

[kasper93]

It additionally calculates the longest item's width, but we don't have to do that and instead keep it a constant width to avoid width calculation.

I would prefer to not cover whole screen in background-box, just because we are too lazy to calculate the width of it. It will look obnoxious for short menu items.

[guidocella]

Updated as request. It disables the item shadow with background-box and draws a rectangle as wide as the longest item (the longest calculation is not perfect with unicode and proportional fonts but works in practice). The rectangle coloring is actually handled by background-box automatically. Also the background width no longer changes as you type or scroll.

I don't see how is this complicated. You draw the selected item background over the whole background.

I meant that we now have to draw 3 rectangles to not make the semitransparent selected rectangle overlap with the default one, but that's fine.

[kasper93]

Doesn't work for me

[guidocella]

It was just missing the closing ASS tag with non-nil font after I added the font. Also made it calculate the width even with outline-and-shadow so I can use it to position a scrollbar later.

[kasper93]

Works.

@na-na-hi: is this solution acceptable to you?

[na-na-hi]

Background looks OK, but the current width calculation is a little buggy and doesn't cover the whole width when it needs to. You can easily test with keepaspect-window=no.

Also because the default font is proportional, it causes text overflow especially with Unicode.

I would prefer to not cover whole screen in background-box, just because we are too lazy to calculate the width of it. It will look obnoxious for short menu items.

We can copy what uosc does if we don't want to be lazy: keep a length cache for items (including regular and bold styles) so that the bounds don't need to be recomputed while selecting/scrolling.

Alternatively we can always cover like 2/3 of the screen width and clip long lines.

[guidocella]

I tried to use the same alpha before but thought it decreases readability and works for the OSC because it's mostly buttons, set it to the same anyway but also made it configurable.

Added menu_outline_size and menu_outline_color script-opts (as just border_size already exists, or should they be called menu_border?), but size is 0 by default, because I think it looks better without borders and it already has a shadow if you set --osd-shadow-offset (https://x.com/steveschoger/status/897849211110273024), and default bottombar OSC doesn't have a border like box.

[na-na-hi]

FWIW, I think it might also be valid to say "all the floating widgets currently have rounded corners", where "all" refers to the only "floating" widget in the OSC, which is the box layout.

I have already mentioned 2 other cases where the corner isn't rounded like OSD bar.
I also wouldn't take the box layout as the pinnacle of UI design. It has rounded corner for background but not for progress bar.

I didn't try it with sharp corners, and I only saw an image with rounded corners, and liked it.

I think if someone only sees the sharp corner version of this PR they would also think it's nice too. Both sharp corners and rounded corners look better than the current state in isolation. The problem is that the image is not representative of user experience as a whole, and how it plays with other UI elements need to be considered.

We can disable rounding if this is the main blocker for this PR.

Since layout=box has rounded corners, I don't mind defaulting to rounding for layout=box only and sharp otherwise for now.

What are you trying to say? Should we do democratization and vote on every change and stall small PR for years before they are merged?

No, there is no need for democratization. But we should at least get the opinion of those who have ample experience related to the PR. In this case users with strong UI/UX design background and feedback experience. Consider the initial implementation of this PR and at the current state: it's a dramatic improvement in both appearance and usability, which wouldn't have happened if I wasn't here """stalling""" this PR by suggesting alternatives and taking uosc as a hint.

Pushing changes is the only way to get feedback, even from mentioned sfan5, people don't go and look at those PRs until they are forgotten forever and nothing ever changes.

See above. There are ways to collect efficient feedbacks before merging, which is especially suitable for mpv development process since it's mostly clear which contributors are the ones to ask. macOS, Wayland, etc. parts of mpv already follow this kind of process, there is no reason why this can't be done for UI/UX.

And sure, some people don't like the change, but you don't have to update and add new entries to restore-osc.conf.

What do you mean? Somehow adding new entries to a pure informational document like restore-osc.conf is bad, but YOLO changing the default UX is good? Please correct me if I misunderstood.

Great, that means the system is working and we are developing software in incremental steps, refining and adjusting based on user feedback.

Doesn't mean feedback isn't needed or useful before merging.

[kasper93]

I also wouldn't take the box layout as the pinnacle of UI design.

I think if someone only sees the sharp corner version of this PR they would also think it's nice too.

You are trying to get validation too hard.

Both sharp corners and rounded corners look better than the current state in isolation.

No one said it looks better. People said it looks nice.

The problem is that the image is not representative of user experience as a whole, and how it plays with other UI elements need to be considered.

Could you elaborate what does this mean?

which wouldn't have happened if I wasn't here """stalling""" this PR by suggesting alternatives and taking uosc as a hint.

Sure buddy, all credit goes to you.

Doesn't mean feedback isn't needed or useful before merging.

And who said this it is? I pinged you directly multiple times in this very PR. Don't try to act like I'm the bad guy here. I try to ping people on IRC for controversial changes, but I don't want to be nagging and force people to do things they don't want. Look this PR is open 3 weeks, mpv doesn't have this much of PR rotation to not expect interested people to comment on it.

but YOLO changing the default UX is good

And who said this it is? Guido is working at his own pace, making changes as he discover new ways to do thing. select/menu is new user experience, so it hardly break current UX. Arguably we changed some keybinds, which were further adjusted. Another non-ui example would be merging incomplete clipboard support, if you think it's bad, sorry for that. Either way most of the feedback we got were positive, but I might as well stop merging those changes and see where it gets us.

[na-na-hi]

No one said it looks better. People said it looks nice.

OK, here is my worthless opinion: sharp corners look nice, round corners look nice too, i love mpv <3 Good now?

Even though there is no way to transform opinions like this into actionable items to improve the PR in any way, unlike real feedbacks.

Could you elaborate what does this mean?

It means as it says. For example, I can put a pretty screenshot of a feature so that the PR looks good for the users who have seen the screenshot and "wow" without any further testing, but avoid mentioning that it's changing key bindings in a disruptive way, etc..

Sure buddy, all credit goes to you.

Be honest, if I stopped posting here after you approved with LGTM, would you have merged at that state?

And who said this it is? Guido is working at his own pace, making changes as he discover new ways to do thing. select/menu is new user experience, so it hardly break current UX. Arguably we changed some keybinds, which were further adjusted. Another non-ui example would be merging incomplete clipboard support, if you think it's bad, sorry for that.

Anyone can open PRs with any pace, but it doesn't mean those PRs also need to merged at the same fast pace. Fast changes don't mean they are beneficial for the users. It depends on what are the benefits and drawbacks of the PR. I think a PR can be merged if it's a net positive with zero drawbacks, and any PR with known drawbacks needs to take steps to minimize them before they can be merged.

Of course, you won't be able to find any drawback if you don't do careful evaluations on the PR, and base your impression only on the positives. It does not matter whether it's my PR or someone else's PR.

But you do you. If you really think, for example, incomplete clipboard support is an issue, then you don't have to merge it at that state. I am not the one who make the decision on whether or when any PR should merged, with or without the need for any feedback. There is no "block merge" button in my control panel.

[kasper93]

OK, here is my worthless opinion: sharp corners look nice, round corners look nice too, i love mpv <3 Good now?

Don't act like I don't appreciate your feedback.

Even though there is no way to transform opinions like this into actionable items to improve the PR in any way, unlike real feedbacks.

Ok, let's step back a bit, because this discussion will get nowhere. It was me who initially pointed out that rounded corners doesn't fit current OSC, here #15711 (review)

Rounded corners are not in line with the rest of mostly rectangular only OSC.

Only reason I didn't insist on disabling it, because I knew that everyone liked it. I myself think it would be better to have it rectangular for the OSC consistency, but even then it is 4 to 2 in favor of rounded corners. So you can pick and prod my approach to PRs, but I'm not the person to convince here.

Be honest, if I stopped posting here after you approved with LGTM, would you have merged at that state?

I wouldn't because I didn't. If I wanted to merge it, I would approve and merge right away also look at the dates. Here is lil secret for you, approved prs get more incentive to get feedback from others. It may seem that I don't care, but I try my best.

Anyone can open PRs with any pace, but it doesn't mean those PRs also need to merged at the same fast pace. Fast changes don't mean they are beneficial for the users. It depends on what are the benefits and drawbacks of the PR. I think a PR can be merged if it's a net positive with zero drawbacks, and any PR with known drawbacks needs to take steps to minimize them before they can be merged.

Agreed, but what is your point?

If you really think, for example, incomplete clipboard support is an issue, then you don't have to merge it at that state.

See, this is the second time in the same message that you’ve tried to pin something on me that I haven’t done. If you disagree with me or something I did, please provide an example of what I actually did, rather than hypothetical "would-have-done" scenarios that never happened. I made mistakes, but who doesn't?

There is no "block merge" button in my control panel.

Any feedback until resolved one way or another is block merge.

[kasper93]

This is the difference:

--script-opt=console-corner_radius=8

--script-opt=console-corner_radius=0

I myself prefer softer looking corners. And also would like to have libass/libass#688 for profile=box for OSD messages.

If we consider consistency with OSC only (and profile=box if someone uses it) corner_radius=0 is more in-line. Though in my humble opinion OSC doesn't expose sharp corners, because it is anchored to the edges of the window and seekbar itself span whole height of the bar.

On the other hand if we consider all modern DE, whether macOS, Windows 11, KDE, Gnome, they all provide rounded window corners by default. So floating window inside mpv with rounded corners would be consistent with top level window look and feel

(incidentally I use --window-corners=donotround myself, because I dislike it, but still for floating window, I prefer cutting the sharp corner. It just doesn't look modern and OSC imho doesn't look out of place with it)

[guidocella]

Consider the initial implementation of this PR and at the current state: it's a dramatic improvement in both appearance and usability, which wouldn't have happened if I wasn't here """stalling""" this PR by suggesting alternatives and taking uosc as a hint.

Come on, do you think you made me discover uosc? I've already been comparing it for months and considering copying ideas from it e.g. #15346 (comment) #15499 (comment) #15608 (comment) (format quality selector idea copied from uosc)

2024-12-29 14:01:03 Samillion guido: lol, two oscs on top of each other: Samillion/ModernZ#282 (comment)
2024-12-29 14:01:15 Samillion that guy invented a new level of comfort :D

(user preferring uosc's menus making me consider copying them).

It was in fact kasper's idea to calculate the maximum width that allowed centering alignment, then the maximum width allowed implementing a horizontal hitbox and positioning a scrollbar (which I had already implemented with bottom left alignment before opening this PR - #15101 (comment)), then the scrollbar made me decide that it looked better with a background, and kasper also requested changing the background color of the selected item before opening this PR. On the other hand you suggested covering the whole window width, recalculating the width as you scroll which changes the background width as you scroll which no menu UI does (after saying yourself that we shouldn't do what no menu UI does), expanding the width as you type which no menu UI does, adding rounded corners to the bottom aligned OSC, which would be completely idiotic, for the sake of consistency with the menu as if blindly making everything consistent like a robot is more important than sane design or usability. And now you're wasting everyone's time arguing the irrelevant detail of rounded corners after everyone but you already expressed preference for rounded corners, so how about getting off your high horse.

[na-na-hi]

If you disagree with me or something I did, please provide an example of what I actually did, rather than hypothetical "would-have-done" scenarios that never happened. I made mistakes, but who doesn't?

Sorry if there was any misunderstanding. I did not mean to say any particular PR merge is bad. Just suggesting to take steps to minilize drawbacks before PR merging. If you are already doing this, no worry.

Come on, do you think you made me discover uosc? I've already been comparing it for months and considering copying ideas from it e.g. #15346 (comment) #15499 (comment) #15608 (comment) (format quality selector idea copied from uosc)

Of course not, but you clearly did not have uosc in mind when you opened this PR, otherwise you would've taken hints from uosc from the start.

Up until I mentioned uosc in this thread, you still insisted on your initial solution, and didn't want to draw background yourself instead of relying on libass: #15711 (comment)

You also failed to take the hint I gave in my second and third replies in this PR. I knew from the start that uosc would solve all problems with the intial version of this PR perfectly, and most importantly, what techniques uosc used to solve it that we can borrow from, but I intentionally withheld it and deceided to give you some hints instead, trying to test if you can figure something out yourself.

I outlined why the initial solution is bad and why self-drawing background can solve it. You did not come up with a solution to clip text overflow resulted from inexact longest width calculation with \clip tag. You did not come up with a solution to cache line widths. If you really knew uosc so well you would have known the solutions from the start.

It's one thing to know what uosc is. It's another thing to know why uosc is the way it is, which from the exchanges in this thread, you clearly have no idea about.

(user preferring uosc's menus making me consider copying them).

OK, it's no doubt you had this thought when you saw that message. Why didn't you do that for this PR? Why did you reject my hints which are the steps necessary to implement uosc-like menus?

It was in fact kasper's idea to...

I don't know what's the point of this. If any, it only shows that kasper knows the principles of UI/UX better than you.

On the other hand you suggested covering the whole window width

Come on, I only said this because you said it's too slow to calculate the exact width needed.

recalculating the width as you scroll which changes the background width as you scroll which no menu UI does (after saying yourself that we shouldn't do what no menu UI does), expanding the width as you type which no menu UI does

It's already doing it currently, so it won't be a regression. It's only a significant problem when the menu is centered, which I never asked for. I would prefer to keep the current bottom-left alignment personally.

for the sake of consistency with the menu as if blindly making everything consistent like a robot is more important than sane design or usability

"design or usability"? Right, all accounted for by the initial version of this PR. Correct me if I'm wrong, but I'm not seeing many useful inputs of "design or usability" from you. It's always about copying how XYZ tool does it on a surface level, and often times it's someone else who is pointing out the design and usability issues and whether it mekes sense in the context of mpv.

Not to mention that you failed to demonstrate any good understanding of it even after copying uosc design. You were still arguing about scrollbar size needing to be perfectly mathematicallty accurate, not realizing that the very uosc you copied from "lies" about scrollbar size too.

And now you're wasting everyone's time arguing the irrelevant detail of rounded corners after everyone but you already expressed preference for rounded corners, so how about getting off your high horse.

The fact that you think rounded corners are an "irrelevant detail" shows that you're not standing on any high ground here. kasper elaborated reasons why rounded corners make sense, citing consistency principle in desktop environment sense. You didn't say anything other than "it looks nice".

[guidocella]

Of course not, but you clearly did not have uosc in mind when you opened this PR, otherwise you would've taken hints from uosc from the start.

Up until I mentioned uosc in this thread, you still insisted on your initial solution, and didn't want to draw background yourself instead of relying on libass: #15711 (comment)

I already said it was kasper's specific request to do it like this and not my solution. I don't use background-box, so I didn't care that much to change it.

You also failed to take the hint I gave in my second and third replies in this PR. I knew from the start that uosc would solve all problems with the intial version of this PR perfectly, and most importantly, what techniques uosc used to solve it that we can borrow from, but I intentionally withheld it and deceided to give you some hints instead, trying to test if you can figure something out yourself.

Please don't waste people's time playing games and give solutions directly if you have them.

I outlined why the initial solution is bad and why self-drawing background can solve it. You did not come up with a solution to clip text overflow resulted from inexact longest width calculation with \clip tag.

What? I did come up with using clip.

You did not come up with a solution to cache line widths.

What again? I did come up caching the width of the longest line. It's your solution of caching multiple lines as you scroll which was broken because the menu's width would change as you scroll.

If you really knew uosc so well you would have known the solutions from the start.

It's one thing to know what uosc is. It's another thing to know why uosc is the way it is, which from the exchanges in this thread, you clearly have no idea about.

I don't know when I said I know uosc well, when rather I said I don't use OSCs at all.

OK, it's no doubt you had this thought when you saw that message. Why didn't you do that for this PR? Why did you reject my hints which are the steps necessary to implement uosc-like menus?

As I already said, I did it because kasper specifically requested this implementation on IRC, which was not my idea. It's getting really annoying debating with you when you're the only dev not aware of the conversion in the IRC development channel.

Come on, I only said this because you said it's too slow to calculate the exact width needed.

There was a misunderstanding here, what I said was that it's too slow to calculate it indipendently for each line.

"design or usability"? Right, all accounted for by the initial version of this PR. Correct me if I'm wrong, but I'm not seeing many useful inputs of "design or usability" from you. It's always about copying how XYZ tool does it on a surface level, and often times it's someone else who is pointing out the design and usability issues and whether it mekes sense in the context of mpv.

Yeah because it's masters of design that suggest rounded corners on a bar aligned to a corner. I literally linked a tweet from a designer which influenced the decision to not add borders between the items or around the menu and to distantiate them.

Not to mention that you failed to demonstrate any good understanding of it even after copying uosc design. You were still arguing about scrollbar size needing to be perfectly mathematicallty accurate, not realizing that the very uosc you copied from "lies" about scrollbar size too.

And I changed it as soon as kasper agreed, unlike you who insisted on square corners after 4 other people preferred them rounded.

kasper elaborated reasons why rounded corners make sense, citing consistency principle in desktop environment sense. You didn't say anything other than "it looks nice".

If it looks nice to everyone to you that's a perfectly good reason to do it. Changes everyone likes don't have to be justified to you. As if you gave more detailed reasons against the inital layout other than "it's not nice".

[na-na-hi]

To clarify my final thought: using a default rounded corner means a change in mpv's design language, which would be a commitment to implement rounded corner changes to at least OSD bar and background-box.

OSD bar is a part of the default user experience and is something in mpv's control, so that can be changed now. There will be no other suggestions from me for the rounded corner change. Feel free to ignore this and merge when it's ready otherwise if it's not considered a blocker.

[kasper93]

OSD bar is a part of the default user experience

In my opinion OSD bar is not compatible with OSC. It is good to have if you use mpv without OSC, but it is already not compatible with interface.

[guidocella]

I'd definitely like rounded corners on the OSD bar, even already suggested it in the previous PR, but it's work that needs to be done.

[na-na-hi]

I already said it was kasper's specific request to do it like this and not my solution. I don't use background-box, so I didn't care that much to change it.

Have you evaluated yourself whether that request makes sense and whether if there are better solutions for it? I don't think blindly taking requests without evaluation is a good idea. Otherwise mpv will become even a bigger mess because everyone's ideas can go in no matter how good or bad they are.

What? I did come up with using clip.

Not before I mentioned uosc in the PR. Otherwise, the text overflow issue should be fixed already before the layout change.

What again? I did come up caching the width of the longest line. It's your solution of caching multiple lines as you scroll which was broken because the menu's width would change as you scroll.

As mentioned several times before it's not the longest display width. And menu width changing literally isn't a problem for now because the status quo has the same problem, so no regression. Again, I have never asked the menu to be center aligned.

Yeah because it's masters of design that suggest rounded corners on a bar aligned to a corner. I literally linked a tweet from a designer which influenced the decision to not add borders between the items or around the menu and to distantiate them.

It's likely that you followed that tweet just because borderless "looks nice", because you have not taken a hint from other points outlined in that tweet, all of which enhance usability and readability. Where is the different background color for search bar? Where are the extra paddings? I noticed both of these issues immediately after the new layout was first posted, long before you posted that tweet. I didn't mention it because there were other more important issues need to be addressed first.

And I changed it as soon as kasper agreed, unlike you who insisted on square corners after 4 other people preferred them rounded.

Stop going "kasper this, kasper that". Evaluate suggestions on their own merit. There is no need for his agreement to see why that suggestion makes sense.

If it looks nice to everyone to you that's a perfectly good reason to do it. Changes everyone likes don't have to be justified to you.

Those who dislike it often don't show up immediately. It has happened countless of times before that there really isn't any consensus when disagreements show up only after the changes are merged and shoved down to their throats.

As if you gave more detailed reasons against the inital layout other than "it's not nice".

Consistency/familiarity was the reason mentioned. That screenshot by itself should be apparent.

[na-na-hi]

In my opinion OSD bar is not compatible with OSC. It is good to have if you use mpv without OSC, but it is already not compatible with interface.

IMO the same can be said for other OSD text because they use borders instead of a background by default, like OSC.

The OSD bar also needs a redesign to fit into the OSC design theme.

[guidocella]

Have you evaluated yourself whether that request makes sense and whether if there are better solutions for it? I don't think blindly taking requests without evaluation is a good idea. Otherwise mpv will become even a bigger mess because everyone's ideas can go in no matter how good or bad they are.

I don't decide which ideas get in, evaluation is already what PRs are for, and I don't personally care about background-box, those who use it can argue it better which is exactly what happened.

Not before I mentioned uosc in the PR. Otherwise, the text overflow issue should be fixed already before the layout change.

Well duh? There was no custom background drawing before you mentioned uosc, so no need for clipping, which I added along with center alignment.

As mentioned several times before it's not the longest display width. And menu width changing literally isn't a problem for now because the status quo has the same problem, so no regression. Again, I have never asked the menu to be center aligned.

It's only the status quo if one was using the non-default background-box. It looked bad to someone like me not used to it.

It's likely that you followed that tweet just because borderless "looks nice"

I followed all of his advices since 2017, they are gold.

because you have not taken a hint from other points outlined in that tweet, all of which enhance usability and readability. Where is the different background color for search bar?

Not being implemented yet doesn't mean I haven't considered the hint. This PR is already huge without more additions, and it is not as simple as doing it in a web page when font and background colors are configurable which can make the input line look mismatched or decrease readability.

Where are the extra paddings?

In the opts.font_size * 1.1 factor present since the first commit.

Stop going "kasper this, kasper that". Evaluate suggestions on their own merit. There is no need for his agreement to see why that suggestion makes sense.

Disagreeing is an evaluation. It is normal to be skeptical until more people agree.

Those who dislike it often don't show up immediately. It has happened countless of times before that there really isn't any consensus when disagreements show up only after the changes are merged and shoved down to their throats.

No idea what the point here is as there will obviously people disliking whatever we do and whether it has good reasons or not. I've seen e.g. users complaining that left clicking track buttons should show a menu which was reverted. The majority of developers' preferences is the best guess of what is better.

[Dudemanguy]

I think all the actual issues were ironed out by now.