4 ms·

I like how the abstraction point is at LCD. It's abstracting a specific hardware type, not a hardware feature.

clarry 7y ago
And this is why we still have lots of applications where it's difficult or impossible to bind certain inputs. Someone had a mental image of a typical keyboard, then a typical mouse, and that's what we're stuck with. It's not like the sixth thumb button in my mouse is very different from the Print Screen key on my keyboard or the X button in my wireless gamepad. And that's why tools that make your input device X emulate a different type of input device Y are common (but annoying to set up since the setup is going to be application specific). I'm not aware of a single API that offers a sufficiently device-agnostic view of inputs that you can write the application code once and then let the user bind anything they can connect to their computer somehow. The USB spec actually comes close since it starts at the actual hardware inputs (toggle switch, button, relative motion, absolute motion, etc.) and their range, and then offers hints about their intended usage or meaning. It's the layers above that suck.
- mmis1000 7y ago
  I'm not aware of a single API that offers a sufficiently device-agnostic It looks like the goal of `Steam Controller Configurator` project by steam is doing this. (I think this should be done by a systeam level app instead.. but no one is doing this) The configurator api steam provides actually abstract the `real input device layout` away from the `the action user want to do`, which allows games to support `future` input device. The game itself longer needs to handle every input device layout one by one. Instead, it will have a general way to handle unknown device. The Configurator ask the game `which action you can do?` and the game response the actions (like jump, walk, sprint ...etc) to the api, and let the api bind the action to whatever key properly on the device(x on xbox one, square on ps4...etc).
  - clarry 7y ago
    I haven't used that thing but if it is as you say, it sounds backwards and very rigid, and probably only good for games (with assumptions about how the application might want to use inputs). I don't think system level APIs should ask applications anything at all. Applications should be able to ask for inputs instead. Which is the status quo, with the caveat that there's no unified "input" API, instead there's a bunch of different APIs for keyboard, mouse, joystick, xinput gamepad, text input, midi, other kinds of input (lucky if you can find an existing API for them...). Some of these APIs multiplex a few different types of inputs, but still provide them as distinct types of events that need to be handled separately by each application.
    - mmis1000 7y ago
      Then your program failed completely on the input device currently does not exist. How do your program know there is a controller use [w] as confirm instead of [o] when the controller does not even exist when you are writing the program? Although the new controller can just send [w] as [o], you will now have another problem that ui always ask you to press [o] when there is only [w] on the controller. Fix this problem is the sole purpose of that configurator. Don't choose the layout, just let user/system choose them. Although you could still define some preset for known device.

And this is why we still have lots of applications where it's difficult or impossible to bind certain inputs. Someone had a mental image of a typical keyboard, then a typical mouse, and that's what we're stuck with. It's not like the sixth thumb button in my mouse is very different from the Print Screen key on my keyboard or the X button in my wireless gamepad. And that's why tools that make your input device X emulate a different type of input device Y are common (but annoying to set up since the setup is going to be application specific). I'm not aware of a single API that offers a sufficiently device-agnostic view of inputs that you can write the application code once and then let the user bind anything they can connect to their computer somehow. The USB spec actually comes close since it starts at the actual hardware inputs (toggle switch, button, relative motion, absolute motion, etc.) and their range, and then offers hints about their intended usage or meaning. It's the layers above that suck.

mmis1000 7y ago
I'm not aware of a single API that offers a sufficiently device-agnostic It looks like the goal of `Steam Controller Configurator` project by steam is doing this. (I think this should be done by a systeam level app instead.. but no one is doing this) The configurator api steam provides actually abstract the `real input device layout` away from the `the action user want to do`, which allows games to support `future` input device. The game itself longer needs to handle every input device layout one by one. Instead, it will have a general way to handle unknown device. The Configurator ask the game `which action you can do?` and the game response the actions (like jump, walk, sprint ...etc) to the api, and let the api bind the action to whatever key properly on the device(x on xbox one, square on ps4...etc).
- clarry 7y ago
  I haven't used that thing but if it is as you say, it sounds backwards and very rigid, and probably only good for games (with assumptions about how the application might want to use inputs). I don't think system level APIs should ask applications anything at all. Applications should be able to ask for inputs instead. Which is the status quo, with the caveat that there's no unified "input" API, instead there's a bunch of different APIs for keyboard, mouse, joystick, xinput gamepad, text input, midi, other kinds of input (lucky if you can find an existing API for them...). Some of these APIs multiplex a few different types of inputs, but still provide them as distinct types of events that need to be handled separately by each application.
  - mmis1000 7y ago
    Then your program failed completely on the input device currently does not exist. How do your program know there is a controller use [w] as confirm instead of [o] when the controller does not even exist when you are writing the program? Although the new controller can just send [w] as [o], you will now have another problem that ui always ask you to press [o] when there is only [w] on the controller. Fix this problem is the sole purpose of that configurator. Don't choose the layout, just let user/system choose them. Although you could still define some preset for known device.