3 ms·

>Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes

>Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus Sorry I don't count that, this is comparing apples to oranges again. It's still not the same as key themes. You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. It doesn't work either if the command has a slightly different name for some reason. Even if you wanted this type of configuration in GNOME, and if it were even possible, which it sort of is already, it still would be implemented in a completely different way than key themes were. Because key themes were just broken. The difference is key themes are another thing that claims to do it automatically. If they were working correctly there would be no conflicts. They don't though, so either way if there are conflicts you have to hunt those down and reconfigure every app individually again and then you get to remember which apps have different shortcuts because you had to do something weird to resolve the key conflicts. The point is, I can't just flip a switch that changes everything to Windows shortcuts. The other issue here is how this relates to GTK and GNOME apps. Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. So, as always, it still comes back to how the app developer chooses to make the app and what platform conventions they follow. Please be aware of what you're asking for here, it may seem like a simple request to you but when you dig into it it's really asking to change several things in every app to be more like some other platform. And that's not a reasonable request unless you're willing to see it through all the way. >Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels. This behaviour is again dependent on how the terminal handles the menu. It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. It won't work at all if you have another key theme where Ctrl-C is an action that's always enabled. And what if I want to rebind SIGINT in this scenario, how does that work? I don't expect terminals to add a menu entry for every terminal escape, but that's how they would have to do it using the Apple approach. Or they have to add their own setting for this, which is no better than before. >Well, I could argue up until this point, but this is the suckless.org attitude. No, this is the everything attitude. An app developer can always choose what settings they want to present to the user and what features they want to support. If you don't like it, then yes, most of the time it's "my way or the highway". That's how this software thing works, open source or closed source. Mac, Windows, Linux, all of them have a different collection of settings they support. If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.

rollcat 3y ago
> [...] You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. [...] Because key themes were just broken. OK so what is the ideal solution in your opinion? If key themes are broken, and having the ability to reconfigure a single key (for any single, or all apps) in a central place is also broken, then what isn't? Hardcoding all key combos in the source? Having every app developer build a custom settings dialog where maybe they will, or maybe they won't let you configure a given shortcut? > Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. 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. > It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. 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. > If it's open source you just always have the extra option to recompile if the original developer didn't want to do it. And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.
- u9OEYkI0bUxuGns 3y ago
  >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

> [...] You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. [...] Because key themes were just broken. OK so what is the ideal solution in your opinion? If key themes are broken, and having the ability to reconfigure a single key (for any single, or all apps) in a central place is also broken, then what isn't? Hardcoding all key combos in the source? Having every app developer build a custom settings dialog where maybe they will, or maybe they won't let you configure a given shortcut? > Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. 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. > It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. 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. > If it's open source you just always have the extra option to recompile if the original developer didn't want to do it. And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.

u9OEYkI0bUxuGns 3y ago
>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.