4 ms·

Sadly, you chose sarcastic trolling instead of clearly communicating your point. However, it seems like you're assuming system-wide keyboard shortcuts and consi

Sadly, you chose sarcastic trolling instead of clearly communicating your point. However, it seems like you're assuming system-wide keyboard shortcuts and consistent defaults means you can't change anything. On macOS, you can change the keyboard shortcuts, including idiosyncratic ones, of (almost?) any application, certainly any pure Cocoa one. I have Word set up so that CmdV pastes unformatted, for example, and I have to use ShiftCmdV if I want the full suite of paste options. So I guess I feel confused about why you'd rant in defense of "those who like different shortcuts," and then call out macOS specifically, when that's an area where it shines over all others.

palata 4y ago
Sorry for the communication style, that's noted. I meant to communicate a point though. My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set that in the system-wide settings? I would guess that macOS does not strictly enforce the system bindings, does it? Say it does -> application developers lose flexibility because they can't design a different UX if they want to. Say it doesn't -> application developers now have to decide, for each binding, if they want to define a default themselves (which would be consistent with the rest of their app) or if they want to honor the system bindings (and possibly have a terrible UX that people will complain about). It's not an easy problem :-).
- bombcar 4y ago
  You can override things like paste system-wide or you can customize it for a particular app.
  - palata 4y ago
    Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults. Even for the obvious example of the text editor, where "everybody wants Ctrl+P to paste", where I precisely don't want that in vim and emacs. That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves (instead of reusing something I defined system-wide for different apps). Because the app developer knows their app better. If I don't like it, I can customize it or just not use it. "Don't use vim if you want it to behave like Word", in some sense. Both are great, but different. And that's fine.
    - throw10920 4y ago
      > The problem is that it makes it harder for the app to have sane defaults. How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use? > That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves The above system seems to fairly easily fit your preference - you can trivially choose to use the app bindings, and GP can trivially choose to use the system bindings. You're advocating for needlessly restricting user choice by using a design that doesn't allow them to pick between a unified set of system shortcuts (which I, and many other millions of people want) and each app doing it their own way (which is a UX disaster for new users).
      - palata 4y ago
        > You're advocating for needlessly restricting user choice Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance. > How is this not trivially solved [...] Well first you need to find a way to integrate that toggle in your UI without people complaining too much. Then you need to test that it works on your platform (I see a lot of room for errors, e.g. if the system default is not set, or set to something weird, or conflicting with another app), and then you need to make it work on other platforms (which most certainly won't provide a compatible API). Sounds easy, in practice nobody would want to pay for the work required to do it. That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
        throw10920 4y ago
        > Nope, I'm advocating for letting the app developers do what they want. You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all: > Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults. That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model. Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion. > Well first you need to find a way to integrate that toggle in your UI without people complaining too much... ...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it) > That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app. Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread. Do you have anything actually relevant that you'd like to add?
- torstenvl 4y ago
  They're not enforced by technical means, usually, but Apple HIG are fairly highly regarded by developers and users alike. I only do UI programming in wxWidgets so I can't speak for other developer workflows. When I create a menu system, if I don't include accelerators manually, the system-appropriate ones are automatically added for certain things. Additionally, wxWidgets automatically moves Windows/Linux "standard" menu items to macOS-specific locations (e.g., Quit and About menu items), if and only if they're in the pertinent menus at the time they're added to the menu bar. If I add the File menu to the menu bar, and then add "E&xit" to the file menu, it still shows in the File menu. So, in my experience, it's a strong default, but it isn't constraining; you can easily override that behavior when necessary.
  - palata 4y ago
    Yeah for UI it makes a lot of sense. Especially if those are "standalone" (for lack of a better word) elements. For instance, changing the accelerators (I guess that's related to the animation when opening a menu, right?) cannot really conflict with anything else. So it's perfect to use system-wide configurations like that. But I wonder about key bindings. I think it makes sense to have guidelines, and to use "Cmd + Q" to quit whenever it makes sense. But defining this as a high-level action "quit", and letting the user define the binding (e.g. "I want Cmd + S to quit") seems rather complicated to me. If "Cmd + S" is already set system-wide for the "save" action, then the system could tell you "that will disable the 'save' action, are you sure?". But if you go for "Quit with Cmd + J", and "Cmd + J" is not a system-wide binding but instead is used by... say... Blender. Then the system will happily change "Ctrl + Q" with "Ctrl + J", and now what happens if you hit "Ctrl + J" in Blender? Should it quit, or should it do what Blender does for "Ctrl + J"? I am not sure everything can be configurable. My Firefox toolbar is at the top, on mobile I can have it at the bottom (not sure I can do that on Desktop). But I can't have it in the middle of the page, or vertically on a side. That's a decision that was made by the Firefox devs, not by the system settings. That does not mean we should not expect sane defaults, but I would argue that ":q" is a sane default in vim.
bombcar 4y ago
macOS shortcut editing/configuration is an unsung strength of the platform; it’s quite amazing and anyone who uses macOS should spend an hour investigating it. Your past shortcut change is something I’ve done similarly but you can also assign shortcuts to menu commands that you use often but don’t have one, etc.

palata 4y ago

Sorry for the communication style, that's noted. I meant to communicate a point though. My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set that in the system-wide settings? I would guess that macOS does not strictly enforce the system bindings, does it? Say it does -> application developers lose flexibility because they can't design a different UX if they want to. Say it doesn't -> application developers now have to decide, for each binding, if they want to define a default themselves (which would be consistent with the rest of their app) or if they want to honor the system bindings (and possibly have a terrible UX that people will complain about). It's not an easy problem :-).

bombcar 4y ago
You can override things like paste system-wide or you can customize it for a particular app.
- palata 4y ago
  Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults. Even for the obvious example of the text editor, where "everybody wants Ctrl+P to paste", where I precisely don't want that in vim and emacs. That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves (instead of reusing something I defined system-wide for different apps). Because the app developer knows their app better. If I don't like it, I can customize it or just not use it. "Don't use vim if you want it to behave like Word", in some sense. Both are great, but different. And that's fine.
  - throw10920 4y ago
    > The problem is that it makes it harder for the app to have sane defaults. How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use? > That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves The above system seems to fairly easily fit your preference - you can trivially choose to use the app bindings, and GP can trivially choose to use the system bindings. You're advocating for needlessly restricting user choice by using a design that doesn't allow them to pick between a unified set of system shortcuts (which I, and many other millions of people want) and each app doing it their own way (which is a UX disaster for new users).
    - palata 4y ago
      > You're advocating for needlessly restricting user choice Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance. > How is this not trivially solved [...] Well first you need to find a way to integrate that toggle in your UI without people complaining too much. Then you need to test that it works on your platform (I see a lot of room for errors, e.g. if the system default is not set, or set to something weird, or conflicting with another app), and then you need to make it work on other platforms (which most certainly won't provide a compatible API). Sounds easy, in practice nobody would want to pay for the work required to do it. That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
      - throw10920 4y ago
        > Nope, I'm advocating for letting the app developers do what they want. You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all: > Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults. That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model. Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion. > Well first you need to find a way to integrate that toggle in your UI without people complaining too much... ...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it) > That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app. Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread. Do you have anything actually relevant that you'd like to add?
torstenvl 4y ago
They're not enforced by technical means, usually, but Apple HIG are fairly highly regarded by developers and users alike. I only do UI programming in wxWidgets so I can't speak for other developer workflows. When I create a menu system, if I don't include accelerators manually, the system-appropriate ones are automatically added for certain things. Additionally, wxWidgets automatically moves Windows/Linux "standard" menu items to macOS-specific locations (e.g., Quit and About menu items), if and only if they're in the pertinent menus at the time they're added to the menu bar. If I add the File menu to the menu bar, and then add "E&xit" to the file menu, it still shows in the File menu. So, in my experience, it's a strong default, but it isn't constraining; you can easily override that behavior when necessary.
- palata 4y ago
  Yeah for UI it makes a lot of sense. Especially if those are "standalone" (for lack of a better word) elements. For instance, changing the accelerators (I guess that's related to the animation when opening a menu, right?) cannot really conflict with anything else. So it's perfect to use system-wide configurations like that. But I wonder about key bindings. I think it makes sense to have guidelines, and to use "Cmd + Q" to quit whenever it makes sense. But defining this as a high-level action "quit", and letting the user define the binding (e.g. "I want Cmd + S to quit") seems rather complicated to me. If "Cmd + S" is already set system-wide for the "save" action, then the system could tell you "that will disable the 'save' action, are you sure?". But if you go for "Quit with Cmd + J", and "Cmd + J" is not a system-wide binding but instead is used by... say... Blender. Then the system will happily change "Ctrl + Q" with "Ctrl + J", and now what happens if you hit "Ctrl + J" in Blender? Should it quit, or should it do what Blender does for "Ctrl + J"? I am not sure everything can be configurable. My Firefox toolbar is at the top, on mobile I can have it at the bottom (not sure I can do that on Desktop). But I can't have it in the middle of the page, or vertically on a side. That's a decision that was made by the Firefox devs, not by the system settings. That does not mean we should not expect sane defaults, but I would argue that ":q" is a sane default in vim.

bombcar 4y ago

macOS shortcut editing/configuration is an unsung strength of the platform; it’s quite amazing and anyone who uses macOS should spend an hour investigating it. Your past shortcut change is something I’ve done similarly but you can also assign shortcuts to menu commands that you use often but don’t have one, etc.