Re: Review Request 113426: Adjust API in KEmoticons framework: createNew method

[David Gil Oliva]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113426/
---

(Updated Oct. 24, 2013, 9:54 p.m.)


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Adjust API in KEmoticons framework: createNew method

-To make KEmoticons API more consistent, deprecate 
KEmoticonsProvider::createNew()
and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way,
we have loadTheme(), saveTheme() and newTheme().
-Adjust plugins.
-Before the cleanup, KEmoticonsTheme was calling 
KEmoticonsProvider::createNew(),
which was empty. Therefore, I deprecate it and advice subclassing
KEmoticonsProvider.


Diffs
-

  KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 
  staging/kemoticons/src/core/kemoticons.cpp 
43dac6517b77a0d0040912958fe76687b475d85c 
  staging/kemoticons/src/core/kemoticonsprovider.h 
2ec0de8d1dfb846188bd458b49a4028fee115431 
  staging/kemoticons/src/core/kemoticonsprovider.cpp 
7374966c65922c3e7a5be881c198a8f8f52fee29 
  staging/kemoticons/src/core/kemoticonstheme.h 
25fc29453535d7e73f4e2d0752ce3f989c83fa96 
  staging/kemoticons/src/core/kemoticonstheme.cpp 
e54d015e7f0f866d199d8eed7863fafd28576c13 
  staging/kemoticons/src/providers/adium/adium_emoticons.h 
01d89e13834c345765e696d66560071dc10291af 
  staging/kemoticons/src/providers/adium/adium_emoticons.cpp 
e6719d112a14478bdfd7f8c47633c18108a5633a 
  staging/kemoticons/src/providers/kde/kde_emoticons.h 
0738b79dcf734b7904e061b5eb41807ccaf443ff 
  staging/kemoticons/src/providers/kde/kde_emoticons.cpp 
a99c6d84f5ab7e0e2f41027c37a97f170333dca8 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h 
a51b736f7702d7af1f1367dd1f13271647212fee 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 
7596e30e8e5153185a3dd365858567c69477ff4a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 
4ba706f519cebedaa6c9c3f2f02331e85745e89a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 
afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 

Diff: http://git.reviewboard.kde.org/r/113426/diff/


Testing
---

Builds. Tests pass.


Thanks,

David Gil Oliva

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDirWatch vs QFileSystemWatcher

[Sune Vuorela]

Hi

If your KDirWatch backend is QFileSystemWatcher, one of the testcases
fails.

The last QVERIFY in testMoveTo never receives the signal dirty-signal it
is looking for.

Apparantly, the watch.removeFile apparantly somehow turns off the QFSW
to not do any further notifications for what happens in the directory
that it also is supposed to be watching.

I haven't yet fully understood what's going on here, but if someone is
up for it, fixing it would be nice. Among others, it is the only backend
available on windows.

This dirty patch seems to ensure that QFSW is used on your platform:

diff --git a/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp 
b/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
index 2a89372..8bc9d9b 100644
--- a/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
+++ b/tier1/kcoreaddons/src/lib/io/kdirwatch.cpp
@@ -103,12 +103,7 @@ static KDirWatch::Method methodFromString(const QString 
&method) {
   } else if (method == QLatin1String("QFSWatch")) {
 return KDirWatch::QFSWatch;
   } else {
-#ifdef Q_OS_LINUX
-// inotify supports delete+recreate+modify, which QFSWatch doesn't support
-return KDirWatch::INotify;
-#else
 return KDirWatch::QFSWatch;
-#endif
   }
 }
 

Anyone looking into it would be nice.

/Sune

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 113426: Adjust API in KEmoticons framework: createNew method

[David Gil Oliva]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113426/
---

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Adjust API in KEmoticons framework: createNew method

-To make KEmoticons API more consistent, deprecate 
KEmoticonsProvider::createNew()
and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way,
we have loadTheme(), saveTheme() and newTheme().
-Adjust plugins.
-Before the cleanup, KEmoticonsTheme was calling 
KEmoticonsProvider::createNew(),
which was empty. Therefore, I deprecate it and advice subclassing
KEmoticonsProvider.


Diffs
-

  KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 
  staging/kemoticons/src/core/kemoticons.cpp 
43dac6517b77a0d0040912958fe76687b475d85c 
  staging/kemoticons/src/core/kemoticonsprovider.h 
2ec0de8d1dfb846188bd458b49a4028fee115431 
  staging/kemoticons/src/core/kemoticonsprovider.cpp 
7374966c65922c3e7a5be881c198a8f8f52fee29 
  staging/kemoticons/src/core/kemoticonstheme.h 
25fc29453535d7e73f4e2d0752ce3f989c83fa96 
  staging/kemoticons/src/core/kemoticonstheme.cpp 
e54d015e7f0f866d199d8eed7863fafd28576c13 
  staging/kemoticons/src/providers/adium/adium_emoticons.h 
01d89e13834c345765e696d66560071dc10291af 
  staging/kemoticons/src/providers/adium/adium_emoticons.cpp 
e6719d112a14478bdfd7f8c47633c18108a5633a 
  staging/kemoticons/src/providers/kde/kde_emoticons.h 
0738b79dcf734b7904e061b5eb41807ccaf443ff 
  staging/kemoticons/src/providers/kde/kde_emoticons.cpp 
a99c6d84f5ab7e0e2f41027c37a97f170333dca8 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h 
a51b736f7702d7af1f1367dd1f13271647212fee 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 
7596e30e8e5153185a3dd365858567c69477ff4a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 
4ba706f519cebedaa6c9c3f2f02331e85745e89a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 
afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 

Diff: http://git.reviewboard.kde.org/r/113426/diff/


Testing
---

Builds. Tests pass.


Thanks,

David Gil Oliva

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113426: Adjust API in KEmoticons framework: createNew method

[David Gil Oliva]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113426/
---

(Updated Oct. 24, 2013, 9:54 p.m.)


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Adjust API in KEmoticons framework: createNew method

-To make KEmoticons API more consistent, deprecate 
KEmoticonsProvider::createNew()
and prefer newTheme() instead, as it appears in KEmoticonsTheme. That way,
we have loadTheme(), saveTheme() and newTheme().
-Adjust plugins.
-Before the cleanup, KEmoticonsTheme was calling 
KEmoticonsProvider::createNew(),
which was empty. Therefore, I deprecate it and advice subclassing
KEmoticonsProvider.


Diffs
-

  KDE5PORTING.html ceff2fa13e4a666939dd0a1bb63e967504c31c07 
  staging/kemoticons/src/core/kemoticons.cpp 
43dac6517b77a0d0040912958fe76687b475d85c 
  staging/kemoticons/src/core/kemoticonsprovider.h 
2ec0de8d1dfb846188bd458b49a4028fee115431 
  staging/kemoticons/src/core/kemoticonsprovider.cpp 
7374966c65922c3e7a5be881c198a8f8f52fee29 
  staging/kemoticons/src/core/kemoticonstheme.h 
25fc29453535d7e73f4e2d0752ce3f989c83fa96 
  staging/kemoticons/src/core/kemoticonstheme.cpp 
e54d015e7f0f866d199d8eed7863fafd28576c13 
  staging/kemoticons/src/providers/adium/adium_emoticons.h 
01d89e13834c345765e696d66560071dc10291af 
  staging/kemoticons/src/providers/adium/adium_emoticons.cpp 
e6719d112a14478bdfd7f8c47633c18108a5633a 
  staging/kemoticons/src/providers/kde/kde_emoticons.h 
0738b79dcf734b7904e061b5eb41807ccaf443ff 
  staging/kemoticons/src/providers/kde/kde_emoticons.cpp 
a99c6d84f5ab7e0e2f41027c37a97f170333dca8 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h 
a51b736f7702d7af1f1367dd1f13271647212fee 
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp 
7596e30e8e5153185a3dd365858567c69477ff4a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h 
4ba706f519cebedaa6c9c3f2f02331e85745e89a 
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp 
afb07b207407b00bbe0d38e0ca6d9e2bf2ccd809 

Diff: http://git.reviewboard.kde.org/r/113426/diff/


Testing
---

Builds. Tests pass.


Thanks,

David Gil Oliva

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113424: Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()

[Alex Merry]

> On Oct. 24, 2013, 7:25 p.m., Alex Merry wrote:
> > whoami is part of coreutils, so should be available everywhere.  The only 
> > possible issue I see is that we've gone from a test that doesn't depend on 
> > PATH to one that does.  This isn't necessarily a problem, but it will test 
> > slightly different code paths.
> 
> Nicolás Alvarez wrote:
> "part of coreutils" is irrelevant for Windows, there's no such thing as 
> coreutils. The point is that Windows also happens to have a command called 
> 'whoami'.

Ah, sorry, by "everywhere", I meant "all UNIX systems".  My point was merely 
that no GNU-based UNIX system, at least, will be missing whoami.  This is less 
obvious for whoami than for ls (at least for me; I had to check with my package 
manager).  It is also part of the BSD general commands, so should exist on all 
BSD flavours, including OSX.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113424/#review42320
---


On Oct. 24, 2013, 3:59 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113424/
> ---
> 
> (Updated Oct. 24, 2013, 3:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()
> 
> Unlike "/bin/ls" this also works on Windows
> 
> 
> Diffs
> -
> 
>   tier1/kconfig/autotests/kdesktopfiletest.cpp 
> 8f2ed2047e39f4f6b5d24a620474c3894f7986cc 
> 
> Diff: http://git.reviewboard.kde.org/r/113424/diff/
> 
> 
> Testing
> ---
> 
> Test passes on both linux and windows
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113424: Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()

[Nicolás Alvarez]

> On Oct. 24, 2013, 4:25 p.m., Alex Merry wrote:
> > whoami is part of coreutils, so should be available everywhere.  The only 
> > possible issue I see is that we've gone from a test that doesn't depend on 
> > PATH to one that does.  This isn't necessarily a problem, but it will test 
> > slightly different code paths.

"part of coreutils" is irrelevant for Windows, there's no such thing as 
coreutils. The point is that Windows also happens to have a command called 
'whoami'.


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113424/#review42320
---


On Oct. 24, 2013, 12:59 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113424/
> ---
> 
> (Updated Oct. 24, 2013, 12:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()
> 
> Unlike "/bin/ls" this also works on Windows
> 
> 
> Diffs
> -
> 
>   tier1/kconfig/autotests/kdesktopfiletest.cpp 
> 8f2ed2047e39f4f6b5d24a620474c3894f7986cc 
> 
> Diff: http://git.reviewboard.kde.org/r/113424/diff/
> 
> 
> Testing
> ---
> 
> Test passes on both linux and windows
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

extra-cmake-modules: remove ECMPrintVariables.cmake

[Alexander Neundorf]

Hi,

e-c-m has a macro ecm_print_variables()
>From the documentation:

# Example:
#   ecm_print_variables(CMAKE_C_COMPILER
#   CMAKE_MAJOR_VERSION THIS_ONE_DOES_NOT_EXIST)
# Gives:
#   -- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ;
#  THIS_ONE_DOES_NOT_EXIST=""


Now that kde frameworks depends on cmake 2.8.12, this could be removed, since 
cmake now has something similar.
include(CMakePrintHelpers)

cmake_print_variables(CMAKE_C_COMPILER
  CMAKE_MAJOR_VERSION THIS_ONE_DOES_NOT_EXIST)

and additionally for printing properties (again from the docs):

cmake_print_properties(TARGETS foo bar
   PROPERTIES LOCATION INTERFACE_INCLUDE_DIRS)
# This will print the LOCATION and INTERFACE_INCLUDE_DIRS properties for both
# targets foo and bar.


These two functions are useful mostly for debugging, and make this more 
convenient.

If somebody feels like it, I think it would be a good idea to remove 
ECMPrintVariables.cmake, now that there is a replacement in cmake.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113373: Enable C++11 support by default.

[Aleix Pol Gonzalez]

> On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote:
> > As far as I know, only threadweaver and karchive will be released in 
> > December. The rest of the frameworks won't be released until summer. 
> > 
> > By summer, CMake 3.0.0 will most likely be out.
> 
> Volker Krause wrote:
> while the CMake 3 solution is obviously much nicer, what are our 
> alternatives until then? The current solution is adding -std=c++0x without 
> proper compiler checks ad-hoc where needed, I think that's far worse than 
> this change. Also, it wont detect incompatibilities with C++11 in currently 
> C++98-only code paths. And changes here are needed anyway, since -ansi 
> effectively prevents you from enabling C++11 (which also suggests ICC hasn't 
> been tested in quite a while).
>
> 
> Ivan Čukić wrote:
> +1
> 
> Stephen Kelly wrote:
> Fair enough.
> 
> I don't recommend releasing ecm with this though.
> 
> I don't see any reason to release ecm when releasing KArchive and 
> Threadweaver. I recommend just copying needed files into the first release of 
> those instead.
> 
> Alexander Neundorf wrote:
> I.e. both will have copies of ECMSetupVersion.cmake, 
> ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and 
> KDECMakeSettings.cmake ?
> This is just so much against what was originally, at least my, idea of 
> e-c-m: make cmake stuff we have in KDE, but which can be useful also in other 
> projects, easier and quicker available to others (instead of not being able 
> to release it when the first frameworks are released).
> But I don't object, it's your decision.
>
> 
> Stephen Kelly wrote:
> It's not my decision either. It's just a recommendation.

I object.
What's the big impediment of releasing ECM? If there's an impediment, let's fix 
it.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113373/#review42130
---


On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113373/
> ---
> 
> (Updated Oct. 21, 2013, 6:51 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Enable C++11 support by default.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d 
> 
> Diff: http://git.reviewboard.kde.org/r/113373/diff/
> 
> 
> Testing
> ---
> 
> Compiles, all required fixes have been integrated into the frameworks branch 
> by now (at least for the subset I have the required dependencies for).
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113424: Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113424/#review42320
---

Ship it!


whoami is part of coreutils, so should be available everywhere.  The only 
possible issue I see is that we've gone from a test that doesn't depend on PATH 
to one that does.  This isn't necessarily a problem, but it will test slightly 
different code paths.

- Alex Merry


On Oct. 24, 2013, 3:59 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113424/
> ---
> 
> (Updated Oct. 24, 2013, 3:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()
> 
> Unlike "/bin/ls" this also works on Windows
> 
> 
> Diffs
> -
> 
>   tier1/kconfig/autotests/kdesktopfiletest.cpp 
> 8f2ed2047e39f4f6b5d24a620474c3894f7986cc 
> 
> Diff: http://git.reviewboard.kde.org/r/113424/diff/
> 
> 
> Testing
> ---
> 
> Test passes on both linux and windows
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Aurélien Gâteau]

> On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.
> 
> Aurélien Gâteau wrote:
> Actually, the even more ideal solution would be for ktranscript to use 
> QtScript instead of KJS. In the future we will have more and more 
> applications developed with QtQuick, so they will already link to QtScript, 
> loading another JavaScript interpreter sounds wasteful to me. Do you think 
> this is doable? I would be quite interested in helping making it happen.
> 
> Aurélien Gâteau wrote:
> Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, 
> QtQuick uses the QJS* classes from QtQML, so this is what we should be using.
> 
> Kevin Ottens wrote:
> I would definitely welcome such a port... I remember asking ktranscript 
> to be ported away from KJS. Would also make ki18n tier 1.
> 
> Aurélien Gâteau wrote:
> I started diving into this today. No change for now, but I wrote some 
> unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is 
> here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests 
> for now. Chusslove: would you be interested in extending the test coverage?
> 
> Chusslove Illich wrote:
> Yes, I most certainly would be interested in extending the test coverage.
> But I intended to do it "full-range", that is starting from test PO files
> (which are already there), once I get to it. And first I need to document 
> it
> better :) Currently all there is is this wiki page:
> http://techbase.kde.org/Localization/Concepts/Transcript
> 
> As for the port away from KJS, I have to state again that I see no value 
> in
> that. Having ki18n be tier 1 is of no use: if someone is so tight on
> dependencies that using a tier 2 framework is a problem, then ki18n is the
> first thing to dump in favor of built-in Qt translation system, tier 1 or
> not. Note that ki18n also brings into play all the Gettext tools, as 
> opposed
> to self-contained Qt translation tools. The only possible advantage of 
> ki18n
> in tier 1 is that it can be used by tier 2 frameworks, of which there is 
> not
> much by my estimate (and between tier 1 and tier 3, I also fail to see the
> reason for existence of tier 2).
>

There is value in both full-range tests and tests exercising smaller parts of 
the code as well IMO.

Thanks for the link, I am going to look at it.

Regarding the port to QJSEngine, I see the following advantages to it:
- It solves the build issue I have been trying to fix with this request: no 
need for uninstalled headers anymore.
- The code is going to be simpler: from what I read of QJSEngine and KJS, 
exposing an object using QJSEngine is simpler than with KJS: no need for lookup 
tables or things like that, just a QObject with slots.
- I expect QJSEngine to be better maintained than KJS, given that it is the 
backbone of QtQuick.
- Having ki18n in tier1 would make it more attractive to Qt developers since it 
brings superior translation support. Right now the cost of dragging in a 
separate JavaScript interpreter, can be perceived as a burden especially for 
QtQuick developers.


- Aurélien


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically gen

Re: Review Request 113406: Add a macro to automatically generate forward headers

[Alexander Neundorf]

> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 29
> > 
> >
> > This variable shouldn't be needed at all.
> 
> Aleix Pol Gonzalez wrote:
> Variable? Or argument? Why?
> 
> Stephen Kelly wrote:
> Argument, yes, sorry.
> 
> I think that because the source dir is already in the 
> INTERFACE_INCLUDE_DIRECTORIES of the target, there is no need to have to 
> specify it, and there should be no need to use ${EGH_HEADERS_DIR}/ in the 
> generated include.
> 
> I guess you have some reason for doing that, but that just points to 
> non-uniformity which should maybe be fixed, as I wrote in the KIO commit I 
> linked to.

I don't see any target involved here...


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---


On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113406/
> ---
> 
> (Updated Oct. 24, 2013, 1:40 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Create a macro that will generate the forward headers like we used to, in 
> cmake configure time.
> 
> Here's an example of how we'd port KParts to that macro: 
> http://paste.opensuse.org/9880051
> After the change, these are the installed headers: 
> http://paste.opensuse.org/90980400
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113406/diff/
> 
> 
> Testing
> ---
> 
> Ported KParts and still everything works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113373: Enable C++11 support by default.

[Stephen Kelly]

> On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote:
> > As far as I know, only threadweaver and karchive will be released in 
> > December. The rest of the frameworks won't be released until summer. 
> > 
> > By summer, CMake 3.0.0 will most likely be out.
> 
> Volker Krause wrote:
> while the CMake 3 solution is obviously much nicer, what are our 
> alternatives until then? The current solution is adding -std=c++0x without 
> proper compiler checks ad-hoc where needed, I think that's far worse than 
> this change. Also, it wont detect incompatibilities with C++11 in currently 
> C++98-only code paths. And changes here are needed anyway, since -ansi 
> effectively prevents you from enabling C++11 (which also suggests ICC hasn't 
> been tested in quite a while).
>
> 
> Ivan Čukić wrote:
> +1
> 
> Stephen Kelly wrote:
> Fair enough.
> 
> I don't recommend releasing ecm with this though.
> 
> I don't see any reason to release ecm when releasing KArchive and 
> Threadweaver. I recommend just copying needed files into the first release of 
> those instead.
> 
> Alexander Neundorf wrote:
> I.e. both will have copies of ECMSetupVersion.cmake, 
> ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and 
> KDECMakeSettings.cmake ?
> This is just so much against what was originally, at least my, idea of 
> e-c-m: make cmake stuff we have in KDE, but which can be useful also in other 
> projects, easier and quicker available to others (instead of not being able 
> to release it when the first frameworks are released).
> But I don't object, it's your decision.
>

It's not my decision either. It's just a recommendation.


- Stephen


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113373/#review42130
---


On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113373/
> ---
> 
> (Updated Oct. 21, 2013, 6:51 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Enable C++11 support by default.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d 
> 
> Diff: http://git.reviewboard.kde.org/r/113373/diff/
> 
> 
> Testing
> ---
> 
> Compiles, all required fixes have been integrated into the frameworks branch 
> by now (at least for the subset I have the required dependencies for).
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113406: Add a macro to automatically generate forward headers

[Stephen Kelly]

> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 11
> > 
> >
> > I really think the answers to my questions here need to be found first:
> > 
> >  http://thread.gmane.org/gmane.comp.kde.cvs/1272841
> > 
> > It should be more-simple than it currently is.
> 
> Aleix Pol Gonzalez wrote:
> I think that this patch answers most of these questions, leaving up to 
> discussion if we expect people to include "module/something.h" or just 
> "something.h".
> 
> I'd say that if Qt5 transition teaches something is that it's not very 
> flexible to namespace the include files, but that's up to the developer 
> anyway...

I'm not sure it does...

For example, grantlee installs headers like this:

 include/grantlee/engine.h
 include/grantlee_export.h

include/grantlee/engine.h has include "grantlee_export.h" and even if it is 
, the intent is that the user only needs -Iinclude/, and 
does not need -Iinclude/grantlee.

The same is not true of where KF5 installs headers and how they are included. 
There is scope for improvement there, and this patch does not affect that.


> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 29
> > 
> >
> > This variable shouldn't be needed at all.
> 
> Aleix Pol Gonzalez wrote:
> Variable? Or argument? Why?

Argument, yes, sorry.

I think that because the source dir is already in the 
INTERFACE_INCLUDE_DIRECTORIES of the target, there is no need to have to 
specify it, and there should be no need to use ${EGH_HEADERS_DIR}/ in the 
generated include.

I guess you have some reason for doing that, but that just points to 
non-uniformity which should maybe be fixed, as I wrote in the KIO commit I 
linked to.


> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 32
> > 
> >
> > I recommend not putting this in the API of the function, and instead 
> > users should use 
> > 
> >  install(DIRECTORY) to install the generated files.
> 
> Aleix Pol Gonzalez wrote:
> Why?

I think it's better API. It's what all existing functions which generate 
headers do.


- Stephen


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---


On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113406/
> ---
> 
> (Updated Oct. 24, 2013, 1:40 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Create a macro that will generate the forward headers like we used to, in 
> cmake configure time.
> 
> Here's an example of how we'd port KParts to that macro: 
> http://paste.opensuse.org/9880051
> After the change, these are the installed headers: 
> http://paste.opensuse.org/90980400
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113406/diff/
> 
> 
> Testing
> ---
> 
> Ported KParts and still everything works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Ivan Čukić]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.
> 
> Thomas Lübking wrote:
> Isn't the splash screen supposed to cover (also) those loading costs?
> If the splashscreen took like 5 seconds to load but then could finish in 
> 500ms, we would simply not require a splash screen in the first place.
> 
> Martin Klapetek wrote:
> I've never done any (useful) startup benchmarks, but I'd be happy to try. 
> Can you suggest some ways to measure cold startup time? Then I'll test both 
> and post my findings.
> 
> Ivan Čukić wrote:
> If loading Qt took 5 seconds, loading the rest would take 10 minutes.
> 
> As I said "doesn't seem to be noticeably slower".
> 
> Sebastian Kügler wrote:
> echo 1 > /proc/sys/vm/drop_caches
> 
> Clears all filesystem caches, so that everything has to be loaded from 
> disk, that's essentially what you have after a cold boot.
> 
> Fredrik Höglund wrote:
> > but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> It was a long time ago, but that doesn't mean you should undo what
> is essentially a bug fix without checking if the bug is still
> reproducible.
> 
> > It should not slow down the boot - if it does start slower than 
> ksplashx, it speeds up loading the workspace for the same amount by having Qt 
> preloaded.
> 
> The point isn't whether it slows down the boot process or not,
> the point is that the splash screen should appear immediately
> so the user isn't left staring at a blank screen for N seconds.
>

This is a review for a patch. It is really not the place for discussing the 
pros and cons of ksplashqml. If anyone wants to maintain ksplashx and create 
ksplashwayland, they are free to do so.


- Ivan


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-de

Re: Porting away from KLocale

[Albert Astals Cid]

El Dijous, 24 d'octubre de 2013, a les 17:44:01, Kevin Ottens va escriure:
> On Thursday 24 October 2013 16:56:47 John Layt wrote:
> > On 24 October 2013 07:33, Kevin Ottens  wrote:
> > > On Wednesday 23 October 2013 20:40:19 John Layt wrote:
> > >> * The obviously place to move it is k18n, as either part of
> > >> KLocalizedString or in a new KByteFormatter class?
> > > 
> > > Hm, wouldn't that fit in KCoreAddons?
> > > 
> > >> * No locale file overrides the default BinaryUnitDialect, so we only
> > >> have to worry about reading any user override from kglobals
> > > 
> > > Or have that done by the caller (thinking about KCoreAddons there, it
> > > couldn't use KConfig for the default).
> > 
> > Well, that becomes the central question then, if we allow users to set
> > a global override or not?  I don't think its very useful to tell all
> > apps that they need to read the global config themselves to see how to
> > format the bytes, they would reasonably expect that that is what the
> > method is there to hide from them.  It would effectively become an
> > application-level setting depending on if the app decides to read the
> > config.  On the other hand, if Qt eventually gains support it can use
> > the setting from there.  If we're happy to ignore user settings for
> > now then KCoreAddons will be fine.
> 
> I think we can go this route. Worst case we can channel the default setting
> through a dynamic property on the application object which would be set by
> the platform theme plugin. We used to do that for some other features.

I understand you guys want to make things as low in tiering as possible to 
ease the reuse of stuff, but can you please also think about those of use that 
want to deliver a consistent desktop where it makes sense that all the apps 
use the same way of calculating the KB? Maybe we can have one function that 
does not depend on KConfig and one that does for those of us that want the 
consistency/ease of use?

Cheers,
  Albert

> 
> Cheers.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Fredrik Höglund]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.
> 
> Thomas Lübking wrote:
> Isn't the splash screen supposed to cover (also) those loading costs?
> If the splashscreen took like 5 seconds to load but then could finish in 
> 500ms, we would simply not require a splash screen in the first place.
> 
> Martin Klapetek wrote:
> I've never done any (useful) startup benchmarks, but I'd be happy to try. 
> Can you suggest some ways to measure cold startup time? Then I'll test both 
> and post my findings.
> 
> Ivan Čukić wrote:
> If loading Qt took 5 seconds, loading the rest would take 10 minutes.
> 
> As I said "doesn't seem to be noticeably slower".
> 
> Sebastian Kügler wrote:
> echo 1 > /proc/sys/vm/drop_caches
> 
> Clears all filesystem caches, so that everything has to be loaded from 
> disk, that's essentially what you have after a cold boot.

> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.

It was a long time ago, but that doesn't mean you should undo what
is essentially a bug fix without checking if the bug is still
reproducible.

> It should not slow down the boot - if it does start slower than ksplashx, it 
> speeds up loading the workspace for the same amount by having Qt preloaded.

The point isn't whether it slows down the boot process or not,
the point is that the splash screen should appear immediately
so the user isn't left staring at a blank screen for N seconds.


- Fredrik


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Sebastian Kügler]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.
> 
> Thomas Lübking wrote:
> Isn't the splash screen supposed to cover (also) those loading costs?
> If the splashscreen took like 5 seconds to load but then could finish in 
> 500ms, we would simply not require a splash screen in the first place.
> 
> Martin Klapetek wrote:
> I've never done any (useful) startup benchmarks, but I'd be happy to try. 
> Can you suggest some ways to measure cold startup time? Then I'll test both 
> and post my findings.
> 
> Ivan Čukić wrote:
> If loading Qt took 5 seconds, loading the rest would take 10 minutes.
> 
> As I said "doesn't seem to be noticeably slower".

echo 1 > /proc/sys/vm/drop_caches

Clears all filesystem caches, so that everything has to be loaded from disk, 
that's essentially what you have after a cold boot.


- Sebastian


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Ivan Čukić]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.
> 
> Thomas Lübking wrote:
> Isn't the splash screen supposed to cover (also) those loading costs?
> If the splashscreen took like 5 seconds to load but then could finish in 
> 500ms, we would simply not require a splash screen in the first place.
> 
> Martin Klapetek wrote:
> I've never done any (useful) startup benchmarks, but I'd be happy to try. 
> Can you suggest some ways to measure cold startup time? Then I'll test both 
> and post my findings.

If loading Qt took 5 seconds, loading the rest would take 10 minutes.

As I said "doesn't seem to be noticeably slower".


- Ivan


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Chusslove Illich]

> On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.
> 
> Aurélien Gâteau wrote:
> Actually, the even more ideal solution would be for ktranscript to use 
> QtScript instead of KJS. In the future we will have more and more 
> applications developed with QtQuick, so they will already link to QtScript, 
> loading another JavaScript interpreter sounds wasteful to me. Do you think 
> this is doable? I would be quite interested in helping making it happen.
> 
> Aurélien Gâteau wrote:
> Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, 
> QtQuick uses the QJS* classes from QtQML, so this is what we should be using.
> 
> Kevin Ottens wrote:
> I would definitely welcome such a port... I remember asking ktranscript 
> to be ported away from KJS. Would also make ki18n tier 1.
> 
> Aurélien Gâteau wrote:
> I started diving into this today. No change for now, but I wrote some 
> unit tests for ktranscript, so that a qjs port can be evaluated. Patchset is 
> here: http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests 
> for now. Chusslove: would you be interested in extending the test coverage?

Yes, I most certainly would be interested in extending the test coverage.
But I intended to do it "full-range", that is starting from test PO files
(which are already there), once I get to it. And first I need to document it
better :) Currently all there is is this wiki page:
http://techbase.kde.org/Localization/Concepts/Transcript

As for the port away from KJS, I have to state again that I see no value in
that. Having ki18n be tier 1 is of no use: if someone is so tight on
dependencies that using a tier 2 framework is a problem, then ki18n is the
first thing to dump in favor of built-in Qt translation system, tier 1 or
not. Note that ki18n also brings into play all the Gettext tools, as opposed
to self-contained Qt translation tools. The only possible advantage of ki18n
in tier 1 is that it can be used by tier 2 frameworks, of which there is not
much by my estimate (and between tier 1 and tier 3, I also fail to see the
reason for existence of tier 2).


- Chusslove


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113402/
> ---
> 
> (Updated Oct. 23, 2013, 4:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> KI18n depends on KJS to build the ktranscript plugin. This plugin requires an 
> internal KJS Perl script as well as headers which were not installed.
> 
> This is a 3-commit patches, which does the following:
> 
> 1. Install kjs headers
> 
> 2. Install wtf headers, using wtf/ and kjs/ in include directives (because 
> some kjs headers includes wtf headers)
> 
> 3. Fix KI18n:
> - Format top-level CMakeLists.txt according to CMake template
> - Duplicate KJS create_hash_table script
> - Add call to find_package(KJS)
> 
> Individual patches available from 
> http://agateau.com/tmp/ki18n-standalone.patch
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 5cdec94 
>   tier1/kjs/src/CMakeLists.txt 8629716 
>   tier1/kjs/src/kjs/CMakeLists.txt

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Martin Klapetek]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.
> 
> Thomas Lübking wrote:
> Isn't the splash screen supposed to cover (also) those loading costs?
> If the splashscreen took like 5 seconds to load but then could finish in 
> 500ms, we would simply not require a splash screen in the first place.

I've never done any (useful) startup benchmarks, but I'd be happy to try. Can 
you suggest some ways to measure cold startup time? Then I'll test both and 
post my findings.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113373: Enable C++11 support by default.

[Alexander Neundorf]

> On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote:
> > As far as I know, only threadweaver and karchive will be released in 
> > December. The rest of the frameworks won't be released until summer. 
> > 
> > By summer, CMake 3.0.0 will most likely be out.
> 
> Volker Krause wrote:
> while the CMake 3 solution is obviously much nicer, what are our 
> alternatives until then? The current solution is adding -std=c++0x without 
> proper compiler checks ad-hoc where needed, I think that's far worse than 
> this change. Also, it wont detect incompatibilities with C++11 in currently 
> C++98-only code paths. And changes here are needed anyway, since -ansi 
> effectively prevents you from enabling C++11 (which also suggests ICC hasn't 
> been tested in quite a while).
>
> 
> Ivan Čukić wrote:
> +1
> 
> Stephen Kelly wrote:
> Fair enough.
> 
> I don't recommend releasing ecm with this though.
> 
> I don't see any reason to release ecm when releasing KArchive and 
> Threadweaver. I recommend just copying needed files into the first release of 
> those instead.

I.e. both will have copies of ECMSetupVersion.cmake, ECMVersionHeader.h.in, 
KDEInstallDirs.cmake, KDECompilerSettings.cmake and KDECMakeSettings.cmake ?
This is just so much against what was originally, at least my, idea of e-c-m: 
make cmake stuff we have in KDE, but which can be useful also in other 
projects, easier and quicker available to others (instead of not being able to 
release it when the first frameworks are released).
But I don't object, it's your decision.


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113373/#review42130
---


On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113373/
> ---
> 
> (Updated Oct. 21, 2013, 6:51 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Enable C++11 support by default.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d 
> 
> Diff: http://git.reviewboard.kde.org/r/113373/diff/
> 
> 
> Testing
> ---
> 
> Compiles, all required fixes have been integrated into the frameworks branch 
> by now (at least for the subset I have the required dependencies for).
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Thomas Lübking]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
> We haven't done any real benchmarks, but it doesn't seem to be noticeably 
> slower.
> 
> It should not slow down the boot - if it does start slower than ksplashx, 
> it speeds up loading the workspace for the same amount by having Qt preloaded.

Isn't the splash screen supposed to cover (also) those loading costs?
If the splashscreen took like 5 seconds to load but then could finish in 500ms, 
we would simply not require a splash screen in the first place.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Aurélien Gâteau]

> On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.
> 
> Aurélien Gâteau wrote:
> Actually, the even more ideal solution would be for ktranscript to use 
> QtScript instead of KJS. In the future we will have more and more 
> applications developed with QtQuick, so they will already link to QtScript, 
> loading another JavaScript interpreter sounds wasteful to me. Do you think 
> this is doable? I would be quite interested in helping making it happen.
> 
> Aurélien Gâteau wrote:
> Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, 
> QtQuick uses the QJS* classes from QtQML, so this is what we should be using.
> 
> Kevin Ottens wrote:
> I would definitely welcome such a port... I remember asking ktranscript 
> to be ported away from KJS. Would also make ki18n tier 1.

I started diving into this today. No change for now, but I wrote some unit 
tests for ktranscript, so that a qjs port can be evaluated. Patchset is here: 
http://agateau.com/tmp/ki18n-qjs.patch but it's missing loads of tests for now. 
Chusslove: would you be interested in extending the test coverage?


- Aurélien


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113402/
> ---
> 
> (Updated Oct. 23, 2013, 4:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> KI18n depends on KJS to build the ktranscript plugin. This plugin requires an 
> internal KJS Perl script as well as headers which were not installed.
> 
> This is a 3-commit patches, which does the following:
> 
> 1. Install kjs headers
> 
> 2. Install wtf headers, using wtf/ and kjs/ in include directives (because 
> some kjs headers includes wtf headers)
> 
> 3. Fix KI18n:
> - Format top-level CMakeLists.txt according to CMake template
> - Duplicate KJS create_hash_table script
> - Add call to find_package(KJS)
> 
> Individual patches available from 
> http://agateau.com/tmp/ki18n-standalone.patch
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 5cdec94 
>   tier1/kjs/src/CMakeLists.txt 8629716 
>   tier1/kjs/src/kjs/CMakeLists.txt 9523e89 
>   tier1/kjs/src/wtf/CMakeLists.txt 83b4417 
>   tier1/kjs/src/wtf/FastMalloc.h 29a72a5 
>   tier1/kjs/src/wtf/HashCountedSet.h be3c387 
>   tier1/kjs/src/wtf/HashFunctions.h f665447 
>   tier1/kjs/src/wtf/HashMap.h ba2971c 
>   tier1/kjs/src/wtf/HashSet.h e84b349 
>   tier1/kjs/src/wtf/HashTable.h 0b2c22c 
>   tier1/kjs/src/wtf/HashTable.cpp e08d09a 
>   tier1/kjs/src/wtf/HashTraits.h 4d01726 
>   tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 
>   tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 
>   tier1/kjs/src/wtf/OwnPtr.h 188a1dc 
>   tier1/kjs/src/wtf/PassRefPtr.h 25b9906 
>   tier1/kjs/src/wtf/RefPtr.h 493ab05 
>   tier1/kjs/src/wtf/Vector.h 9b0f38a 
>   tier1/kjs/src/wtf/VectorTraits.h 31ae028 
>   tier2/ki18n/CMakeLists.txt 4cc8e30 
>   tier2/ki18n/src/CMakeLists.txt 7f8259b4 
>   tier2/ki18n/src/create_hash_table PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113402/diff/
> 
> 
> Testing
> ---
> 
> Builds within kdelibs and standalone.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
>

Re: Review Request 113423: Fix KConfigCompiler_Test::testRunning() on Windows

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113423/#review42298
---

Ship it!


Ship It!


tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp


You can pass CMAKE_EXECUTABLE_SUFFIX from cmake.


- Aleix Pol Gonzalez


On Oct. 24, 2013, 3:59 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113423/
> ---
> 
> (Updated Oct. 24, 2013, 3:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Fix KConfigCompiler_Test::testRunning() on Windows
> 
> The test expects that the executables to find have no suffix
> 
> 
> Diffs
> -
> 
>   tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp 
> 7f2697ad94ac6d433d18fb16a99ed1435433547d 
> 
> Diff: http://git.reviewboard.kde.org/r/113423/diff/
> 
> 
> Testing
> ---
> 
> Test passes.
> 
> Although IMO it might make sense to drop this test, it takes ages due to 
> spawning all those programs that do nothing useful.
> Compiling these generated files to see that they contain no errors is enough.
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Ivan Čukić]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
> but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
> interesting to do such comparisons on spinning metal.

We haven't done any real benchmarks, but it doesn't seem to be noticeably 
slower.

It should not slow down the boot - if it does start slower than ksplashx, it 
speeds up loading the workspace for the same amount by having Qt preloaded.


- Ivan


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Martin Gräßlin]

> On Oct. 24, 2013, 6:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >

but that's a long time ago, isn't it? So Moore's Law... Anyway could be 
interesting to do such comparisons on spinning metal.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


On Oct. 24, 2013, 4:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 4:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113422: Port kconfigtest and kconfignokdehometest to QStandardPaths

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113422/#review42297
---



tier1/kconfig/autotests/kconfignokdehometest.cpp


Please review what you changed.

You're removing the config directory of the test user, sounds dangerous!

Note that it was changing the value of the XDG_CONFIG_HOME before running 
the test.

I'm unsure what's the proper cross-platform fix to it.


- Aleix Pol Gonzalez


On Oct. 24, 2013, 3:55 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113422/
> ---
> 
> (Updated Oct. 24, 2013, 3:55 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Port kconfigtest and kconfignokdehometest to QStandardPaths
> 
> They relied on setting XDG_CONFIG_HOME which will not work on Windows
> 
> 
> Diffs
> -
> 
>   tier1/kconfig/autotests/kconfigtest.h 
> e0d7f7350159187e7611ddefd99d7d6faabde6ac 
>   tier1/kconfig/autotests/kconfignokdehometest.cpp 
> ce53ca58fc7e1ce5a4345cce8a17de0e05866019 
>   tier1/kconfig/autotests/kconfigtest.cpp 
> 26e6a781bedf226ef0ca0d9030e107d3c412bd35 
> 
> Diff: http://git.reviewboard.kde.org/r/113422/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 113423: Fix KConfigCompiler_Test::testRunning() on Windows

[Alexander Richardson]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113423/
---

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Fix KConfigCompiler_Test::testRunning() on Windows

The test expects that the executables to find have no suffix


Diffs
-

  tier1/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp 
7f2697ad94ac6d433d18fb16a99ed1435433547d 

Diff: http://git.reviewboard.kde.org/r/113423/diff/


Testing
---

Test passes.

Although IMO it might make sense to drop this test, it takes ages due to 
spawning all those programs that do nothing useful.
Compiling these generated files to see that they contain no errors is enough.


Thanks,

Alexander Richardson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Fredrik Höglund]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
---


What's the cold startup time like for KSplashQML compared to KSplashX?

Let's not forget that the reason KPlash was rewritten to only depend on
X + libjpeg + libpng was so that the startup time would be limited by
the time it takes to load the images for the theme.


- Fredrik Höglund


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 113424: Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()

[Alexander Richardson]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113424/
---

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Use "whoami" as the command in KDesktopFileTest::testSuccessfulTryExec()

Unlike "/bin/ls" this also works on Windows


Diffs
-

  tier1/kconfig/autotests/kdesktopfiletest.cpp 
8f2ed2047e39f4f6b5d24a620474c3894f7986cc 

Diff: http://git.reviewboard.kde.org/r/113424/diff/


Testing
---

Test passes on both linux and windows


Thanks,

Alexander Richardson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 113422: Port kconfigtest and kconfignokdehometest to QStandardPaths

[Alexander Richardson]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113422/
---

Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Port kconfigtest and kconfignokdehometest to QStandardPaths

They relied on setting XDG_CONFIG_HOME which will not work on Windows


Diffs
-

  tier1/kconfig/autotests/kconfigtest.h 
e0d7f7350159187e7611ddefd99d7d6faabde6ac 
  tier1/kconfig/autotests/kconfignokdehometest.cpp 
ce53ca58fc7e1ce5a4345cce8a17de0e05866019 
  tier1/kconfig/autotests/kconfigtest.cpp 
26e6a781bedf226ef0ca0d9030e107d3c412bd35 

Diff: http://git.reviewboard.kde.org/r/113422/diff/


Testing
---


Thanks,

Alexander Richardson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Porting away from KLocale

[Kevin Ottens]

On Thursday 24 October 2013 16:56:47 John Layt wrote:
> On 24 October 2013 07:33, Kevin Ottens  wrote:
> > On Wednesday 23 October 2013 20:40:19 John Layt wrote:
> >> * The obviously place to move it is k18n, as either part of
> >> KLocalizedString or in a new KByteFormatter class?
> > 
> > Hm, wouldn't that fit in KCoreAddons?
> > 
> >> * No locale file overrides the default BinaryUnitDialect, so we only
> >> have to worry about reading any user override from kglobals
> > 
> > Or have that done by the caller (thinking about KCoreAddons there, it
> > couldn't use KConfig for the default).
> 
> Well, that becomes the central question then, if we allow users to set
> a global override or not?  I don't think its very useful to tell all
> apps that they need to read the global config themselves to see how to
> format the bytes, they would reasonably expect that that is what the
> method is there to hide from them.  It would effectively become an
> application-level setting depending on if the app decides to read the
> config.  On the other hand, if Qt eventually gains support it can use
> the setting from there.  If we're happy to ignore user settings for
> now then KCoreAddons will be fine.

I think we can go this route. Worst case we can channel the default setting 
through a dynamic property on the application object which would be set by the 
platform theme plugin. We used to do that for some other features.

Cheers.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113406: Add a macro to automatically generate forward headers

[Aleix Pol Gonzalez]

> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 29
> > 
> >
> > This variable shouldn't be needed at all.

Variable? Or argument? Why?


> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 32
> > 
> >
> > I recommend not putting this in the API of the function, and instead 
> > users should use 
> > 
> >  install(DIRECTORY) to install the generated files.

Why?


> On Oct. 24, 2013, 1:54 p.m., Stephen Kelly wrote:
> > modules/ECMGenerateHeaders.cmake, line 11
> > 
> >
> > I really think the answers to my questions here need to be found first:
> > 
> >  http://thread.gmane.org/gmane.comp.kde.cvs/1272841
> > 
> > It should be more-simple than it currently is.

I think that this patch answers most of these questions, leaving up to 
discussion if we expect people to include "module/something.h" or just 
"something.h".

I'd say that if Qt5 transition teaches something is that it's not very flexible 
to namespace the include files, but that's up to the developer anyway...


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---


On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113406/
> ---
> 
> (Updated Oct. 24, 2013, 1:40 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Create a macro that will generate the forward headers like we used to, in 
> cmake configure time.
> 
> Here's an example of how we'd port KParts to that macro: 
> http://paste.opensuse.org/9880051
> After the change, these are the installed headers: 
> http://paste.opensuse.org/90980400
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113406/diff/
> 
> 
> Testing
> ---
> 
> Ported KParts and still everything works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Porting away from KLocale

[John Layt]

On 24 October 2013 07:33, Kevin Ottens  wrote:
> On Wednesday 23 October 2013 20:40:19 John Layt wrote:
>> * The obviously place to move it is k18n, as either part of
>> KLocalizedString or in a new KByteFormatter class?
>
> Hm, wouldn't that fit in KCoreAddons?

>> * No locale file overrides the default BinaryUnitDialect, so we only
>> have to worry about reading any user override from kglobals
>
> Or have that done by the caller (thinking about KCoreAddons there, it couldn't
> use KConfig for the default).

Well, that becomes the central question then, if we allow users to set
a global override or not?  I don't think its very useful to tell all
apps that they need to read the global config themselves to see how to
format the bytes, they would reasonably expect that that is what the
method is there to hide from them.  It would effectively become an
application-level setting depending on if the app decides to read the
config.  On the other hand, if Qt eventually gains support it can use
the setting from there.  If we're happy to ignore user settings for
now then KCoreAddons will be fine.

John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/
---

(Updated Oct. 24, 2013, 2:19 p.m.)


Status
--

This change has been marked as submitted.


Review request for kde-workspace and KDE Frameworks.


Repository: kde-workspace


Description
---

Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
if it would simply work without XLib/XCB bits at all and it does work in 
testing mode, I'm unsure if it also works after actual login, but I don't see 
why it wouldn't.

KSplash was also receiving the stage messages via XAtoms, which I replaced with 
simple DBus interface. That means that all the parts in the login sequence need 
to be updated (I'll do it) to emit dbus signal instead of sending X message. I 
used the same API as the XAtoms were using, but let me know if you think this 
could be changed. In some future I'd probably also change the stages resolution 
as it's not too robust and does not help paralelization much. I have a plan in 
my head but that's for another commit.

I'd also like to remove the old KSplashX and port its default theme to QML and 
provide together with KSplashQML as "Classic" or "KDE 4" theme.


Diffs
-

  ksplash/ksplashqml/CMakeLists.txt 8cd5305 
  ksplash/ksplashqml/SplashApp.h 3c55be9 
  ksplash/ksplashqml/SplashApp.cpp 7c528d0 
  ksplash/ksplashqml/SplashWindow.h 9680c1e 
  ksplash/ksplashqml/SplashWindow.cpp 4417643 
  ksplash/ksplashqml/SystemInfo.h 7a74554 
  ksplash/ksplashqml/main.cpp c2722ab9 
  ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
  ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 

Diff: http://git.reviewboard.kde.org/r/113415/diff/


Testing
---

Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
not sure why), all stages passes, then it terminates itself.


Thanks,

Martin Klapetek

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42283
---


This review has been submitted with commit 
90e2c0b65cce3f899d4fd5514493beaa60151f1e by Martin Klapetek to branch master.

- Commit Hook


On Oct. 24, 2013, 2:04 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:04 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Keep the Things You Forgot

[John Layt]

On 24 October 2013 14:54, Mario Fux KDE ML  wrote:

>> You probably mean dot.kde.org/2013/09/25/frameworks-5
>
> And this:
> http://dot.kde.org/2013/09/04/kde-release-structure-evolves

Yes, that explains Frameworks and Workspaces, albeit a little fuzzy on
Workspaces vs Plasma, but it kinda leaves Applications hanging, and
with good reason as we really don't know what's happening there yet.
Talking to a few people there does seem to be an interest in having a
clean-up of the modules and apps, reducing the number of apps in the
"official" release, having fewer "essential" applications of higher
quality, and killing off the "SC" name once and for all.  I'm also
keen on breaking down the whole Modules vs Extragear distinction,
they're all KDE Applications built by the same KDE Community, just
with different release schedules.  How that all might work is
something the community as a whole needs to discuss.

John.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Ivan Čukić]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42281
---

Ship it!


Looks ok. It will need testing with the startkde/startactive.

- Ivan Čukić


On Oct. 24, 2013, 2:04 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> ---
> 
> (Updated Oct. 24, 2013, 2:04 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
> if it would simply work without XLib/XCB bits at all and it does work in 
> testing mode, I'm unsure if it also works after actual login, but I don't see 
> why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced 
> with simple DBus interface. That means that all the parts in the login 
> sequence need to be updated (I'll do it) to emit dbus signal instead of 
> sending X message. I used the same API as the XAtoms were using, but let me 
> know if you think this could be changed. In some future I'd probably also 
> change the stages resolution as it's not too robust and does not help 
> paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML 
> and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> ---
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
> not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/
---

Review request for kde-workspace and KDE Frameworks.


Repository: kde-workspace


Description
---

Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try 
if it would simply work without XLib/XCB bits at all and it does work in 
testing mode, I'm unsure if it also works after actual login, but I don't see 
why it wouldn't.

KSplash was also receiving the stage messages via XAtoms, which I replaced with 
simple DBus interface. That means that all the parts in the login sequence need 
to be updated (I'll do it) to emit dbus signal instead of sending X message. I 
used the same API as the XAtoms were using, but let me know if you think this 
could be changed. In some future I'd probably also change the stages resolution 
as it's not too robust and does not help paralelization much. I have a plan in 
my head but that's for another commit.

I'd also like to remove the old KSplashX and port its default theme to QML and 
provide together with KSplashQML as "Classic" or "KDE 4" theme.


Diffs
-

  ksplash/ksplashqml/CMakeLists.txt 8cd5305 
  ksplash/ksplashqml/SplashApp.h 3c55be9 
  ksplash/ksplashqml/SplashApp.cpp 7c528d0 
  ksplash/ksplashqml/SplashWindow.h 9680c1e 
  ksplash/ksplashqml/SplashWindow.cpp 4417643 
  ksplash/ksplashqml/SystemInfo.h 7a74554 
  ksplash/ksplashqml/main.cpp c2722ab9 
  ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
  ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 

Diff: http://git.reviewboard.kde.org/r/113415/diff/


Testing
---

Theme successfully loads, displays fullscreen (Plasma panels are not covered, 
not sure why), all stages passes, then it terminates itself.


Thanks,

Martin Klapetek

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113406: Add a macro to automatically generate forward headers

[Stephen Kelly]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/#review42280
---



modules/ECMGenerateHeaders.cmake


I really think the answers to my questions here need to be found first:

 http://thread.gmane.org/gmane.comp.kde.cvs/1272841

It should be more-simple than it currently is.



modules/ECMGenerateHeaders.cmake


This variable shouldn't be needed at all.



modules/ECMGenerateHeaders.cmake


I recommend not putting this in the API of the function, and instead users 
should use 

 install(DIRECTORY) to install the generated files.


- Stephen Kelly


On Oct. 24, 2013, 1:40 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113406/
> ---
> 
> (Updated Oct. 24, 2013, 1:40 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Create a macro that will generate the forward headers like we used to, in 
> cmake configure time.
> 
> Here's an example of how we'd port KParts to that macro: 
> http://paste.opensuse.org/9880051
> After the change, these are the installed headers: 
> http://paste.opensuse.org/90980400
> 
> 
> Diffs
> -
> 
>   modules/ECMGenerateHeaders.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113406/diff/
> 
> 
> Testing
> ---
> 
> Ported KParts and still everything works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113373: Enable C++11 support by default.

[Stephen Kelly]

> On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote:
> > As far as I know, only threadweaver and karchive will be released in 
> > December. The rest of the frameworks won't be released until summer. 
> > 
> > By summer, CMake 3.0.0 will most likely be out.
> 
> Volker Krause wrote:
> while the CMake 3 solution is obviously much nicer, what are our 
> alternatives until then? The current solution is adding -std=c++0x without 
> proper compiler checks ad-hoc where needed, I think that's far worse than 
> this change. Also, it wont detect incompatibilities with C++11 in currently 
> C++98-only code paths. And changes here are needed anyway, since -ansi 
> effectively prevents you from enabling C++11 (which also suggests ICC hasn't 
> been tested in quite a while).
>
> 
> Ivan Čukić wrote:
> +1

Fair enough.

I don't recommend releasing ecm with this though.

I don't see any reason to release ecm when releasing KArchive and Threadweaver. 
I recommend just copying needed files into the first release of those instead.


- Stephen


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113373/#review42130
---


On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113373/
> ---
> 
> (Updated Oct. 21, 2013, 6:51 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Enable C++11 support by default.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d 
> 
> Diff: http://git.reviewboard.kde.org/r/113373/diff/
> 
> 
> Testing
> ---
> 
> Compiles, all required fixes have been integrated into the frameworks branch 
> by now (at least for the subset I have the required dependencies for).
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113406: Add a macro to automatically generate forward headers

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113406/
---

(Updated Oct. 24, 2013, 1:40 p.m.)


Review request for Build System, KDE Frameworks and Stephen Kelly.


Changes
---

Adopt changes proposed by Neundorf.
- Improved documentation.
- Added different arguments to configure how the macro works.


Repository: extra-cmake-modules


Description
---

Create a macro that will generate the forward headers like we used to, in cmake 
configure time.

Here's an example of how we'd port KParts to that macro: 
http://paste.opensuse.org/9880051
After the change, these are the installed headers: 
http://paste.opensuse.org/90980400


Diffs (updated)
-

  modules/ECMGenerateHeaders.cmake PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/113406/diff/


Testing
---

Ported KParts and still everything works.


Thanks,

Aleix Pol Gonzalez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Keep the Things You Forgot

[Mario Fux KDE ML]

Am Donnerstag, 24. Oktober 2013, 14.02:16 schrieb Mark:

Morning

[snip]

> You probably mean dot.kde.org/2013/09/25/frameworks-5

And this:
http://dot.kde.org/2013/09/04/kde-release-structure-evolves
 
> That would work but not if that's it. This kind of change is one that has
> to sink in over time so this has to be repeated from time to time.

Of course. That's why there are some more stories in the tube. See promo list 
and co for hints.

Best
Mario
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Some changes to buildsystem files

[Stephen Kelly]

Hello,

I've just pushed some changes to the buildsystem files. KF5 CMake config 
files no longer define a Foo_LIBRARIES variable. Instead the KF5::Foo should 
be used in target_link_libraries.

I tested the build of plasma-frameworks, kactivities, konsole and kde-
workspace after my changes and they built for me. If they don't build for 
you then replace those variables with target names or post here for help.

Thanks,

Steve.


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Kevin Ottens]

> On Oct. 23, 2013, 2:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.
> 
> Aurélien Gâteau wrote:
> Actually, the even more ideal solution would be for ktranscript to use 
> QtScript instead of KJS. In the future we will have more and more 
> applications developed with QtQuick, so they will already link to QtScript, 
> loading another JavaScript interpreter sounds wasteful to me. Do you think 
> this is doable? I would be quite interested in helping making it happen.
> 
> Aurélien Gâteau wrote:
> Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, 
> QtQuick uses the QJS* classes from QtQML, so this is what we should be using.

I would definitely welcome such a port... I remember asking ktranscript to be 
ported away from KJS. Would also make ki18n tier 1.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 2:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113402/
> ---
> 
> (Updated Oct. 23, 2013, 2:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> KI18n depends on KJS to build the ktranscript plugin. This plugin requires an 
> internal KJS Perl script as well as headers which were not installed.
> 
> This is a 3-commit patches, which does the following:
> 
> 1. Install kjs headers
> 
> 2. Install wtf headers, using wtf/ and kjs/ in include directives (because 
> some kjs headers includes wtf headers)
> 
> 3. Fix KI18n:
> - Format top-level CMakeLists.txt according to CMake template
> - Duplicate KJS create_hash_table script
> - Add call to find_package(KJS)
> 
> Individual patches available from 
> http://agateau.com/tmp/ki18n-standalone.patch
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 5cdec94 
>   tier1/kjs/src/CMakeLists.txt 8629716 
>   tier1/kjs/src/kjs/CMakeLists.txt 9523e89 
>   tier1/kjs/src/wtf/CMakeLists.txt 83b4417 
>   tier1/kjs/src/wtf/FastMalloc.h 29a72a5 
>   tier1/kjs/src/wtf/HashCountedSet.h be3c387 
>   tier1/kjs/src/wtf/HashFunctions.h f665447 
>   tier1/kjs/src/wtf/HashMap.h ba2971c 
>   tier1/kjs/src/wtf/HashSet.h e84b349 
>   tier1/kjs/src/wtf/HashTable.h 0b2c22c 
>   tier1/kjs/src/wtf/HashTable.cpp e08d09a 
>   tier1/kjs/src/wtf/HashTraits.h 4d01726 
>   tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 
>   tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 
>   tier1/kjs/src/wtf/OwnPtr.h 188a1dc 
>   tier1/kjs/src/wtf/PassRefPtr.h 25b9906 
>   tier1/kjs/src/wtf/RefPtr.h 493ab05 
>   tier1/kjs/src/wtf/Vector.h 9b0f38a 
>   tier1/kjs/src/wtf/VectorTraits.h 31ae028 
>   tier2/ki18n/CMakeLists.txt 4cc8e30 
>   tier2/ki18n/src/CMakeLists.txt 7f8259b4 
>   tier2/ki18n/src/create_hash_table PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113402/diff/
> 
> 
> Testing
> ---
> 
> Builds within kdelibs and standalone.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 112755: Reimplement KXUtils::createPixmapFromHandle with XCB

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112755/
---

(Updated Oct. 24, 2013, 12:22 p.m.)


Review request for KDE Frameworks.


Changes
---

* added a small test app which is able to render the icon of a passed in window 
id into a QLabel
* added a byte order check, if not LSB no image conversion is done
* added better depth and visual conversion. Only a small subset is checked with 
inspiration from kde-workspace/ksmserver/logouteffect.cpp

For testing I used iceweasel and xclock. Both work fine.


Repository: kdelibs


Description
---

Implements the createPixmapFromHandle by getting the image for the pixmaps and 
using it as either the Pixmap or the bitmap mask.


Diffs (updated)
-

  tier1/kwindowsystem/src/kxutils.cpp 33bd678 
  tier1/kwindowsystem/src/kxutils_p.h 84d639b 
  tier1/kwindowsystem/tests/CMakeLists.txt 5cf5868 
  tier1/kwindowsystem/tests/createpixmapfromhandletest.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/112755/diff/


Testing
---

Adjusted KWin to take this codepath and say thanks to Iceweasel for having a 
mask


Thanks,

Martin Gräßlin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Aurélien Gâteau]

> On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.
> 
> Aurélien Gâteau wrote:
> Actually, the even more ideal solution would be for ktranscript to use 
> QtScript instead of KJS. In the future we will have more and more 
> applications developed with QtQuick, so they will already link to QtScript, 
> loading another JavaScript interpreter sounds wasteful to me. Do you think 
> this is doable? I would be quite interested in helping making it happen.

Mmm, actually I am wrong, QtScript is provided for Qt 4.x compatibility, 
QtQuick uses the QJS* classes from QtQML, so this is what we should be using.


- Aurélien


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113402/
> ---
> 
> (Updated Oct. 23, 2013, 4:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> KI18n depends on KJS to build the ktranscript plugin. This plugin requires an 
> internal KJS Perl script as well as headers which were not installed.
> 
> This is a 3-commit patches, which does the following:
> 
> 1. Install kjs headers
> 
> 2. Install wtf headers, using wtf/ and kjs/ in include directives (because 
> some kjs headers includes wtf headers)
> 
> 3. Fix KI18n:
> - Format top-level CMakeLists.txt according to CMake template
> - Duplicate KJS create_hash_table script
> - Add call to find_package(KJS)
> 
> Individual patches available from 
> http://agateau.com/tmp/ki18n-standalone.patch
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 5cdec94 
>   tier1/kjs/src/CMakeLists.txt 8629716 
>   tier1/kjs/src/kjs/CMakeLists.txt 9523e89 
>   tier1/kjs/src/wtf/CMakeLists.txt 83b4417 
>   tier1/kjs/src/wtf/FastMalloc.h 29a72a5 
>   tier1/kjs/src/wtf/HashCountedSet.h be3c387 
>   tier1/kjs/src/wtf/HashFunctions.h f665447 
>   tier1/kjs/src/wtf/HashMap.h ba2971c 
>   tier1/kjs/src/wtf/HashSet.h e84b349 
>   tier1/kjs/src/wtf/HashTable.h 0b2c22c 
>   tier1/kjs/src/wtf/HashTable.cpp e08d09a 
>   tier1/kjs/src/wtf/HashTraits.h 4d01726 
>   tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 
>   tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 
>   tier1/kjs/src/wtf/OwnPtr.h 188a1dc 
>   tier1/kjs/src/wtf/PassRefPtr.h 25b9906 
>   tier1/kjs/src/wtf/RefPtr.h 493ab05 
>   tier1/kjs/src/wtf/Vector.h 9b0f38a 
>   tier1/kjs/src/wtf/VectorTraits.h 31ae028 
>   tier2/ki18n/CMakeLists.txt 4cc8e30 
>   tier2/ki18n/src/CMakeLists.txt 7f8259b4 
>   tier2/ki18n/src/create_hash_table PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113402/diff/
> 
> 
> Testing
> ---
> 
> Builds within kdelibs and standalone.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113402: Fix KI18n standalone build

[Aurélien Gâteau]

> On Oct. 23, 2013, 4:40 p.m., Chusslove Illich wrote:
> > I can only say that whatever is the proper fix here, it is fine with me.
> > Since non-installed headers are being used, maybe ki18n is using KJS in a
> > way which became deprecated somewhere along the way? If so, I've nothing
> > against fixing that instead.
> >
> 
> Aleix Pol Gonzalez wrote:
> Well the thing is that ki18n was using private API (since it was in the 
> same module, kdelibs).
> 
> Aurélien: what about installing these headers in a private/ directory?
> 
> Chusslove Illich wrote:
> If I recall, when implementing that I mimicked what khtml was doing.
> And apparently is still doing.
>
> 
> Aleix Pol Gonzalez wrote:
> khtml is in kdelibs as well, nobody has tried to build it standalone just 
> yet, I guess.
> 
> Chusslove Illich wrote:
> Right, but, how is then KJS supposed to be used in a different way? Are
> these private headers really private, or actually necessary to use KJS as 
> a
> JS interpreter in random client code?
>
> 
> Aurélien Gâteau wrote:
> The ideal solution would be for ktranscript to only use public headers, 
> but I assume there is no way to do so (I haven't taken the time to study 
> ktranscript enough to understand what it does), Chusslove, it would be 
> awesome if you could have a look at it.
> 
> If it is definitely not possible, then I am going to update my changes to 
> install to a private/ directory, like Aleix suggests.

Actually, the even more ideal solution would be for ktranscript to use QtScript 
instead of KJS. In the future we will have more and more applications developed 
with QtQuick, so they will already link to QtScript, loading another JavaScript 
interpreter sounds wasteful to me. Do you think this is doable? I would be 
quite interested in helping making it happen.


- Aurélien


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113402/#review4
---


On Oct. 23, 2013, 4:30 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113402/
> ---
> 
> (Updated Oct. 23, 2013, 4:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> KI18n depends on KJS to build the ktranscript plugin. This plugin requires an 
> internal KJS Perl script as well as headers which were not installed.
> 
> This is a 3-commit patches, which does the following:
> 
> 1. Install kjs headers
> 
> 2. Install wtf headers, using wtf/ and kjs/ in include directives (because 
> some kjs headers includes wtf headers)
> 
> 3. Fix KI18n:
> - Format top-level CMakeLists.txt according to CMake template
> - Duplicate KJS create_hash_table script
> - Add call to find_package(KJS)
> 
> Individual patches available from 
> http://agateau.com/tmp/ki18n-standalone.patch
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 5cdec94 
>   tier1/kjs/src/CMakeLists.txt 8629716 
>   tier1/kjs/src/kjs/CMakeLists.txt 9523e89 
>   tier1/kjs/src/wtf/CMakeLists.txt 83b4417 
>   tier1/kjs/src/wtf/FastMalloc.h 29a72a5 
>   tier1/kjs/src/wtf/HashCountedSet.h be3c387 
>   tier1/kjs/src/wtf/HashFunctions.h f665447 
>   tier1/kjs/src/wtf/HashMap.h ba2971c 
>   tier1/kjs/src/wtf/HashSet.h e84b349 
>   tier1/kjs/src/wtf/HashTable.h 0b2c22c 
>   tier1/kjs/src/wtf/HashTable.cpp e08d09a 
>   tier1/kjs/src/wtf/HashTraits.h 4d01726 
>   tier1/kjs/src/wtf/ListRefPtr.h 0a704d8 
>   tier1/kjs/src/wtf/OwnArrayPtr.h 3b77871 
>   tier1/kjs/src/wtf/OwnPtr.h 188a1dc 
>   tier1/kjs/src/wtf/PassRefPtr.h 25b9906 
>   tier1/kjs/src/wtf/RefPtr.h 493ab05 
>   tier1/kjs/src/wtf/Vector.h 9b0f38a 
>   tier1/kjs/src/wtf/VectorTraits.h 31ae028 
>   tier2/ki18n/CMakeLists.txt 4cc8e30 
>   tier2/ki18n/src/CMakeLists.txt 7f8259b4 
>   tier2/ki18n/src/create_hash_table PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113402/diff/
> 
> 
> Testing
> ---
> 
> Builds within kdelibs and standalone.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Config files naming policy

[David Faure]

On Wednesday 23 October 2013 19:37:21 Ivan Čukić wrote:
> I guess I'll rename my config file then. I've been using activitymanagerrc,
> while the binary was actually prefixed with a 'k' and suffixed with a 'd'.

Hmm, if you use KGlobal::config() (in kde4) or KSharedConfig::openConfig() (in 
KF5), the name of the config file would be automatically generated from the 
application name.

(assuming this is about an application like the daemon, not a library)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Keep the Things You Forgot

[Mario Fux KDE ML]

Am Mittwoch, 23. Oktober 2013, 21.49:27 schrieb Mark:

Morning

[snip]

> A blog post that i'd very much like from you (Aaron) is about the next
> big KDE version, the naming and how the complete collection is going
> to be called or if there even will be a collection release (what KDE
> SC is now). Press is still getting that wrong, i tend to get it wrong
> and other people talking about KDE seem to get it wrong. Usually it's
> just being referred to as "KDE 5" which is wrong. (Frameworks 5,
> Plasma 2, ...). So if you have the time, a blog about that would be
> wonderful and very educational ^_^

What about all the recent dot articles about KF5, Plasma 2 and Co? I think you 
won't get it clearer than that.

Best 
Mario
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kio kfilewidget.h problem

[David Faure]

On Wednesday 23 October 2013 11:10:17 Treeve Jelbert wrote:
> kio installs kfilewidget.h which references kio/kiofilewidgets_export.h
> which is not installed

Fixed, thanks for the report.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 113370: move KDED to Tier3

[David Faure]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113370/#review42261
---



kded/CMakeLists.txt


"should be replaced with"? it already is



kded/CMakeLists.txt


Why not use the version number of *this* framework? The same risks for 
discrepancies exist whichever framework is used for the version checking.



kioslave/http/kcookiejar/CMakeLists.txt


ok, we'll have to change that, obviously.

kded should install that xml file, and kcookiejar should use the installed 
xml file (or the one from tier3/kded when building kdelibs all-in-one)


- David Faure


On Oct. 21, 2013, 3:56 p.m., Àlex Fiestas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113370/
> ---
> 
> (Updated Oct. 21, 2013, 3:56 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Moves KDED to tier3.
> 
> I have removed any use of X11/Properties used to communicate with KSplash 
> since we want to use either DBus or Wayland but certainly not X11.
> 
> I plan to work on session startup in a few weeks so I will fix (if nobody 
> else does before me) KSplash <---> KDED communication by then.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4ea56ae 
>   kded/CMakeLists.txt a06ed09 
>   kded/DESIGN  
>   kded/HOWTO  
>   kded/Info.plist.template  
>   kded/Mainpage.dox  
>   kded/README.kded  
>   kded/config-kded.h.cmake 21210ab 
>   kded/kded.h  
>   kded/kded.cpp aab548b 
>   kded/kdedadaptor.h  
>   kded/kdedadaptor.cpp  
>   kded/kdedmodule.desktop  
>   kded/org.kde.kded5.service.in  
>   kioslave/http/kcookiejar/CMakeLists.txt 8d61c01 
>   tier3/CMakeLists.txt eed8acb 
> 
> Diff: http://git.reviewboard.kde.org/r/113370/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Àlex Fiestas
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel