https://bugs.kde.org/show_bug.cgi?id=15329
--- Comment #167 from Me <[email protected]> --- I just realized that Plasma 6.6.7 is going to allow per display virutal desktops. 1. How will per-display virtual desktops be represented internally? Does KWin treat them as: - one global desktop model plus per-output active desktop selection, or - separate desktop sets per output? 2. What exactly must be persisted for restore? Is the saved state now: - window -> output + desktop - or window -> workspace topology object of some kind? 3. What output identity is considered stable enough for restore? Should restore use: - connector name like DP-1 - EDID-based monitor identity - a KWin internal output UUID - something else 4. If the original monitor is missing, what is the fallback policy? For example: - same desktop number on the primary monitor - current monitor and current desktop - nearest surviving output - same logical position if possible 5. If the monitor layout changes, which state has priority? If KWin cannot satisfy both: - original output - original per-output desktop - original geometry which one should win? 6. Are per-display desktops globally named or output-local? If a window was on “desktop 3” on monitor B, is that desktop identity meaningful without monitor B? 7. Can restored windows move across outputs during fallback? If so, under what rules? 8. What happens if the number of per-display desktops changes between sessions? For example, a window was on desktop 5 of monitor 2, but that monitor now only has 4 desktops. 9. How do activities interact with per-display desktop restore? If activities remain part of the model, restore semantics could become: - activity - output - per-output desktop 10. What is the intended behavior for multi-monitor browser sessions? If Firefox or Brave had multiple windows spread across outputs and desktops, what app-side identity does KWin need to restore them correctly? 11. Will the current session-restore protocol need any KDE-specific extension for per-display desktop restore? Or is this entirely compositor-side policy once KWin has stable window identity? 12. What should testers validate once per-display desktops land? Ask for a concrete matrix such as: - one window, two monitors - multiple windows across outputs - dock/undock between sessions - missing monitor on restore - renamed/reordered outputs - mixed XWayland/native Wayland apps Thanks -- You are receiving this mail because: You are watching all bug changes.
