Change Details

We (Dorota from Purism, @mart, me) had some discussions at Plasma Mobile Sprint today about the question on how KWin should react to different input and output device classes. I'm looking for more feedback on our ideas. **Current state of affairs** * On Plasma Mobile we install a [[ https://cgit.kde.org/plasma-phone-settings.git/tree/etc/xdg/kwinrc | kwinrc config file ]], which controls KWin's behavior, for example that the window placement strategy should always be "Maximizing". * In KWin we have the TabletModeManager class. Its purpose is to inform clients via DBus about the current usage mode of convertibles. Kirigami uses this information for example to change the size of visual elements to allow easier touch control. **Goals** * Define a concept of determining and controlling the window placement and other window manager internal characteristic depending on current hardware and configuration. * Communicate the decision to interested clients. ##Solution proposal **KWin internal** * Define in KWin //usage patterns// describing the preferred way of arranging content and interacting with it. For example: //Desktop, Phone, Tablet, TV, VR, ...// * Set usage pattern //per output//. * Determine which usage pattern should be set on which output by evaluating information about the size of the output, the overall availability of input methods and manual system/user configuration. * Change window placement strategy, decoration visibility and other properties accordingly (should still be configurable, but //per// usage pattern). **Informing clients** * Define a Wayland protocol to inform interested clients //per surface//, when this surface changes output. Set enums describing the current usage pattern on the output. Enums could be: ** Directly named Desktop, Phone,... like the usage patterns ** Enums named Mouse, Touch, GameController, VRGoggles,... resembling real hardware. * Add new names in new protocol versions. * Solution 1: Send a single enum ** If client only supports older version, send the best fitting supported older enum as fallback. * Solution 2: Send a priority list of enum values ** Fallback is integrated directly. Clients should just ignore values in the list if they can't interpret it. ** By reading out multiple values, clients are able in theory to determine how best react to the usage pattern. * Solution 3: Send two enum values, one for input usage pattern and one for output usage pattern. ** Combinations like Phone + Touch / Phone + Keyboard or VRGoggles + Gloves / VRGoggles + KnuckleControllers are easily possible ** Might be redundant in certain cases: For example difference between Phone + Touch / Tablet + Touch is negligible client-side (in this example not with CSD).

We (Dorota from Purism, @mart, me) had some discussions at Plasma Mobile Sprint today about the question on how KWin should react to different input and output device classes. I'm looking for more feedback on our ideas. **Current state of affairs** * On Plasma Mobile we install a [[ https://cgit.kde.org/plasma-phone-settings.git/tree/etc/xdg/kwinrc | kwinrc config file ]], which controls KWin's behavior, for example that the window placement strategy should always be "Maximizing". * In KWin we have the TabletModeManager class. Its purpose is to inform clients via DBus about the current usage mode of convertibles. Kirigami uses this information for example to change the size of visual elements to allow easier touch control. **Goals** * Define a concept of determining and controlling the window placement and other window manager internal characteristic depending on current hardware and configuration. * Support multiple characteristics in the same session with different hardware devices (convergence). * Communicate the selected characteristic to interested clients. ##Solution proposal **KWin internal** * Define in KWin //usage patterns// describing the preferred way of arranging content and interacting with it. For example: //Desktop, Phone, Tablet, TV, VR, ...// * Set usage pattern //per output//. * Determine which usage pattern should be set on which output by evaluating information about the size of the output, the overall availability of input methods and manual system/user configuration. * Change window placement strategy, decoration visibility and other properties accordingly (should still be configurable, but //per// usage pattern). **Informing clients** * Define a Wayland protocol to inform interested clients //per surface//, when this surface changes output. Set enums describing the current usage pattern on the output. Enums could be: ** Directly named Desktop, Phone,... like the usage patterns ** Enums named Mouse, Touch, GameController, VRGoggles,... resembling real hardware. * Add new names in new protocol versions. * Solution 1: Send a single enum ** If client only supports older version, send the best fitting supported older enum as fallback. * Solution 2: Send a priority list of enum values ** Fallback is integrated directly. Clients should just ignore values in the list if they can't interpret it. ** By reading out multiple values, clients are able in theory to determine how best react to the usage pattern. * Solution 3: Send two enum values, one for input usage pattern and one for output usage pattern. ** Combinations like Phone + Touch / Phone + Keyboard or VRGoggles + Gloves / VRGoggles + KnuckleControllers are easily possible ** Might be redundant in certain cases: For example difference between Phone + Touch / Tablet + Touch is negligible client-side (in this example not with CSD).

We (Dorota from Purism, @mart, me) had some discussions at Plasma Mobile Sprint today about the question on how KWin should react to different input and output device classes. I'm looking for more feedback on our ideas. **Current state of affairs** * On Plasma Mobile we install a [[ https://cgit.kde.org/plasma-phone-settings.git/tree/etc/xdg/kwinrc | kwinrc config file ]], which controls KWin's behavior, for example that the window placement strategy should always be "Maximizing". * In KWin we have the TabletModeManager class. Its purpose is to inform clients via DBus about the current usage mode of convertibles. Kirigami uses this information for example to change the size of visual elements to allow easier touch control. **Goals** * Define a concept of determining and controlling the window placement and other window manager internal characteristic depending on current hardware and configuration. * Communicate the decisionSupport multiple characteristics in the same session with different hardware devices (convergence). * Communicate the selected characteristic to interested clients. ##Solution proposal **KWin internal** * Define in KWin //usage patterns// describing the preferred way of arranging content and interacting with it. For example: //Desktop, Phone, Tablet, TV, VR, ...// * Set usage pattern //per output//. * Determine which usage pattern should be set on which output by evaluating information about the size of the output, the overall availability of input methods and manual system/user configuration. * Change window placement strategy, decoration visibility and other properties accordingly (should still be configurable, but //per// usage pattern). **Informing clients** * Define a Wayland protocol to inform interested clients //per surface//, when this surface changes output. Set enums describing the current usage pattern on the output. Enums could be: ** Directly named Desktop, Phone,... like the usage patterns ** Enums named Mouse, Touch, GameController, VRGoggles,... resembling real hardware. * Add new names in new protocol versions. * Solution 1: Send a single enum ** If client only supports older version, send the best fitting supported older enum as fallback. * Solution 2: Send a priority list of enum values ** Fallback is integrated directly. Clients should just ignore values in the list if they can't interpret it. ** By reading out multiple values, clients are able in theory to determine how best react to the usage pattern. * Solution 3: Send two enum values, one for input usage pattern and one for output usage pattern. ** Combinations like Phone + Touch / Phone + Keyboard or VRGoggles + Gloves / VRGoggles + KnuckleControllers are easily possible ** Might be redundant in certain cases: For example difference between Phone + Touch / Tablet + Touch is negligible client-side (in this example not with CSD).