GSoC : Multiscreen management

[Detlev Casanova]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100404/7140af94/attachment.sig