QScreen vs. KScreen in plasmashell

[Daniel Vratil]

Hi all,

the current state of multi-monitor support in Plasma 5 is rather bad as both 
Plasma 5 and KWin keep crashing every time there's any change (+ the desktop 
is extremely sluggish for about 15 seconds after that). Many colleagues in my 
office would love to switch to Plasma 5 already, but this is one of the major 
blockers that scares most people away, so it needs to be fixed.

I was looking into plasmashell code to fix it (and also for a different 
reason, more on that later) and realized that the code is mixing use of 
KScreen and QScreen, and I couldn't resist asking myself why. QScreen provides 
subset of information that KScreen and all I can see in the code is just 
endless conversion between QScreen and respective KScreen::Output and hoping 
they both behave the same. Would it make sense to get rid of QScreen 
completely and use KScreen exclusively? I think it would solve most of the 
crashes I'm currently getting. I'm of course volunteering to do all the work, 
but before I start, I want to make sure there's no real obscure reason for 
keeping both QScreen and KScreen.

Cheers,
Daniel

(For the "other reason I was looking into plasmashell": I'm currently working 
on a big KScreen API and design changes, which includes using QSharedPointers, 
having async API, and running platform backends in a separate process to 
improve performance and stability, but I'll send a separate email on that once 
the API is finished, as that will affect all KScreen-enabled applications)

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141024/6dd679ef/attachment.sig>