D7323: Expose Cursor position to DeclarativeScripting

[Martin Flöser]

graesslin added a comment.


  In https://phabricator.kde.org/D7323#136114, @davidedmundson wrote:
  
  > 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.
  
  
  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.
  
  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.
  
  > I could write my thing as C++, but I was very much under the impression you wanted to move scripts away from that?
  > 
  >> If you want to do these effects in a scripted approach we need to extend the scripting API.
  > 
  > That's what I am doing...unless scripting API and the declarative scripting API are conceptually different?
  
  We have three APIs:
  
  - effects (QScript based)
  - kwin scripts (QScript based)
  - kwin declarative scripts
  
  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.
  
  > 
  > 
  >> Something something planes
  > 
  > 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.
  
  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.
  
  > 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.
  > 
  > 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.
  
  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).

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D7323

To: davidedmundson, #plasma, graesslin
Cc: luebking, broulik, graesslin, anthonyfieroni, plasma-devel, kwin, #kwin, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart, lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170816/5704e09f/attachment.html>