org/r/114195/
> ---
>
> (Updated Nov. 29, 2013, 6:20 a.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: kdelibs
>
>
> Description
> ---
>
> The cast operator didn't pa
marked as submitted.
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
The cast operator didn't pass the License information, so when using a
K4AboutData the license information was set to unknown.
Diffs
-
tier4/kde4support/src/kdecore/k4aboutdata.cpp 9b
v. 29, 2013, 6:20 a.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: kdelibs
>
>
> Description
> ---
>
> The cast operator didn't pass the License information, so when using a
> K4AboutData the license information was set to un
---
The cast operator didn't pass the License information, so when using a
K4AboutData the license information was set to unknown.
Diffs
-
tier4/kde4support/src/kdecore/k4aboutdata.cpp 9bdc1a4
Diff: http://git.reviewboard.kde.org/r/114195/diff/
Testing
---
only with a sta
On Tuesday 26 November 2013 09:56:54 Stephen Kelly wrote:
> I looked into this to try to understand, but I still don't understand why a
> patch something like this can not be applied:
The problem is with the code in main(), that would call this.
KCmdLineArgs *has* to be used before the QCoreAppl
--
// Design notes:
@@ -469,6 +470,18 @@ KCmdLineArgs::init(int _argc, char **_argv, const
K4AboutData *_about, StdCmdLin
addStdCmdLineOptions(stdargs);
}
+void
+KCmdLineArgs::init(int _argc, char **_argv, const KAboutData *_about,
StdCmdLineArgs stda
David Faure wrote:
> Conclusion:
> I think it's a lot simpler to keep things as is,
I can't say I understand fully, but thanks for looking into it!
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman
Hi Stephen,
as promised I had another look at the KAboutData vs K4AboutData situation,
in order to attempt to minimize the SIC.
Context:
KCmdLineArgs uses K4AboutData rather than KAboutData: K4AboutData keeps the
old mechanism for delayed translations (I18N_NOOP), while KAboutData is the
one
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
(Updated July 29, 2013, 7:15 p.m.)
Status
--
This change has been mar
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/#review36773
---
This review has been submitted with commit
21dfceedf2bf4a3fbc5
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/#review36767
---
Ship it!
KHTML could be ported away of course, but this can be
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
(Updated July 29, 2013, 6:07 p.m.)
Review request for KDE Frameworks.
De
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
(Updated July 29, 2013, 4:20 p.m.)
Review request for KDE Frameworks.
Ch
removing the install
dir), then yes it's enough :)
This task only became possible after the port from KCmdLineArgs to
QCommandLineParser, because KCmdLineArgs is heavily based on K4AboutData. This
is why we couldn't do it before.
Thanks!
kdecore/kernel/kcomponentdata
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
(Updated July 27, 2013, 2:42 p.m.)
Review request for KDE Frameworks.
Ch
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
(Updated July 27, 2013, 1:04 p.m.)
Review request for KDE Frameworks.
Ch
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111702/
---
Review request for KDE Frameworks.
Description
---
Is this enough?
17 matches
Mail list logo
