input-method: suggestion for activation sources and method types

Hello, I've been using the input-method protocol for some time now and noticed a few problems that I think my suggestions could solve.

Problem 1

Only 1 input-method can be active which means on-screen keyboards and input-methods must be the same client. I believe that it should be possible to create an input-method which can be an on-screen keyboard or a regular input-method or both.

Problem 2

The input-method client has no sense of "why" the input-method was activated beyond "being needed". This makes it more difficult to design on-screen keyboards. I hope that an on-screen keyboard could be shown based on if it is needed. Some examples of that would be to check if the activation "source" was a touchscreen event or if it came from a mouse button.

Solution to Problem 1

My solution to the first problem is the idea of "input-method types" this could either be a method (type) or an extra argument to the get_input_method which tells the compositor what kind of input-method is being registered. This would be a bitwise set of flags which can be either on-screen-keyboard or alternative-typing.

The on-screen-keyboard type would be obviously for on-screen keyboards like Squeekboard. This would allow for the compositor to distinguish that the client is used for displaying some sort of surface which is responsible for handling that kind of input.

The alternative-typing type would be for services like IBus, fcitx5, etc.

Solution to Problem 2

My solution to the second problem is the idea of activation "sources". This would be an argument added to the activation event which is a flag to determine where the activation is coming from. If none could be determined, it is likely that an explicit source could be defined. There would also be three other sources which tells why the input-method was activated, this would be: keyboard, mouse, and touch.