<table><tr><td style="">graesslin added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7323" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D7323#136114" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;" rel="noreferrer">D7323#136114</a>, <a href="https://phabricator.kde.org/p/davidedmundson/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;" rel="noreferrer">@davidedmundson</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>Security in scripts/effects is an existing problem, Scripts already can do literally anything, from manipulating workspace windows to low level DBus calls...as kwin. It needs solving regardless at a much higher level than restricting what API is available.</p></div>
</blockquote>
<p>Only partially. E.g. Wayland windows are not exposed to scripting for security concerns. So scripting currently only allows X11 which does not reduce the overall security.</p>
<p>Yes it needs a better solution, but a few years ago I decided to not expose anything Wayland related till we have a solution in place.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>I could write my thing as C++, but I was very much under the impression you wanted to move scripts away from that?</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>If you want to do these effects in a scripted approach we need to extend the scripting API.</p></blockquote>
<p>That's what I am doing...unless scripting API and the declarative scripting API are conceptually different?</p></blockquote>
<p>We have three APIs:</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">effects (QScript based)</li>
<li class="remarkup-list-item">kwin scripts (QScript based)</li>
<li class="remarkup-list-item">kwin declarative scripts</li>
</ul>
<p>The latter two are the same thing with different languages, the first one is a different beast. Effects cannot use QML. Code wise the effect scripts live in effects/ subdir, the two scripted in scripts/ subdir.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;">
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Something something planes</p></blockquote>
<p>This is something I want to to do too. But declarative and using planes aren't in any way exclusive. A DRM buffer still needs content from somewhere.</p></blockquote>
<p>True, but we need to get the content. If it's done by QtQuick we don't get the content (c.f. in Aurorae we do an expensive to QImage copy, for normal QWindows (on Wayland) we use an FBO which we cannot share at all with the DRM buffer). If we have the data as QImage we can relatively easy get it into a DRM layer, even if we do it in OpenGL not using QtQuick we could get it into a layer (with some serious engeneering work). Just with QtQuick - well difficult.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>For the thing I was doing (some obscure accessibility thing for someone) the cursor plane wouldn't really work. Nor for mousemark, where the content remains static.</p>
<p>Given how many effects are simply overlays - having platforms provide a plane for all overlays (with some compositior fallback) is something that IMHO would make sense, that I would happily work on. I don't think throwing it into the DRM backend itself is a system that will scale.</p></blockquote>
<p>Nah, of course not everything in DRM platform plugin. An abstraction which would allow to move it to into the platform is what we need. E.g. like we can do software rendering of cursor or doing it in the platform. Or the invert of screen which can either be done by an effect or through the platform (except it's in core).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7323" rel="noreferrer">https://phabricator.kde.org/D7323</a></div></div><br /><div><strong>To: </strong>davidedmundson, Plasma, graesslin<br /><strong>Cc: </strong>luebking, broulik, graesslin, anthonyfieroni, plasma-devel, kwin, KWin, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, lukas<br /></div>