On Saturday 03 April 2010 21:04:33 Aaron J. Seigo wrote: > 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.
So, does that mean that Kephal would have to have backends to follow xrandr changing API ? Is the current Kephal API correct ? I never created an API :-) What Aike said seems ok but it has to be well documented so people don't mix everything up. A Screen might not feel like what it represents in xrandr but how would you name that ? I think about a "Desktop" and you could put your Desktop on multiple Outputs (Not Screen, a beamer's not really a Screen) > > 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. That's what I would have called an Output. > 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 thought you meant that it was the way Kephal currently works when you wrote "(which is what we have right now)" Detlev.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel