3 ms·

> 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 binding

> 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?
  - palata 4y ago
    I think we're talking past each other. I'm not trying to win an argument, I'm just sharing my opinion. I reacted to that: > Not having system wide keyboard shortcuts is one of [those big mistakes]: vim, emacs, nano etc all have a different shortcut to quit the app In my opinion (and that's an opinion, not a formal proof), this does not work. _I do not want the same shortcut to quit nano, vim and emacs_. The author of that comment does, obviously. Which is why I said "preferably the standard should be your favourite shortcuts, right?". Not as a criticism, but in order to show that this is a preference, and my preference differs from the author's. My preference is to have vim bindings be vim bindings, and not the system bindings. Sure, the system settings could offer a way to specifically set the bindings for vim instead of using the `.vimrc`. But it would not entirely replace `vimrc`, so it would split the config in what _I see_ as a weird way. I generally don't see how it would work in practice. I can easily swap "ESC" and "CapsLock" in the system settings, but that's not the same level as setting the shortcut for a high-level action like "save". If you want to set the "save" shortcut globally, then everyone writing a program has to deal with it. First, I don't see how you can enforce it. And second, it makes life harder for developers. For something _I don't personally want_. Therefore as a developer, I won't follow your preference, period. This is my opinion about the hypothetical idea of having system-wide settings that would unify vim, emacs and nano (that's the point of the sentence above, isn't it?). Maybe someone can implement this in a perfect way, and I would even use it (who doesn't like "perfect"?). But it _feels_ like I fundamentally disagree: _to me_, the fact that vim, emacs and nano all have a different way to quit the app is a feature, not a bug. Therefore it does not need fixing. But feel free to explain to me what I am trying to say, and why it is logically wrong.

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?
- palata 4y ago
  I think we're talking past each other. I'm not trying to win an argument, I'm just sharing my opinion. I reacted to that: > Not having system wide keyboard shortcuts is one of [those big mistakes]: vim, emacs, nano etc all have a different shortcut to quit the app In my opinion (and that's an opinion, not a formal proof), this does not work. _I do not want the same shortcut to quit nano, vim and emacs_. The author of that comment does, obviously. Which is why I said "preferably the standard should be your favourite shortcuts, right?". Not as a criticism, but in order to show that this is a preference, and my preference differs from the author's. My preference is to have vim bindings be vim bindings, and not the system bindings. Sure, the system settings could offer a way to specifically set the bindings for vim instead of using the `.vimrc`. But it would not entirely replace `vimrc`, so it would split the config in what _I see_ as a weird way. I generally don't see how it would work in practice. I can easily swap "ESC" and "CapsLock" in the system settings, but that's not the same level as setting the shortcut for a high-level action like "save". If you want to set the "save" shortcut globally, then everyone writing a program has to deal with it. First, I don't see how you can enforce it. And second, it makes life harder for developers. For something _I don't personally want_. Therefore as a developer, I won't follow your preference, period. This is my opinion about the hypothetical idea of having system-wide settings that would unify vim, emacs and nano (that's the point of the sentence above, isn't it?). Maybe someone can implement this in a perfect way, and I would even use it (who doesn't like "perfect"?). But it _feels_ like I fundamentally disagree: _to me_, the fact that vim, emacs and nano all have a different way to quit the app is a feature, not a bug. Therefore it does not need fixing. But feel free to explain to me what I am trying to say, and why it is logically wrong.