davidedmundson abandoned this revision.
davidedmundson added a comment.
I'm not particularly convinced by the arguments, but also don't care enough
to argue.
Might try solving this a different way at a later date.
REPOSITORY
R108 KWin
REVISION DETAIL
https://phabricator.kde.org/D7323
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 regardle
davidedmundson added a comment.
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.
graesslin added a comment.
In https://phabricator.kde.org/D7323#136066, @luebking wrote:
> 2¢ - you don't have to expose the cursor position for those effects, just a
signal that the cursor position changed and the ability to "do some" at the
"current" cursor position (which is then reso
luebking added a comment.
2¢ - you don't have to expose the cursor position for those effects, just a
signal that the cursor position changed and the ability to "do some" at the
"current" cursor position (which is then resolved by the core)
REPOSITORY
R108 KWin
REVISION DETAIL
https://p
graesslin added a subscriber: broulik.
graesslin added a comment.
Just some more thinking: if the aim is better trackmouse or mousemark
extending scripts or effects is the wrong approach. Ideally one would want to
use the DRM cursor layer for this. The big disadvantage of trackmouse currently
graesslin requested changes to this revision.
graesslin added a comment.
This revision now requires changes to proceed.
I'm very concerned about this from a security perspective. This would allow
to globally get notifications about the cursor positions and thus destroy one
of the design goals
graesslin added a comment.
In https://phabricator.kde.org/D7323#135959, @davidedmundson wrote:
> In retrospect, I don't even want cursor tracking - I was thinking of
mousePolling, but that no-ops here anyway.
KWin doesn't do mousePolling anymore in "normal" situations. On X11 with
davidedmundson added a comment.
In retrospect, I don't even want cursor tracking - that's for something else
entirely.
REPOSITORY
R108 KWin
REVISION DETAIL
https://phabricator.kde.org/D7323
To: davidedmundson, #plasma
Cc: anthonyfieroni, plasma-devel, kwin, #kwin, ZrenBot, progwolff, le
anthonyfieroni added inline comments.
INLINE COMMENTS
> cursorwrapper.cpp:29-30
> +{
> +connect(Cursor::self(), &Cursor::posChanged, this,
> &CursorWrapper::positionChanged);
> +Cursor::self()->startCursorTracking();
> +}
https://phabricator.kde.org/source/kwin/browse/master/cursor.cpp;
davidedmundson created this revision.
Restricted Application added a project: KWin.
Restricted Application added subscribers: KWin, kwin, plasma-devel.
REVISION SUMMARY
This allows us to write scripts like mousemark, trackmouse, etc. as
declarative scripts.
It's exposed as a new object ra
11 matches
Mail list logo
