4 ms·

Why would a widget library need to deal with input stack directly? For portability it'd provide an API where the caller will dispatch abstract events such as mo

Why would a widget library need to deal with input stack directly? For portability it'd provide an API where the caller will dispatch abstract events such as mouse events and keyboard events and already translated character events.

cmrdporcupine 5y ago
If you think it's easy to make an abstraction around keyboard events, stroll through the Chromium and Blink source tree some time and try to understand all the nuances. Keyboard and key event input is much harder than it first appears. From multiple platforms to multiple languages to multiple keyboard interface devices to multiple layouts, and you cannot assume that the operating system provides a workable abstraction on its own.
- ensiferum 5y ago
  Not sure if that's an apples to apples comparison. Generally speaking a widget library should be able to provide and interface for taking the keyboard input. It doesn't need to interface with the OS for this. The caller does and uses for example an IME or the native OS API to receive the os level input. I have in fact written widget libraries this way. Just wondering if I didn't hit some ude case that would require the widget to rely on some input system directly.
  - nybble41 5y ago
    If you're implementing a text input widget then your widget needs to interact with the platform IME. It doesn't just receive text to append to the buffer in response to key presses. The IME may be context-sensitive and thus need access to the existing text, it may replace previously entered text, it may want to display a pop-up (e.g. a list of candidates) near the cursor position. These things require interfacing with the OS, and the underlying data model varies for each platform.
    - ensiferum 5y ago
      And what makes you think the widget can't give this information to the user of the library which would Then invoke the IME/whatever input system and give the result back to the widget in an platform independent input/character event? // pseudo-interface class TextWidget { ... WidgetEvent HandleMouseEvent(const MouseEvent& m, ...); WidgetEvent HandleKeyboardEvent(const KeyboardEvent& k, ...), WidgetEvent InputEvent(const InputEvent& i, ...); }; // client code. PlatformMsg msg; while (GetMessage(&msg, ...)) { WidgetEvent event; if (IsKeyboard(msg)) { event=widgets.DispatchEvent(MapKeyboardMsg(msg),...); } ... { if (NeedsIMEInput(event)) { OpenIME(ExtractDetails(event)); } } The client application interfaces with the native/platform/synthesizer API/wrapper library to read/generate events from apps message queue/script/internet/whatever and maps those into platform agonistic events supported by the widget library and dispatches them into the library where the library decides which widget will receive them etc. The widget will react to the event and in the case of the text input widget will return back an event with the relevant information for invoking some IME system (in this example). The client code interfaces again with the native/platform/synthesizer to do what is asked and then dispatches the result back to the widget which will update its state. This design will basically have the same functionality but will split the responsibilities so that the widget system would not depend on the input system. This allows the two to vary independently and remain agnostic of each other thus promoting reuse and testing and simplifying the implementation (IMHO). The question is not about how to invoke some IME, it's about how to separate these concerns and de-couple the widget system from the input system by delegating the invocation (and required details) to somewhere else. I don't see any real reason that warrants tight coupling.
      - cmrdporcupine 5y ago
        You've simply moved the problem. Someone ends up having to take responsibility for managing virtual keyboards, internationalization, layouts, etc., and now you've given the chance for every user of the library to do it differently.

cmrdporcupine 5y ago

If you think it's easy to make an abstraction around keyboard events, stroll through the Chromium and Blink source tree some time and try to understand all the nuances. Keyboard and key event input is much harder than it first appears. From multiple platforms to multiple languages to multiple keyboard interface devices to multiple layouts, and you cannot assume that the operating system provides a workable abstraction on its own.

ensiferum 5y ago
Not sure if that's an apples to apples comparison. Generally speaking a widget library should be able to provide and interface for taking the keyboard input. It doesn't need to interface with the OS for this. The caller does and uses for example an IME or the native OS API to receive the os level input. I have in fact written widget libraries this way. Just wondering if I didn't hit some ude case that would require the widget to rely on some input system directly.
- nybble41 5y ago
  If you're implementing a text input widget then your widget needs to interact with the platform IME. It doesn't just receive text to append to the buffer in response to key presses. The IME may be context-sensitive and thus need access to the existing text, it may replace previously entered text, it may want to display a pop-up (e.g. a list of candidates) near the cursor position. These things require interfacing with the OS, and the underlying data model varies for each platform.
  - ensiferum 5y ago
    And what makes you think the widget can't give this information to the user of the library which would Then invoke the IME/whatever input system and give the result back to the widget in an platform independent input/character event? // pseudo-interface class TextWidget { ... WidgetEvent HandleMouseEvent(const MouseEvent& m, ...); WidgetEvent HandleKeyboardEvent(const KeyboardEvent& k, ...), WidgetEvent InputEvent(const InputEvent& i, ...); }; // client code. PlatformMsg msg; while (GetMessage(&msg, ...)) { WidgetEvent event; if (IsKeyboard(msg)) { event=widgets.DispatchEvent(MapKeyboardMsg(msg),...); } ... { if (NeedsIMEInput(event)) { OpenIME(ExtractDetails(event)); } } The client application interfaces with the native/platform/synthesizer API/wrapper library to read/generate events from apps message queue/script/internet/whatever and maps those into platform agonistic events supported by the widget library and dispatches them into the library where the library decides which widget will receive them etc. The widget will react to the event and in the case of the text input widget will return back an event with the relevant information for invoking some IME system (in this example). The client code interfaces again with the native/platform/synthesizer to do what is asked and then dispatches the result back to the widget which will update its state. This design will basically have the same functionality but will split the responsibilities so that the widget system would not depend on the input system. This allows the two to vary independently and remain agnostic of each other thus promoting reuse and testing and simplifying the implementation (IMHO). The question is not about how to invoke some IME, it's about how to separate these concerns and de-couple the widget system from the input system by delegating the invocation (and required details) to somewhere else. I don't see any real reason that warrants tight coupling.
    - cmrdporcupine 5y ago
      You've simply moved the problem. Someone ends up having to take responsibility for managing virtual keyboards, internationalization, layouts, etc., and now you've given the chance for every user of the library to do it differently.