Projects/KAuth/Polkit-Qt-1

Polkit-Qt-1 is the next version of Polkit-Qt, based on Polkit-1. Please be aware these are just development plans, neither Polkit-Qt-1 or polkit-1 are ready for production.

KDE Plans for Polkit

We (as in the KDE team) want to switch to polkit-1 by default just when we will reach feature parity with our polkit-0.9 tools. The KAuth backend for polkit-1 will be made available as soon as polkit-qt-1 will be ready, but not made as default until the requirements above are met.

Fedora/Red Hat people will switch to polkit-1 by default upon Fedora 12 release, which is before 4.4. Hopefully, we will be able to deliver 4.4/KAuth with polkit-1 by default

KDE Release Cycle and Polkit

It is quite unlikely that every polkit-1 tool will made it into 4.4/workspace. We can, however, if everything will be ready by 4.4 release, make KAuth polkit-1 backend default, and provide a separate tarball for polkit-1 tools (just like we did with polkit-0.9 and KDE 4.2), and merging them later in kdebase/workspace. We also want to deprecate polkit-0.9 by making it a separate tarball. Hence the plan would be:

=> 4.4: Have polkit-0.9 in workspace and polkit-1 in a separate tarball

=> 4.5: Have polkit-1 in workspace, and polkit-0.9 in a separate tarball for legacy installations. Put polkit-0.9 in maintenance mode in KDE Extragear.

Polkit-Qt-1 development plans

Polkit-Qt-1 aims to maintain partial source compatibility with polkit-qt 0.9 (mainly for the Auth class). Complete source/binary compatibility is impossible, as polkit-1 brings extensive changes to design and API.

Polkit-Qt-1 also aims to be a complete in-place replacement to the Polkit-1 gobject library, by wrapping it around to make it Qt-Styled.

For those reasons, we want to have the new library named polkit-qt-1, and be side-by-side installable with polkit-qt 0.9, just like polkit 0.9 and polkit-1. We also want to change the include headers location to /usr/include/polkit-1/polkit-qt-1, and the so library to be named polkit-qt-1.so to make it completely separate from the previous one (please note that this naming convention is widely used, for example dbus is named dbus-1).

We will also create a separate FindPolkitQt1.cmake file to make things handled separately.

About the namespace, I think it would be sensible to keep PolkitQt and not PolkitQt1, for a variety of reasons:

=> polkit-qt 0.9 and polkit-qt-1 are meant to be installable together, but not to be used together. This would not make any sense at all.

=> The name would not make sense as we check the library version at runtime. Other software using the *-1 convention does not take such measures in the API.

Polkit-Qt GUI

Efforts on Polkit-Qt-GUI-1 should not be dropped. The API, though, needs to be cleaned up, also for the removal of some Polkit::Results from the polkit API. we probably want to have a setText(const QString &, PolkitQt::Result) or something like that to let developers set icon/text/Whatever association to a status in a more natural way.