[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Review Request: Make KAuth ready for frameworks + API Changes
From: "Kevin Ottens" <ervin () kde ! org>
Date: 2012-03-22 16:04:34
Message-ID: 20120322160434.16614.32150 () vidsolbach ! de
[Download RAW message or body]
> On March 18, 2012, 11:04 p.m., Stephen Kelly wrote:
> > Nice, thanks and sorry for the noise, and thanks for making the branch.
> =
> Dario Freddi wrote:
> Np, hope you'll be able to have a quick look at it as well, it would =
be great :)
> =
> Stephen Kelly wrote:
> Mostly it looks fine. =
> =
> The enums are not named consistently though. Sometimes you make it <e=
num name><enum value> (eg StatusDenied) and sometimes you use <enum value><=
enum name> (eg HelperBusyError).
> The Qt way would be <enum value><enum name>.
> =
> Also, you replied that removed APIs are used nowhere. Are the enums u=
sed nowhere too? Is it worth keeping the backward compatibility enum names?=
Assuming your branch builds (I didn't try it) nothing else inside of kdeli=
bs seems to need those enum values at least, so maybe it's not a big deal.
> =
> I'm also generally impressed with how the commits are written to do o=
ne thing at a time, so thanks for that. I wonder if the fixes to ExecuteJob=
should be squashed though as well as porting it to KJob? It's not clear to=
me if those commits are separate because of something in an intermediate c=
ommit? Not very important either way. I don't mind if you change them or no=
t.
> =
> Some of the files in the unit tests appear to be old. Are they copied=
from somewhere? Could they be moved instead?
> =
> Stephen Kelly wrote:
> Regarding what you asked about:
> =
> * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. Author=
izationDeniedError. While the semantic seems correct to me, I'd like to hav=
e some feedback on whether consistency is valuable in the ordering of <type=
><value> vs. <value><type> and which one should be preferred in case.
> =
> I guess I prefer the Qt style.
> =
> * Whether to deprecate static accessors such as static const ActionR=
eply SuccessReply(). I strongly favor this.
> =
> If you know that they are not much used or easily portable, I'd say g=
o for it.
> =
> * Whether the new dependency of kcoreaddons for the sake of using KJ=
ob is reasonable or I should go for a different alternative.
> =
> I think it's an ok dependency. I still hope that class will move to a=
different framework at some point if we can find other classes that it wou=
ld belong with ('base-asyncronous APIs'?). 'addons' is a forbidden name if =
the result of Randa is followed.
> =
> * CMake sanity for the new dependency of kcoreaddons.
> =
> That's fine, yes.
>
> =
> Kevin Ottens wrote:
> Result pretty much aligns with what I was expecting as outcome from o=
ur previous private discussion. And so, apart from the points Stephen alrea=
dy raised I see nothing outstanding now.
> =
> Dario Freddi wrote:
> Enums: will change all of them to be <value><name> (InvalidStatus, Ex=
ecuteMode, AuthorizationDeniedError).
> =
> Static accessors: they are easily portable (one should use SuccessRep=
ly() compared to previous SuccessReply) and quite used widely. I'd like peo=
ple to use ActionReply(ActionReply::SuccessType) instead, although they are=
indeed widely used in helpers. Quite torn on this one - now they're safe t=
o use though, so I guess that besides adding lots of symbols for the sake o=
f nothing, they won't hurt. What's your take?
> =
> Squashing ExecuteJob's commits might be a good idea now that it's cle=
ar we're going to use KJob as a base class. Will also take care of amending=
other commits for the sake of clarity.
> =
> The enums are not used exactly because the static accessors are used =
instead. The only enums that might be used around are the error ones, but a=
gain it's not something as big to justify the need for having to keep SC wi=
th those.
> =
> Old files in unit tests - Disclaimer I should have put: I forgot to u=
pdate copyrights and documentation, so those will come later. Files in the =
autotests directory are slight modifications of existent files which basica=
lly hijack KAuth's backend loading making it possible to use a different te=
sting backend. Will probably write a more detailed documentation on how aut=
otesting is achieved in the future, not anything strictly urgent unless som=
ebody plans to hack on the core testing suite soon (very unlikely).
> =
> Will fix enums in my branch (I won't update the review since it's too=
much of a hassle) and will wait for further feedback from you about the ot=
her points before amending & merging.
Regarding the static accessors I think you're right, they won't hurt. If th=
at really bothers you though you could at least mark them deprecated, that'=
ll motivate people to port away from them, and you'll be in a good position=
to remove them at the next great ABI breakage. :-)
- Kevin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104337/#review11596
-----------------------------------------------------------
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
> =
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104337/
> -----------------------------------------------------------
> =
> (Updated March 18, 2012, 10:25 p.m.)
> =
> =
> Review request for kdelibs, Kevin Ottens, David Faure, and Alexander Neun=
dorf.
> =
> =
> Description
> -------
> =
> Preamble - sorry for having to name-call people but apparently we still d=
on't have a frameworks way for reviewing code (which sucks). And sorry for =
the long summary, but it's worth reading. However.
> =
> This huge patchsets brings KAuth in the marvelous world of Frameworks. If=
you dislike ReviewBoard's way of displaying diffs or simply want to see a =
commit list, please refer to the URL in "Branch".
> =
> First of all, I pulled in a dependency on KJob after a chat with Kevin. T=
his makes KAuth tier2, but shouldn't be a big issue.
> =
> Then there's the hard part: source compatibility is reasonably broken her=
e. The changes I had to do were mostly for the sake of revamping the intern=
al workflow of the library. The main problem KAuth had was the fact it was =
completely synchronous, leading to a multitude of problems. After these cha=
nges it's fully asynchronous instead (reason for pulling in KJob), the API =
was simplified, and some unused features like multiple action execution hav=
e been removed.
> =
> The main changes at a glance:
> =
> * Some renaming to the enums
> * Moving Action & ActionReply to be implicitly shared
> * Removing ActionWatcher (now useless due to the new semantics of execute
> * Removing some useless APIs from Action, namely executeActions, execute=
(helper)
> * execute() now returns a KJob
> * helperID() -> helperId()
> * Static action replies are now static accessors returning a new instanc=
e. This was a complete mistake in the first place, but it's still there wit=
h a different semantic to ease porting. The main use case for changing this=
is a failure to handle implicitly shared classes in multithreaded environm=
ents with that approach.
> =
> Of course, while it would be awesome to have all the code reviewed, I und=
erstand it's a very big change so I'd like at least some feedback on the fo=
llowing points:
> =
> * General sanity of the new API
> * Consistency of the enums. StatusInvalid vs. ExecuteMode vs. Authorizat=
ionDeniedError. While the semantic seems correct to me, I'd like to have so=
me feedback on whether consistency is valuable in the ordering of <type><va=
lue> vs. <value><type> and which one should be preferred in case.
> * Whether to deprecate static accessors such as static const ActionReply=
SuccessReply(). I strongly favor this.
> * Whether the new dependency of kcoreaddons for the sake of using KJob i=
s reasonable or I should go for a different alternative.
> * CMake sanity for the new dependency of kcoreaddons.
> =
> The code is pretty much unit-tested and it should have a decent coverage,=
even if I had no way to check this. For unit tests, I had to create a fake=
authorization backend for testing purposes, whereas I managed to reuse the=
dbus backend for helper communication, so that I could even test that. For=
running the helper and the client in the same process, in the unit test I =
am resorting to making the dbus service of the helper live in a separate th=
read, to prevent asynchronous DBus calls from failing due to QDBus' local-l=
oop optimization. The test is also run on the session bus.
> =
> =
> Diffs
> -----
> =
> staging/kauth/CMakeLists.txt PRE-CREATION =
> staging/kauth/autotests/BackendsManager.h PRE-CREATION =
> staging/kauth/autotests/BackendsManager.cpp PRE-CREATION =
> staging/kauth/autotests/CMakeLists.txt PRE-CREATION =
> staging/kauth/autotests/HelperTest.cpp PRE-CREATION =
> staging/kauth/autotests/SetupActionTest.cpp PRE-CREATION =
> staging/kauth/autotests/TestBackend.h PRE-CREATION =
> staging/kauth/autotests/TestBackend.cpp PRE-CREATION =
> staging/kauth/autotests/TestHelper.h PRE-CREATION =
> staging/kauth/autotests/TestHelper.cpp PRE-CREATION =
> staging/kauth/src/AuthBackend.h PRE-CREATION =
> staging/kauth/src/CMakeLists.txt PRE-CREATION =
> staging/kauth/src/HelperProxy.h PRE-CREATION =
> staging/kauth/src/backends/dbus/DBusHelperProxy.h PRE-CREATION =
> staging/kauth/src/backends/dbus/DBusHelperProxy.cpp PRE-CREATION =
> staging/kauth/src/backends/dbus/org.kde.auth.xml PRE-CREATION =
> staging/kauth/src/backends/fake/FakeBackend.cpp PRE-CREATION =
> staging/kauth/src/backends/fakehelper/FakeHelperProxy.h PRE-CREATION =
> staging/kauth/src/backends/fakehelper/FakeHelperProxy.cpp PRE-CREATION =
> staging/kauth/src/backends/mac/AuthServicesBackend.cpp PRE-CREATION =
> staging/kauth/src/backends/policykit/PolicyKitBackend.cpp PRE-CREATION =
> staging/kauth/src/backends/polkit-1/Polkit1Backend.cpp PRE-CREATION =
> staging/kauth/src/kauthaction.h PRE-CREATION =
> staging/kauth/src/kauthaction.cpp PRE-CREATION =
> staging/kauth/src/kauthactionreply.h PRE-CREATION =
> staging/kauth/src/kauthactionreply.cpp PRE-CREATION =
> staging/kauth/src/kauthactionwatcher.h PRE-CREATION =
> staging/kauth/src/kauthactionwatcher.cpp PRE-CREATION =
> staging/kauth/src/kauthexecutejob.h PRE-CREATION =
> staging/kauth/src/kauthexecutejob.cpp PRE-CREATION =
> =
> Diff: http://git.reviewboard.kde.org/r/104337/diff/
> =
> =
> Testing
> -------
> =
> New unit tests pass 100%
> =
> =
> Thanks,
> =
> Dario Freddi
> =
>
[Attachment #3 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/104337/">http://git.reviewboard.kde.org/r/104337/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On March 18th, 2012, 11:04 p.m., <b>Stephen \
Kelly</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Nice, thanks and sorry for the noise, and thanks for making the \
branch.</pre> </blockquote>
<p>On March 18th, 2012, 11:06 p.m., <b>Dario Freddi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Np, hope you'll be \
able to have a quick look at it as well, it would be great :)</pre> </blockquote>
<p>On March 19th, 2012, 8:58 p.m., <b>Stephen Kelly</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Mostly it looks fine.
The enums are not named consistently though. Sometimes you make it <enum \
name><enum value> (eg StatusDenied) and sometimes you use <enum \
value><enum name> (eg HelperBusyError). The Qt way would be <enum \
value><enum name>.
Also, you replied that removed APIs are used nowhere. Are the enums used nowhere too? \
Is it worth keeping the backward compatibility enum names? Assuming your branch \
builds (I didn't try it) nothing else inside of kdelibs seems to need those enum \
values at least, so maybe it's not a big deal.
I'm also generally impressed with how the commits are written to do one thing at \
a time, so thanks for that. I wonder if the fixes to ExecuteJob should be squashed \
though as well as porting it to KJob? It's not clear to me if those commits are \
separate because of something in an intermediate commit? Not very important either \
way. I don't mind if you change them or not.
Some of the files in the unit tests appear to be old. Are they copied from somewhere? \
Could they be moved instead? </pre> </blockquote>
<p>On March 19th, 2012, 9:04 p.m., <b>Stephen Kelly</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Regarding what you asked \
about:
* Consistency of the enums. StatusInvalid vs. ExecuteMode vs. \
AuthorizationDeniedError. While the semantic seems correct to me, I'd like to \
have some feedback on whether consistency is valuable in the ordering of \
<type><value> vs. <value><type> and which one should be \
preferred in case.
I guess I prefer the Qt style.
* Whether to deprecate static accessors such as static const ActionReply \
SuccessReply(). I strongly favor this.
If you know that they are not much used or easily portable, I'd say go for it.
* Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable \
or I should go for a different alternative.
I think it's an ok dependency. I still hope that class will move to a different \
framework at some point if we can find other classes that it would belong with \
('base-asyncronous APIs'?). 'addons' is a forbidden name if the \
result of Randa is followed.
* CMake sanity for the new dependency of kcoreaddons.
That's fine, yes.
</pre>
</blockquote>
<p>On March 20th, 2012, 5:04 p.m., <b>Kevin Ottens</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Result pretty much \
aligns with what I was expecting as outcome from our previous private discussion. And \
so, apart from the points Stephen already raised I see nothing outstanding now.</pre> \
</blockquote>
<p>On March 21st, 2012, 12:20 a.m., <b>Dario Freddi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Enums: will change all \
of them to be <value><name> (InvalidStatus, ExecuteMode, \
AuthorizationDeniedError).
Static accessors: they are easily portable (one should use SuccessReply() compared to \
previous SuccessReply) and quite used widely. I'd like people to use \
ActionReply(ActionReply::SuccessType) instead, although they are indeed widely used \
in helpers. Quite torn on this one - now they're safe to use though, so I guess \
that besides adding lots of symbols for the sake of nothing, they won't hurt. \
What's your take?
Squashing ExecuteJob's commits might be a good idea now that it's clear \
we're going to use KJob as a base class. Will also take care of amending other \
commits for the sake of clarity.
The enums are not used exactly because the static accessors are used instead. The \
only enums that might be used around are the error ones, but again it's not \
something as big to justify the need for having to keep SC with those.
Old files in unit tests - Disclaimer I should have put: I forgot to update copyrights \
and documentation, so those will come later. Files in the autotests directory are \
slight modifications of existent files which basically hijack KAuth's backend \
loading making it possible to use a different testing backend. Will probably write a \
more detailed documentation on how autotesting is achieved in the future, not \
anything strictly urgent unless somebody plans to hack on the core testing suite soon \
(very unlikely).
Will fix enums in my branch (I won't update the review since it's too much of \
a hassle) and will wait for further feedback from you about the other points before \
amending & merging.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Regarding the static \
accessors I think you're right, they won't hurt. If that really bothers you \
though you could at least mark them deprecated, that'll motivate people to port \
away from them, and you'll be in a good position to remove them at the next great \
ABI breakage. :-)</pre> <br />
<p>- Kevin</p>
<br />
<p>On March 18th, 2012, 10:25 p.m., Dario Freddi wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kdelibs, Kevin Ottens, David Faure, and Alexander \
Neundorf.</div> <div>By Dario Freddi.</div>
<p style="color: grey;"><i>Updated March 18, 2012, 10:25 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Preamble - sorry for having to name-call people but apparently we still \
don't have a frameworks way for reviewing code (which sucks). And sorry for the \
long summary, but it's worth reading. However.
This huge patchsets brings KAuth in the marvelous world of Frameworks. If you dislike \
ReviewBoard's way of displaying diffs or simply want to see a commit list, please \
refer to the URL in "Branch".
First of all, I pulled in a dependency on KJob after a chat with Kevin. This makes \
KAuth tier2, but shouldn't be a big issue.
Then there's the hard part: source compatibility is reasonably broken here. The \
changes I had to do were mostly for the sake of revamping the internal workflow of \
the library. The main problem KAuth had was the fact it was completely synchronous, \
leading to a multitude of problems. After these changes it's fully asynchronous \
instead (reason for pulling in KJob), the API was simplified, and some unused \
features like multiple action execution have been removed.
The main changes at a glance:
* Some renaming to the enums
* Moving Action & ActionReply to be implicitly shared
* Removing ActionWatcher (now useless due to the new semantics of execute
* Removing some useless APIs from Action, namely executeActions, execute(helper)
* execute() now returns a KJob
* helperID() -> helperId()
* Static action replies are now static accessors returning a new instance. This was \
a complete mistake in the first place, but it's still there with a different \
semantic to ease porting. The main use case for changing this is a failure to handle \
implicitly shared classes in multithreaded environments with that approach.
Of course, while it would be awesome to have all the code reviewed, I understand \
it's a very big change so I'd like at least some feedback on the following \
points:
* General sanity of the new API
* Consistency of the enums. StatusInvalid vs. ExecuteMode vs. \
AuthorizationDeniedError. While the semantic seems correct to me, I'd like to \
have some feedback on whether consistency is valuable in the ordering of \
<type><value> vs. <value><type> and which one should be \
preferred in case.
* Whether to deprecate static accessors such as static const ActionReply \
SuccessReply(). I strongly favor this.
* Whether the new dependency of kcoreaddons for the sake of using KJob is reasonable \
or I should go for a different alternative.
* CMake sanity for the new dependency of kcoreaddons.
The code is pretty much unit-tested and it should have a decent coverage, even if I \
had no way to check this. For unit tests, I had to create a fake authorization \
backend for testing purposes, whereas I managed to reuse the dbus backend for helper \
communication, so that I could even test that. For running the helper and the client \
in the same process, in the unit test I am resorting to making the dbus service of \
the helper live in a separate thread, to prevent asynchronous DBus calls from failing \
due to QDBus' local-loop optimization. The test is also run on the session \
bus.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">New unit tests pass 100%</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>staging/kauth/CMakeLists.txt <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/BackendsManager.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/BackendsManager.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/CMakeLists.txt <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/HelperTest.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/SetupActionTest.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/TestBackend.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/TestBackend.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/TestHelper.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/autotests/TestHelper.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/AuthBackend.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/CMakeLists.txt <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/HelperProxy.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/dbus/DBusHelperProxy.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/dbus/DBusHelperProxy.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/dbus/org.kde.auth.xml <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/fake/FakeBackend.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/fakehelper/FakeHelperProxy.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/fakehelper/FakeHelperProxy.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/mac/AuthServicesBackend.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/policykit/PolicyKitBackend.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/backends/polkit-1/Polkit1Backend.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthaction.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthaction.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthactionreply.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthactionreply.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthactionwatcher.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthactionwatcher.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthexecutejob.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>staging/kauth/src/kauthexecutejob.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/104337/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic