Review Request: KWallet Password Prompt Dialog In Your Face

[Allen Winter]

> On July 20, 2012, 2:15 p.m., Martin Gräßlin wrote:
> >

So I don't know much about window managers and stuff.. what I want is to make sure that no matter what the prompt dialog is in the user's face and can't be dismissed.

The worst case I've found is when the akonadi mail dispatcher needs to open the wallet.  the prompt dialog for that has been hidden in some cases.. and can also be stacked below kmail or minimized.  when that happens the user sees their message sitting in their outbox forever (since the mail dispatcher is waiting for kwallet to return)


> On July 20, 2012, 2:15 p.m., Martin Gräßlin wrote:
> > kwalletd/kwalletd.cpp, line 361
> > <http://git.reviewboard.kde.org/r/105628/diff/1/?file=73793#file73793line361>
> >
> >     from API docs: "The usage of forceActiveWindow() is meant only for pagers and similar tools, which represent direct user actions related to window manipulation. Except for rare cases, this request will be always honored, and normal applications are forbidden to use it."
> >     
> >     I do not see that this is a pager or a taskbar. This means forceActiveWindow is the wrong way to do it.
> >     
> >     The way it is done here is an example of how to do a nag window. Please make it just a transient to the window it belongs to. KWin should take care of presenting it correctly. It is nothing which has to be above everything else. If we want that we should do it correctly, that is really block till the user entered the password. But in general I'm against windows behaving like that. It would make it very difficult for users to figure out what's going on and I think it's a very bad idea to ask for passwords in a nag window way as long as we have "kded asks for password". Yeah right, what's kded again?
> 
> Thomas Lübking wrote:
>     There're two issues here
>     a) they don't know the main window
>     b) it can happen that the wallet password dialog is invoked by two applications at the same time and you can't have one dialog transient for two main windows (for good reason, btw - that's never gonna be "fixed")
>     
>     So tasks are:
>     a) figure the mainwindow for daemons (hard enough - what if some plasmoid & kmail access akonadi?)
>     b) figure to which one the transient should be applied if there's multiple kwalled access
>     
>     Optionally: question whether the triggered invocation is an ideal approach at all (-> single login, seems heftily demanded)

forceActiveWindow() has always been there.  my patch did not change that.
I added unminimize and setUserTime (and demandsattention)


- Allen


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105628/#review16158
-----------------------------------------------------------


On July 20, 2012, 1:41 p.m., Allen Winter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105628/
> -----------------------------------------------------------
> 
> (Updated July 20, 2012, 1:41 p.m.)
> 
> 
> Review request for KDE Runtime, David Faure and Fredrik Höglund.
> 
> 
> Description
> -------
> 
> This is an attempt to make the KWallet password prompt much harder to ignore or miss.
> 
> Now the prompt should always be in front of the parent window. and it should unminimize if needed, and demand attention.
> 
> 
> Diffs
> -----
> 
>   kwalletd/kwalletd.cpp 309c45f 
> 
> Diff: http://git.reviewboard.kde.org/r/105628/diff/
> 
> 
> Testing
> -------
> 
> Just using it in various scenarios.
> For example, if the akonadi maildispatcher needs to open kwallet now the password prompt is always in front of kmail
> 
> 
> Thanks,
> 
> Allen Winter
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120720/4c912cd5/attachment.htm>