… to compile polkit-qt-1!
So, after I got your attention with the tabloid-style headline, let’s make a bit less shocking point of the current situation, or “What did I do during summer?”. 🙂
First of all, please let me apologize for the time it took me to at least put up a summary of my project, I was (and still am, but it’s getting better every day) sick past few weeks and finally getting into a more “alive” shape.
Well, if I could make it in one sentence, it would be something along the lines of “I hacked libpolkit out of polkit-qt-1”. But that’s not all, let’s jump on the longer version of the story:
After playing around with the D-Bus classes in Qt a little bit, I tried generating bindings for the org.freedesktop.PolicyKit1.Authority interface. Of course it didn’t work initially but very soon I had a working connection and could call some methods. This success led me into believing I could get rid of those nasty GLIB-based methods in our library (Hey, it’s called polkit-qt-1, not polkit-qt-glib-1!).
The progress
I was very naive because I thought it could be done quickly.
There were various bumps on the road (and still will be) but the biggest ones were caused by my stupidity so no big deal implementation-wise really.
For example – I had wrong QDBusArgument streaming operators for the Identity class, resulting in having a different signature for a slot on the AuthenticationAgent adaptor, which then of course ended up in the authority not being able to call BeginAuthentication correctly because of a wrong method signature. I’m not sure how I found out but Qt definitely wasn’t helping me. Which I can illustrate by this: I found out about the QTDBUS_DEBUG environment variable in a few small blogposts when I was googling about it but its documentation is almost nonexistent.
The most recent state is in the noglib branch of my personal clone (mbriza/gsoc13-polkit-qt-1). The last commit I had when GSoC ended is the biggest one, currently about 1400 additions and 1300 deletions. From now on, I’ll commit the changes incrementally and stop modifying this one.
As the changes that will be introduced by these commits will be quite consistent as one and depend on each other, there will be a single commit for the whole change. I don’t see purpose in splitting it – No part of the transition can be done on its own and keep the functionality as a whole intact.
It works!
What I achieved so far with this is being able to run polkit-kde-authentication-agent-1 with the new library loaded and successfully authenticate for any action in the system… without crashes (whew).
Most of the project is now hooked on the D-Bus API – this means the whole core and agent-listener.
The agent-session is a tad different though – it’s an authentication backend wrapper which in a short means it wraps and mimics PAM conversation. Implementing such functionality would be a huge overkill so I stuck to usage of the session helper provided by polkit which is then communicating with the library using a really simple text-based protocol.
What needs to be done now
- REVIEW 🙂
- adding all missing features (from the tip of my pen, i’m pretty sure creating of subject and identity objects isn’t really valid)
- completing D-Bus call handling (timed out, no reply, etc.)
- adding support for the libpolkit API (which I’m kind of considering obsolete and seriously doubt anyone ever used the structures from libpolkit as parameters to polkit-qt-1 methods… but even though there is this doubt, the methods in question are part of the public API
- fixing and cleaning up both the D-Bus adaptor and interface, ideally to the state when they can be automatically generated from the “XML”s provided by polkit upstream
- finding the location of the polkit provided session helper properly
- CMake magic to actually abandon libpolkit, e.g. to get rid of it altogether, even from the headers
KRunner UI
As discussed in the previous posts, I also experimented with implementing the dialog as a runner, which went reasonably usable, except for the fact the password is displayed as a regular KRunner query.
This means I’ll have to convince the folks maintaining it to add a property or method to set input masking.
Having the password dialog in the textbox UI of KRunner means an improvement in user experience and simplification for end users. It’s also worth noting that simple disabling the runner will give the user access to the old way how dialogs were shown with all the advanced information.
There are a few variants on how to implement the final UI to be included, which will be of course discussed before any definitive decision is made. There are three different pieces of information we may want to display to the user.
- The basic request description (yeah, we want this one for sure)
- Extended description of the request
- Message about why the hell the dialog popped from the top of the screen and what does it want from the user
KDE, Qt, Fedora 
Pingback: You won’t need polkit anymore! | Bartle Doo Articles
one small advice on krunner, could it be something like:
[lock icon] [empty field with placeholder: enter the password], an extra label I looks redundant.
Impressive work!
Great work on the infrastructure side, but erm, do you really make KRunner pop up triggered by the system instead of a user action? If so, then no, this is not an improvement in user experience. KRunner is supposed to be invoked by the user, not pop up triggered by the system itself! If we start doing this, KRunner becomes completely unpredictable.
I agree that modal dialogs are not very pleasant to use, but KRunner definitely is not the solution.
Did you contact usability experts, as stated in your previous post, before doing this? If so: Could you please tell me who you contacted so I can talk to them about why they think this makes sense? If no: Why not?
Sorry for being so negative here, but this came as quite a shock to me as a usability expert.
I totally agree on this part. Krunner is meant to be triggered by the user.
A popup in the notification area would be the appropriate way to show this imho.
Other than that great work 🙂
Thanks for your reply!
No, I did not yet, it was more in terms of playing with the possibilities and libraries, I’m yet going to open a discussion. Anyway, it’s not that the polkit dialog pops out of nowhere randomly. It is (or, should be) always triggered by some user action, so in these terms it’s a similar fashion to how it works for session switching.
But you’re right the notification area could be a better way.
It is usually triggered by a user action, but that action usually doesn’t happen in KRunner.
If the user does something in KRunner which needs authentication, then it would make sense to enter the password there as well, but not if the triggering action happened outside of KRunner.
Actually I think ideally the authentication dialog should be presented directly at the place where it was triggered: If it was triggered somewhere in KRunner, it should be in KRunner. If it was triggered by an application, it should be displayed inside that application. I don’t know if that’s technically possible, though.
I’d suggest you send an email to kde-usability@kde.org so that the whole usability team and developers who are on that list can discuss the topic.
He’s got a point though, the session switcher already appears in KRunner as result of an action in the K menu – isn’t that the same kind of bad usability?
I am always a big fan of having no dependencies on gtk, glib and other gnome stuff. But I am not sure that switching from a glib-based *library* to a *dbus*-based system is a great idea. What impact does this change have on the user experience? Are things faster now? I expect a dbus-based system to be slower than a system that directly uses the correct library, but I could be wrong. If it is indeed slower, then from a user POV this change is not an improvement, but rather a deterioration. In my experience, coding dbus connections in Qt is not the most straightforward thing to do (I don’t know about other toolkits, so no blame to Qt intended), so I am not sure that not using the polkit library directly is making the code more maintainable. The correct thing would have been to program libpolkit in a toolkit-independent way, so that it would not depend on Gnome’s stuff, and to implement front-ends for each toolkit, like it is done for poppler.
Amazing! When we started with Polkit 1 rewrite, we hit so many issues using DBus and we were time constrained (due to next Fedora schedules), so we decided to go with glib wrapper. It was pain too :).
For KRunner – maybe it’s not a best place to have it but it’s the must. In old PolicyKit, it was possible to tie app with auth dialog (as asked above) but window ID is not passed anymore to auth dialog in PK1. It leads to bug, where auth dialog is sometimes hidden behind other windows. At least for KDE apps, it’s fixed by workaround from Lubos but… So we need some way how to show dialog in workspace, visible and actually some dialogs makes sense to be part of workspace.
Pingback: Going to Brno for a week of awesome. – À.Fiestas