|
|
|
|
|
|
by cmiles74
2439 days ago
|
|
|
The Cocoa text input widget supports these keybindings and is used in many applications. Linux does not have one single input widget that is as popular (Gnome apps use a GTK text widget, KDE apps use a Qt text widget, etc.) On Linux, you would need to address this setting on a per widget set basis. I don't think this supports the argument that Mac OS X is somehow more customizable that Linux. In my opinion it's the opposite: every application is strongly encouraged to use the same text widget. We're lucky in this case that we like this function. In other cases (like virtual desktop management) Apple's decisions have been towards less customizability. I believe that has long been a Hallmark of Apple, back when OS X was released Apple scoffed at the idea that anyone would ever want to change the default theme (which at that time was a bit more extreme). A "gray" theme.was introduced after much pressure from customers. That said, I seriously doubt that the Apple Computer of today is as interested in ensuring this functionality to the same degree as the Apple of ten years ago. They have made many developer unfriendly decisions in the past decade, I wouldn't count on this feature being present indefinitely. |
|
|
Yes, I clearly already understood that. I was pointing out how absurd ColanR’s claim was that he could do this all through i3 config “super easy”. It isn’t within the domain of the window manager to control the toolkits’ widget bindings, which are all over the map in terms of customizability.
> I don't think this supports the argument that Mac OS X is somehow more customizable that Linux. In my opinion it's the opposite: every application is strongly encouraged to use the same text widget.
Which, in my opinion, strongly increases customizability because I can be sure the things I customize work the way I want them to effectively everywhere; I am not limited by every third application author’s obstinate choice to hardcode some other set of bindings in some deliberately incompatible toolkit.
I’d suggest that our disagreement comes down to the fact that configurability is not a linear gradient, but a fairly complex, multi-dimensional topic with a lot of subtle trade-offs that different people may have different preferences surrounding.
> I wouldn't count on this feature being present indefinitely.
Sure. Similarly I don’t count on however you do this in GTK today still working in 5 years, given how often they CADT their way into new incompatible configuration systems.