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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
