Multi-Head configuration (Xrandr) -- potential bugs and improvements

I appreciate your work much Trinity TDE seems to be the only X11 desktop left providing enough functionality and configurability to support an ergonomic and powerful X11 GUI for me(FOOTNOTE{Usage}). And it is significantly improved over KDE 3.5! That said, nevertheless there are some kinks, one being the new Xrandr config interfaces in "control center -> system administration -> monitor & display" and the system tray "TDErandrtray" applet.(FOOTNOTE{Expertise offered}) These look very promising and I was quite excited -- until I discovered that they will not support my typical use cases(FOOTNOTE{Xrandr use cases}). === observations + problem description === 1. The screens are always snapped to each other in the control center module. If no edges overlap, the nearest corners snap together with no overlap, leading to both screens being handled independently (dual head / Zaphod mode). The panel remains unchanged and windows are maximized within their respective screen. ==> OK. But if edges overlap, these edges snap together with a few pixels overlap. The consequence is, that both screens are treated as one united screen: * the panel expands as its size is relative to full (virtual) screen width -- both ends of the panel might become invisible and the user is stuck (if not having a 'xterm' and knowledge of 'xrandr' ...), if the screen not bearing the panel is wider than the screen with panel ... * maximizing windows will maximize them over the joint screen area of both screens (while maybe a nice *option* for identical screens side-by-side or stacked, typically quite detrimental on 2 screens with different resolutions!) * it seems neither possible to separate screens nor to construct a cloning configuration with mouse-dragging (documentation is not available, so I might miss some hidden controls, but tried the usual suspects ...) ==> serious usability BUG (IMHO), as many useful screen configurations are precluded and the normal user might end up with a messed up GUI without any obvious way back ... Even if I hand-craft the display profiles according my needs, upon loading (both from the tray-applet and the control-center) they will be "corrected" and rendered useless -- with the exception of hand-crafted clone configurations (full and sub-set). Workaround are manual 'xrandr' cmds or 'arandr', but this is doing TDE disgrace, IMHO. 2. if the primary screen is below/right of the secondary screen, the secondary screen gets negative coordinates in the stored profile (to my knowledge not possible within X11). Upon loading this profile (both via control-center or TDErandrtray) the screen upper/left-most screen becomes the primary screen. --> serious BUG (as silently changing an accepted manual config IMHO is never OK) 3. automatic loading of display profiles is a very clever + useful addition, but at least in my typical use cases it would be advantageous if the profile loaded reacts to the specific monitors to detect a location via monitor and restore the optimal profile for this location. === proposals for bug fixes === * XRANDR control-center module (control center -> system administration -> monitor & display) ** must never change the primary screen attribute on its own ** must calculate X11 coords correctly for secondary screens left or above the primary screen and store them in profiles ** allows unconstrained placement of screens to enable clone and other useful configurations (either as default behavior or a modified, see next point) ** different snapping behavior is provided via modifiers or keys, e.g. SHFT+mouse-movement snaps with overlapping offsets, CTRL+mouse is either unconstrained or snaps abut (non-overlapping) === proposals for improvements === * XRANDR control-center module (control center -> system administration -> monitor & display) ** give some feedback on the actual coords and snapping (major usability improvement) ** indicate primary screen (e.g. by color as in "arandr") (medium usability improvement) ** option to add some "AutoStart" functionality to a profile, either by providing an input field for entering a command or shell script or by giving an AutoStart directory. Assuming that specific profiles constitute either specific operation modes or locations -- like "presentation" or "movie viewing" or "home" or "office" -- additional settings like switching power-scheme, configure proxies, etc. could be done (major functional improvement (for power users)) ** "arandr" uses "xrandr" command lines to store configuration and thus is able to load hand-crafted display profiles which instantiate xrandr-configs beyond 'arand' config capabilities (e.g. complex panning constructions as described in 'xrandr(1)') -- IMHO very powerful and useful = major functional improvement)! I see some possible approaches, the following might be the easiest: *** displaying the constructed "xrandr" command can serve as feedback of actual coords and snapping *** the user might copy this command to an input field and modify it or add further shell syntax (this would implement implicitely the profile "AutoStart"). This manual initiation command overrides the automatic setting. * automatic display profile loading of TDE XRANDR logic ** option to tie hotplug rules to specific monitors (either via the whole EDID blob or by extracting manufacturer+serial#) -- this would allow to detect a specific monitor and automagically restore e.g. home + office configs. (major functional improvement) * control-center -> desktop -> panel ** allow panel size to be given in pixels or percent (minor functional improvement) ** configuration option to tie the panel to the primary screen (it switches if the primary screen setting in the control center is changed) instead to a specific screen number, which is only available if 2 non-overlapping screens are configured ... (medium functional improvement) Best regards, ThoMaus FOOTNOTE{Expertise offered}: I can contribute in the following areas: * programming skills (hundred thousands LOCs in production quality in various programming languages, several thousand lines C (but not recently), -- but NO KDE-related programming so far) * bug hunting + killing * documentation (especially if the points raised above stem from me not finding functionality because of missing or misunderstood documentation ;-) * performance analysis + optimizing * security analysis + hardening * testing on some desktop + notebook systems, single+dual-headed So probably I can debug, sometimes modify code else hint where modification might be needed, and final test existing functionality -- if guided where to start. I probably can't introduce new GUI elements or functionality for lack of KDE/TDE framework skills. FOOTNOTE{Xrandr use cases}: 1. presentations via projector 1.1 the projection representing a completely logically separated screen 1.2 the projection screen being a subset-clone of the notebook screen, so I can use it as a view-port, concentrating e.g. on the inner part of a specific window 1.3 full cloning (typically on a monitor) 2. extended workspace 2.1 my home config with a large monitor (both in resolution and dimensions) sitting above the notebook LCD 2.2 spontaneous extensions elsewhere with monitors of whatever resolution and positioning FOOTNOTE{Environment}: OpenSuSE Tumbleweed on notebook single-headed + with varying dual-head configs repositories: * the recommended ones below http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse42.1/trini… * the official OpenSuSE LEAP 42.1 repositories as second-tier, enabling trinity to install older library versions -- so far without any collisions or failed dependencies FOOTNOTE{Usage}: Despite working with computers for near on 40 years, and using X11 30+ years, I managed to avoid RSI and other computer work induced problems so far very well. I attribute this to using all ergonomic advantages my X11 desktops provided since the early days of "olvwm", especially: * focus follows mouse + auto-raise (delays fine-tuned to my personal reaction) * B2 window style (automatically and dynamically reducing the width of window title bars, such creating a tabbed appearance, very useful with auto-focus) * consistent color scheme indicating active elements clearly (excellent visibility and discernability -> easier for eyes and perceptive workload) * panning (bound to a mouse key -- IMHO more ergonomic than scrolling, essentially with the key pressed, mouse movements scroll ...) * ... You mileage might vary, but a few days with KDE5 or even Cinnamon produced the first RSI inklings (and an impeded work-flow ...) and thus proved the effectiveness of my personal ergonomic approach