And as I see it, I found it kind of silly to hack in a KDE aspect. -----原始邮件----- 发件人: "Leslie Zhai" <xiangzha...@gmail.com> 发送时间: 2014/6/1 15:17 收件人: "Thomas Lübking" <thomas.luebk...@gmail.com>; "kde-devel@kde.org" <kde-devel@kde.org> 抄送: "Daniel Nicoletti" <dantt...@gmail.com>; "jeffbaich...@members.fsf.org" <jeffbaich...@members.fsf.org> 主题: Re: PolicyKit1-KDE AuthDialog could not shown as TOP_LEVEL
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.z...@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 <<
