3 ms·

>OK so what is the ideal solution in your opinion? Cheeky answer: The ideal solution is a smartphone. It has no keyboard. You don't have to worry about keybind

>OK so what is the ideal solution in your opinion? Cheeky answer: The ideal solution is a smartphone. It has no keyboard. You don't have to worry about keybindings at all anymore. Real answer: There isn't one. Once apps can do their own keyboard handling and make their own keybindings, any hope of making a clean solution goes out the window. It's hacks upon hacks from there on, because anything a new app does could potentially conflict with your settings. The Mac solution isn't perfect either but is definitely more flexible and less broken than key themes. >You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user. Yes, you're correct. GNOME apps could use the app menu API anyway, the menu wouldn't be visible, but some settings GUI could look at the information exposed by the API and use that to do other things. In practice they don't use that API at all because it has no visible effect for GNOME users, and it's not very compelling to require them to use an API that only adds some actions that are hidden away in a settings panel somewhere. Sure you could change this. But you have to convince every app developer it's a good idea to start doing it when they've already taken a lot of steps to move away from menu bars. Including completely removing them from the HIG. I'm not trying to say this is impossible but it's a major change that will affect every app, and you would have needed to do something similar anyway if you were trying to fix key themes to not be so broken. >But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels. No, I've seen plenty of apps where Copy with nothing selected takes some reasonable action. Like if you pressed it after opening a dialog displaying a short document, it could copy the entire document for convenience. I can't say no one will ever come up with some reason to do this in a terminal. If it's a Mac terminal, they have few incentives not to because there isn't a key conflict by default with Ctrl-C. If you go around changing your keybindings and you break that, it's on you. Then you probably want to change it back after you find out it's broken. No one can predict what an app will do, that's the point of letting them handle their own keybindings. >And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else. By all means, if you like the way Mac handles this, you should use a Mac. Different operating systems are different for a reason.

rollcat 3y ago
> By all means, if you like the way Mac handles this, you should use a Mac. So let me recap: 1. You've said Gtk/GNOME relies on volunteer contributions; 2. GNOME removes (or refuses to implement, mutter#217) perfectly reasonable features that both regular and power users need/want/rely on, without providing alternatives (unless the plan is to get libadwaita eventually linked into the kernel); 3. You tell someone who shows interest in said features (outlining alternative designs, implementations, diving into some of the edge cases, and weighting their pros and cons), that if they like these features, they should use macOS instead. Conclusion: GNOME drives away the same people who have the motivation and expertise to contribute to the platform. Self-sabotage. Here's a hint: it works for Apple, because Apple produces a polished and highly desirable product. But even Apple caters to their professional audience. It works for suckless, because they're elitists and mostly irrelevant. But even suckless maintains an official repo of community patches. How many active forks of KDE do we have out there?

rollcat 3y ago

> By all means, if you like the way Mac handles this, you should use a Mac. So let me recap: 1. You've said Gtk/GNOME relies on volunteer contributions; 2. GNOME removes (or refuses to implement, mutter#217) perfectly reasonable features that both regular and power users need/want/rely on, without providing alternatives (unless the plan is to get libadwaita eventually linked into the kernel); 3. You tell someone who shows interest in said features (outlining alternative designs, implementations, diving into some of the edge cases, and weighting their pros and cons), that if they like these features, they should use macOS instead. Conclusion: GNOME drives away the same people who have the motivation and expertise to contribute to the platform. Self-sabotage. Here's a hint: it works for Apple, because Apple produces a polished and highly desirable product. But even Apple caters to their professional audience. It works for suckless, because they're elitists and mostly irrelevant. But even suckless maintains an official repo of community patches. How many active forks of KDE do we have out there?