RFC: Moving KWallet Password dialog into Plasma

Martin Gräßlin mgraesslin at kde.org
Fri Jul 20 19:46:02 BST 2012


On Friday 20 July 2012 18:25:15 David Edmundson wrote:
> On Fri, Jul 20, 2012 at 4:58 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> > Hi all,
> > 
> > the problems around review request #105628 and getting KWallet's Password
> > dialog properly raised above the window it is asking the password for just
> > triggered a thought process.
> > 
> > The main problem here is that $service ask for a password through
> > $otherservice. This utterly fails because the $service is not linked
> > directly to a window which the window manager would need to properly
> > stack the window.
> > 
> > Now if we think about it in most cases $service is actually a "system"
> > service which can be considered belonging to the workspace. E.g. checking
> > for mail, logging into your telepathy account and so on.
> > 
> > Providing a password safe and asking for the master password is also a
> > "system" service and should belong into the workspace.
> > 
> > So here my idea: let's move the password dialog into the desktop shell.
> > Have it as a so-called "persistent" notification popping out of the panel
> > and be shown on top of all other windows till the user either dismisses
> > it or enters the password.
> > 
> > I think this would solve most of our current issues. There would be one
> > place where the dialog is shown to ask for the password, it is visually
> > clear that it's a system service which asks for the password and not some
> > random malware and if several applications want to open the wallet this
> > problem is also nicely solved by e.g. saying "Mail Dispatcher Agent and
> > Telepathy need to unlock the wallet".
> > 
> > So what do you think?
> 
> This problem also applies to Authkit/Polkit prompts as well as
> Telepathy windows (from personal experience) and anything else
> dbus-activated.
For polkit and telepathy it should be possible to set the correct transient 
window, so that the window manager knows they belong to a different 
application.

For polkit I would even be fine with adding a special mode in KWin, if we 
would want to have something like nag screens as in UAC in windows.
> Dbus-activated apps being launched are (probably) going to be even
> more common in the future, and we'll see this problem in many more
> places.
> 
> "Fixing" kwallet by moving it into a different place will fix it in
> this one instance, but it's simply avoiding the problem that will come
> back again.
Each of these problems have to be fixed independently and best is to design 
the API with having this usecase in mind (e.g. add the window ID for the 
dialog window). But there cannot be a generic solution to all different use 
cases. The only solution is to disable focus stealing prevention. You can do 
that, but don't complain if your password ends up in #kde-devel of your IRC 
client ;-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120720/35eba49c/attachment.sig>


More information about the kde-core-devel mailing list