Hey! First of all, thanks for all your hard work on Ardour! Just like you, I decided not to use Windows for my media production workflow some years ago, and set

Hey! First of all, thanks for all your hard work on Ardour! Just like you, I decided not to use Windows for my media production workflow some years ago, and set out on a journey that has been as much enlightening as frustrating. I've used Reaper, Renoise, Bitwig, even Ableton on Wine, all are great, all are proprietary. I'm really looking forward to trying out the new clip launcher and the smart ripple editing. I think Ardour just might be the sequencer that all the outboard gear I've accumulated in the meantime is waiting for. I definitely hope so! I guess I just gotta wait a few more days for my distro to upgrade the package (https://github.com/NixOS/nixpkgs/pull/196290 https://github.com/NixOS/nixpkgs/pull/196290) - but that's completely fine. What I'd like to ask is whether you consider important the issues that I've pointed out on this screenshot (from 6.9): https://imgur.com/a/yk60rNc https://imgur.com/a/yk60rNc 1. IMHO, the grid lines being Too Damn Bright is hands down the most jarring thing for any newcomer to Ardour. Basically, there's too much contrast on the very thing that delineates/delimits empty, user-editable space, relative to the contrast in screen areas that contain fixed UI controls. It just creates the impression of a barrier in the wrong place. Changing the line color from 100% white to 100% black would be at least a 200% improvement in terms of more betterness; a slider from 100% black to 100% white would bump that up to 300%. The rest is mostly 1px misalignments that just sort of add up: 2. Top row of pixels in the menu bar is not active. So in full screen if you move the mouse all the way to the top edge of the screen the menus don't work. You can see this when opening a menu - GNOME didn't let me take a screenshot with a menu open lol 3. The 4px gradient border causes the "transport" and "editing" toolbars to look very misaligned. 4. The above border ends a few pixels above the "scrollbar/overview". Apparently there's a dragging handle there - but no hint that it's there. 5. These are the only toolbar buttons that don't have a border. If this is meant to signify that the button is inactive (why does "solo" behave differently from the others?), it would benefit from also making the text a tad dimmer. 6. Icon noclips out of the button. 7. Why the monospace here? It's not aligned to anything. 8. Separators would benefit from either being more prominent, or just being blank spaces. All separators except the one that the arrow points to have N pixels to one side and N+1 pixels to the other. Button text is also 1 pixel below the center of the button (and below the baseline of neighboring labels). These things are noticeable, and annoying, on a 24" 1440p monitor at 150% zoom. Is this due to the scaling or something else? It simply looks slightly unappealing and "broken-ish", which does not do justice to the underlying engineering effort. I think this problem plagues virtually all native GUI apps based on FOSS toolkits, and hampers migration away from proprietary solutions, to a degree that is often underestimated. I have some experience trying to get people to migrate to FOSS solutions, and I realize that it's an uphill struggle against BigCos that have whole design departments and can afford to condition people as to "what things should look like". Computers are scary enough beasts as it is - it's too easy to present either too much or too little information to users, who just expect things to be "intuitive" (i.e. learned helplessness). People who have looked proprietary apps all their lives are prone to viscerally rejecting a solid FOSS product that might even be a better fit for their workflow, just because of superficial glitches like the ones I listed above. One funny effect of this: users might even identify the problem at the wrong level. They may object to the semantics of the interface ("I don't understand it"), while the problem actually is on the level of ergonomics ("it doesn't feel right"). Maybe they don't want to seem petty. I know my way around Ardour and the general Linux audio ecosystem well enough to get things done with it, but the reason I don't bring Ardour with me everywhere is ... basically the grid lines and alignment! Please tell me there's a dotfile for that, or that a fix is on the roadmap? :-) I realize this might be just my "OCD" speaking; I'm still recovering from the heartbreak that was Qt's default font rendering (maybe still is; I think Krita started to look fine at some point, I don't use many other Qt apps...) But I feel like Ardour might be missing out on a big chunk of useful feedback from people that don't even engage with the product deeply enough to provide feedback - because of admittedly silly things (like 10 individual widgets on the main screen being 1 pixel off) that make them automatically disengage. Some might say that such users don't have a serious attitude, so why would they be owed any consideration? I believe proprietary software has conditioned them to believe that their opinions don't matter anyway - which in the case of FOSS couldn't be further from the truth, but then again how are they supposed to know that. So, here I am seriously engaging with this topic in their stead. Sorry for not filing this on the issue tracker I guess . (1) its Web UI basically creates the same impression and (2) I'm weird about creating accounts, that's 1 external and 1 internal reason that combine into nudging me in the direction of speaking up here instead :-)