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

List:       kde-devel
Subject:    Re: PolicyKit1-KDE AuthDialog could not shown as TOP_LEVEL
From:       Leslie Zhai <xiangzhai83 () gmail ! com>
Date:       2014-06-01 7:16:46
Message-ID: 538AD35E.9010708 () gmail ! com
[Download RAW message or body]

Hi Thomas,

Thanks for your reply :)

1. it is NOT a bug about Apper or QJade.

Because Apper and QJade uses PackageKit-Qt, a Qt bindings for 
PackageKit. When it calls installPackage function of PackageKit-Qt, 
there is pk_transaction_obtain_authorization function in PackageKit to 
call PolicyKit relative dbus async APIs such as 
polkit_authority_check_authorization.
the process shown as below:

Apper install package -> PackageKit-Qt call installPackage -> PackageKit 
do PolicyKit authorization -> polkitd -> Polkit-Qt -> Polkit-KDE

so there is NO Apper assoicate WID for AuthDialog constructor.

2. KWindowSystem::forceActiveWindow sometimes worked BUT ...

Sometimes it FAILED to force active window to act like modal one, for 
example, Apper or QJade covered the Polkit-KDE AuthDialog window, but I 
simply setWindowFlags for AuthDialog to force it as _NET_WM_STATE_ABOVE, 
I experienced it :) 
https://github.com/xiangzhai/grt/blob/master/GRTExamples/ClassificationModulesExamples/X11DTWExample/x11.cpp#L102 \




Regards,
Leslie Zhai <xiang.zhai@i-soft.com.cn>


On 2014年05月30日 21:49, Thomas Lübking wrote:
> On Freitag, 30. Mai 2014 05:09:58 CEST, Leslie Zhai wrote:
> > Hi KDE developers,
> > 
> > My colleage reported a bug to me, it is about PolicyKit1-KDE AuthDialog
> > UI behavior issue, the AuthDialog could not show as TOP_LEVEL
> 
> That's called "_NET_WM_STATE_ABOVE" - "toplevel" usually refers to a 
> window with the root window as parent drawable.
> 
> > installing some App via Qt frontend of PackageKit, for example, Apper or
> > QJade https://github.com/AOSC-Dev/QJade
> 
> Seems an apper bug.
> You want to pass the Apper window WId as last parameter to the 
> AuthDialog() constructor.
> 
> This will make the AuthDialog modal (and transient) for that window.
> 
> The only problem occurs if you have no window to assiciate the 
> AuthDialog with. In this case you may wish to enforce activation (see 
> KWindowSystem::forceActiveWindow()) which is legit, if the dialog 
> appears as result of a direct user interaction (eg. with some systray 
> icon etc.)
> 
> Cheers,
> Thomas


> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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