Projects/KAuth/Polkit-Qt-1: Difference between revisions
No edit summary |
m (moved Polkit-Qt-1 to Projects/KAuth/Polkit-Qt-1) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
=> 4.4: Have polkit-0.9 in workspace and polkit-1 in a separate tarball | => 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. | => 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 development plans== | ||
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. | 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. | ||
| Line 23: | Line 24: | ||
About the namespace, I think it would be sensible to keep PolkitQt and not PolkitQt1, for a variety of reasons: | 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. | => polkit-qt 0.9 and polkit-qt-1 are meant to be installable together, but should 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. | => 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== | ==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. | 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. [Dario: Fixed that, now the API is way more consistent] | ||
==Polkit-Qt Agent & KDE Authentication Agent== | |||
We have to extend Polkit-Qt with Polkit-Qt-Agent library as we need it to implement KDE Authentication Agent. It wraps polkit-agent-1 gobject based library. Gnome Authentication Agent could be used meanwhile. | |||
Latest revision as of 23:40, 26 March 2011
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
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 should 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. [Dario: Fixed that, now the API is way more consistent]
Polkit-Qt Agent & KDE Authentication Agent
We have to extend Polkit-Qt with Polkit-Qt-Agent library as we need it to implement KDE Authentication Agent. It wraps polkit-agent-1 gobject based library. Gnome Authentication Agent could be used meanwhile.