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/trinity-r14/
* 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