[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Re: Ksshaskpass ?
From:       Jeremy Whiting <jpwhiting () kde ! org>
Date:       2014-12-14 12:52:51
Message-ID: CADWV2K5QWmhrT-Lm3rjJTfGFMt-zPp3SbVv4gMofK6qP8kAWYg () mail ! gmail ! com
[Download RAW message or body]

Martin, Thomas,

Is the implementation of InputGuard at
https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1d=
c1986f
with
https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be8f2=
e8034a
complete then? should we copy that into kwidgetsaddons and use it in
kpassworddialog? If so I'll do that and post a review request, I don't
quite follow all the discussion on this thread so wanted to be sure that
implementation is complete before doing so.

thanks,
Jeremy

On Fri, Dec 12, 2014 at 2:56 PM, Martin Gr=C3=A4=C3=9Flin <mgraesslin@kde.o=
rg> wrote:

> On Friday 12 December 2014 16:11:25 Thomas L=C3=BCbking wrote:
> > On Freitag, 12. Dezember 2014 08:00:45 CEST, Martin Gr=C3=A4=C3=9Flin w=
rote:
> > > I'd suggest to do a platform check as on Wayland it cannot work
> > > (grab keyboard fails).
> >
> > You're certainly right in that the guarding is entirely superfluous on
> > wayland, but grabbing still "works". Despite the platform window
> > ::setKeyboardGrabEnabled() returns false for wayland, QWidget simply
> > ignores that and assigns the grabber.
>
> oh that's much better than I thought. I only knew that the QPA prints out
> warnings like "not supported" so I expected that code would just break.
>
> >
> > What's worse: looking up the Qt code, QWidget only maintains the grabbe=
r
> as
> > static variable, the grabbing state is never re-tested.
> >
> > Eeeewww... this is gonna be more complex, I fear.
>
> Maybe one could say that misconfiguring the X-Server is out of scope. So =
if
> it's grabbed it's assumed to stay grabbed.
>
> >
> > I wonder whether the grabbing state can actually be tested except by
> > approaching a grab from a sidearm process. In doubt, the only possible
> > hardening would be to continuously - and the only test whether it worke=
d
> > would be to invoke QWindow::setMouseGrabEnabled(bool grab) as well.
>
> QWindow::setMouseGrabEnabled should be fine. The QXcbWindow implementatio=
n
> looks properly to me, like actually checking whether the grab succeeded.
>
> >
> > Stay tuned ;-)
> >
> > Cheers,
> > Thomas
>

[Attachment #3 (text/html)]

<div dir="ltr">Martin, Thomas,<div><br></div><div>Is the implementation of InputGuard \
at  <a href="https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f \
1dc1986f">https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1dc1986f</a> \
with <a href="https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be \
8f2e8034a">https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be8f2e8034a</a> \
complete then? should we copy that into kwidgetsaddons and use it in kpassworddialog? \
If so I&#39;ll do that and post a review request, I don&#39;t quite follow all the \
discussion on this thread so wanted to be sure that implementation is complete before \
doing so.</div><div><br></div><div>thanks,</div><div>Jeremy</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 2:56 PM, \
Martin Gräßlin <span dir="ltr">&lt;<a href="mailto:mgraesslin@kde.org" \
target="_blank">mgraesslin@kde.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Friday 12 December 2014 16:11:25 Thomas \
Lübking wrote:<br> &gt; On Freitag, 12. Dezember 2014 08:00:45 CEST, Martin \
Gräßlin wrote:<br> &gt; &gt; I&#39;d suggest to do a platform check as on Wayland \
it cannot work<br> &gt; &gt; (grab keyboard fails).<br>
&gt;<br>
&gt; You&#39;re certainly right in that the guarding is entirely superfluous on<br>
&gt; wayland, but grabbing still &quot;works&quot;. Despite the platform window<br>
&gt; ::setKeyboardGrabEnabled() returns false for wayland, QWidget simply<br>
&gt; ignores that and assigns the grabber.<br>
<br>
</span>oh that&#39;s much better than I thought. I only knew that the QPA prints \
out<br> warnings like &quot;not supported&quot; so I expected that code would just \
break.<br> <span class=""><br>
&gt;<br>
&gt; What&#39;s worse: looking up the Qt code, QWidget only maintains the grabber \
as<br> &gt; static variable, the grabbing state is never re-tested.<br>
&gt;<br>
&gt; Eeeewww... this is gonna be more complex, I fear.<br>
<br>
</span>Maybe one could say that misconfiguring the X-Server is out of scope. So \
if<br> it&#39;s grabbed it&#39;s assumed to stay grabbed.<br>
<span class=""><br>
&gt;<br>
&gt; I wonder whether the grabbing state can actually be tested except by<br>
&gt; approaching a grab from a sidearm process. In doubt, the only possible<br>
&gt; hardening would be to continuously - and the only test whether it worked<br>
&gt; would be to invoke QWindow::setMouseGrabEnabled(bool grab) as well.<br>
<br>
</span>QWindow::setMouseGrabEnabled should be fine. The QXcbWindow implementation<br>
looks properly to me, like actually checking whether the grab succeeded.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; Stay tuned ;-)<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Thomas<br>
</div></div></blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic