3 ms·

>The concept was never broken on macOS Yes it is, MacOS also doesn't have key themes. I can't reconfigure a Mac to use Windows keyboard shortcuts. Those are ju

>The concept was never broken on macOS Yes it is, MacOS also doesn't have key themes. I can't reconfigure a Mac to use Windows keyboard shortcuts. Those are just the default key bindings every Mac app has to support. That's why it works on Mac and it doesn't work on Windows or Linux or anywhere else where the defaults are different. You're comparing apples to oranges here. To elaborate, Mac gets away with it because historically it has Command as an extra modifier and uses that as the primary modifier key. The Control key isn't used for anything else on Mac. GTK apps need to support non-Mac keyboards where Control is the primary modifier key. The Win or Super key on PC keyboards is historically not used often as a modifier. If it is used as a modifier it's often only used by the shell, not by an app. So, what is consistent for you depends on platform conventions anyway. >but it's still quite disappointing that the "free" desktop is where my preference is disrespected. This isn't a desktop preference, you're asking every app to fundamentally change the way its keybindings work. The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. It doesn't mean that suddenly every preference that you want will start working without any extra effort or causing additional bugs.

rollcat 3y ago
> I can't reconfigure a Mac to use Windows keyboard shortcuts. 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. You can rebind anything for all apps, or only for a specific app. You can also swap Cmd and Opt. This is probably easier for newbies than editing a text file, but you can't trivially check it into git. I still have a PowerPC Mac with OSX 10.5, I should probably check if it was supported at the time, but my hunch is that it was. The point is it's there, out of the box, and it's working extremely well. The most interesting thing with this setup is what the terminal does: Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels. > The Win or Super key on PC keyboards is historically not used often as a modifier. Yes and no. The scan code is the same as Cmd. If you plug an Apple keyboard to a PC or a PC keyboard to a Mac, the only issue is figuring out if you want to swap it with Alt/Opt. Cmd/Win has also always been a very popular choice for the "modifier" key in minimalistic/tiling window managers, and GNOME has supported that too, even back in the early 2.x days (I'm not old enough to remember 1.x). Even Windows started using Win-E for things like launching the file manager, Win-P for configuring the screens, Win-arrow keys for window placement, etc - some of that more than 20 years ago IIRC. So it's not like there's no historical precedent, it's always been about conventions, platform defaults, and what do you want to leave up to the user. I fully agree with "convention over configuration", but if you take away the "configuration" part, what's left is "my way or the highway". > The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. Well, I could argue up until this point, but this is the suckless.org attitude. Awesome. Is this how dwm becomes more user-friendly than GNOME? FYI I've never had to compile Emacs, Sway, or Alacritty (or ANYTHING on Mac) just to change the key bindings, and I'm definitely the guy who tries to change EVERYTHING.
- u9OEYkI0bUxuGns 3y ago
  >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

> I can't reconfigure a Mac to use Windows keyboard shortcuts. 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. You can rebind anything for all apps, or only for a specific app. You can also swap Cmd and Opt. This is probably easier for newbies than editing a text file, but you can't trivially check it into git. I still have a PowerPC Mac with OSX 10.5, I should probably check if it was supported at the time, but my hunch is that it was. The point is it's there, out of the box, and it's working extremely well. The most interesting thing with this setup is what the terminal does: Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels. > The Win or Super key on PC keyboards is historically not used often as a modifier. Yes and no. The scan code is the same as Cmd. If you plug an Apple keyboard to a PC or a PC keyboard to a Mac, the only issue is figuring out if you want to swap it with Alt/Opt. Cmd/Win has also always been a very popular choice for the "modifier" key in minimalistic/tiling window managers, and GNOME has supported that too, even back in the early 2.x days (I'm not old enough to remember 1.x). Even Windows started using Win-E for things like launching the file manager, Win-P for configuring the screens, Win-arrow keys for window placement, etc - some of that more than 20 years ago IIRC. So it's not like there's no historical precedent, it's always been about conventions, platform defaults, and what do you want to leave up to the user. I fully agree with "convention over configuration", but if you take away the "configuration" part, what's left is "my way or the highway". > The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. Well, I could argue up until this point, but this is the suckless.org attitude. Awesome. Is this how dwm becomes more user-friendly than GNOME? FYI I've never had to compile Emacs, Sway, or Alacritty (or ANYTHING on Mac) just to change the key bindings, and I'm definitely the guy who tries to change EVERYTHING.

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