4 ms·

Nothing was sabotaged there. Custom key themes were removed because the whole concept of them was broken. The only one anyone ever seemed to use was the Emacs t

Nothing was sabotaged there. Custom key themes were removed because the whole concept of them was broken. The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. It would get even worse if you had your own custom key theme, there's nothing reasonable an app can do when you add a bunch of key binds that break its keys. On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.

rollcat 3y ago
> Custom key themes were removed because the whole concept of them was broken. The concept was never broken on macOS. It's also implemented in a brilliantly simple and very user-accessible way, and requires very little consideration from the application developer. Between that, or having a single configuration file where one can achieve a similar result, deciding which method is better probably boils down to personal preference. No more personal preference for me though. > The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. Again, macOS does effectively have what can be summarised as "Emacs keybindings": C-a, C-k, C-b, etc all do what you expect them to do, and if you do ever find any particular key combo conflicting for some obscure reason, you have a simple, system-level tool to fix it. I know the issue under GNOME mostly comes from trying to find a compromise between copying what Windows does, and what's native to the terminal, but all I'm really trying to achieve is to have a consistent working environment. The way things are: in the terminal, Ctrl-C sends an interrupt, and Ctrl-Shift-C (or some other combination, depending on your terminal emulator) copies text; in Emacs C-c is a command prefix, and M-w is copy; etcetera. I find working like this frustrating; I could probably stomach having Ctrl-C as copy everywhere (even if it meant doing something unspeakable to the terminal emulator to keep the ability to send SIGINT to the foreground process), but I used to be able to whackamole every app into respecting my preference for using Cmd-C for that. Switching between all these conventions is unnecessary mental fatigue. I know my argument is pretty much <https://xkcd.com/1172/ https://xkcd.com/1172/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
- chrismorgan 3y ago
  I’m now curious whether Emacs key bindings work in GTK text boxes on macOS.
  - rollcat 3y ago
    It's inconsistent. I haven't touched my Gtk settings on macOS, and here are the defaults: Ctrl-A in Gimp (Gtk2) selects all text; in Inkscape (Gtk3) it hops to the start of the line; I'm not sure which apps use Gtk4 so can't tell for this one.
- u9OEYkI0bUxuGns 3y ago
  >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.

rollcat 3y ago

> Custom key themes were removed because the whole concept of them was broken. The concept was never broken on macOS. It's also implemented in a brilliantly simple and very user-accessible way, and requires very little consideration from the application developer. Between that, or having a single configuration file where one can achieve a similar result, deciding which method is better probably boils down to personal preference. No more personal preference for me though. > The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. Again, macOS does effectively have what can be summarised as "Emacs keybindings": C-a, C-k, C-b, etc all do what you expect them to do, and if you do ever find any particular key combo conflicting for some obscure reason, you have a simple, system-level tool to fix it. I know the issue under GNOME mostly comes from trying to find a compromise between copying what Windows does, and what's native to the terminal, but all I'm really trying to achieve is to have a consistent working environment. The way things are: in the terminal, Ctrl-C sends an interrupt, and Ctrl-Shift-C (or some other combination, depending on your terminal emulator) copies text; in Emacs C-c is a command prefix, and M-w is copy; etcetera. I find working like this frustrating; I could probably stomach having Ctrl-C as copy everywhere (even if it meant doing something unspeakable to the terminal emulator to keep the ability to send SIGINT to the foreground process), but I used to be able to whackamole every app into respecting my preference for using Cmd-C for that. Switching between all these conventions is unnecessary mental fatigue. I know my argument is pretty much <https://xkcd.com/1172/ https://xkcd.com/1172/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.

chrismorgan 3y ago
I’m now curious whether Emacs key bindings work in GTK text boxes on macOS.
- rollcat 3y ago
  It's inconsistent. I haven't touched my Gtk settings on macOS, and here are the defaults: Ctrl-A in Gimp (Gtk2) selects all text; in Inkscape (Gtk3) it hops to the start of the line; I'm not sure which apps use Gtk4 so can't tell for this one.
u9OEYkI0bUxuGns 3y ago
>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.