GSoC : Multiscreen management

[Aaron J. Seigo]

On April 2, 2010, Will Stephenson wrote:
> Björn's description matches the xrandr model, but not the Kephal one. 
> Xrandr 1.3 has a single Screen numbered 0 but does not support additional
> Screens; xrandr Screens are distinct from the screennumber in X's
> $DISPLAY, and multiple Screen support is being discussed again for xrandr
> 1.4 according to one of our local Xorg guys.

while i have respect for the low level work that goes on in xrandr, i have no 
respect for their inability to create an API that is reliable and usable by 
application developers.

they have changed definitions and even behaviours so many times with no 
compatibility efforts or warning often enough, and the makes-sense-to-driver-
writers-but-is-incomprehensible-to-app-developers naming systems combines with 
that to lead me to concluce that there is no point or purpose in trying to 
track xrandr's terminology in our application facing API.

that, really, should be the role of Kephal: to provide a sensible naming 
scheme, an API that does not jump around every N months underneath us and 
which is easy to use. so we only should care about how xrandr (and other 
systems, should we care to :) mates up with Kephal, and to ensure that Kephal 
gets that right.
 
> Kephal has both multiple Outputs and multiple Screens in its model.  A

the definition of "Screen" is different between xrandr and Kephal. Kephal uses 
it to mean what app develpers think it means: it's a part of the whole output 
geometry that the user percieves as one screen.

everything else, for an application like plasma or kwin, is a detail.


so, where this gets tricky is when we want to build a tool which allows the 
user to configure how the xrandr outputs/screens are configured. Kephal needs 
to allow this to happen (perhaps even throught a separate "Controller" API?) 
and the tool needs to be written for mortal users not xrandr developers. the 
nice thing about making the configuration tool use Kephal is it will put the 
developer in the right mindset and not get sucked into xrandr's accurate but 
useless for creating usable interfaces model (which is what we have right 
now).

i'm not sure (have to look at it again) how much work will be needed in Kephal 
to get this going. i do know that there is already one such plasmoid out there 
that does screen configuration more elegantly than what we currently have, but 
i think it is also using xrandr directly atm?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks