What's the state of wxWidgets nowadays? I feel like they've always had the most honest approach to cross-platform support.
On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.
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/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.
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.
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.
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.
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.
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.
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?