Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC

[Kevin Funk]

> On Aug. 27, 2015, 9:57 p.m., Patrick Spendrin wrote:
> > Wait, Wait, Wait.
> > 1) The difference between console apps and GUI apps is that console apps 
> > actually have stdin, stdout and stderr streams. So using or not using a 
> > console app actually depends on if you need to have these streams!
> > 2) In kde4 (as in standard cmake) the default when you use add_executable 
> > is a console application, and if you add WIN32 you'll get a GUI 
> > application. In kf5 it was decided that it makes much more sense to mark 
> > non-gui applications explicitly, similar to how it is done in qmake (CONFIG 
> > += CONSOLE); this is done by the set_target_properties or the ecm macro.
> > About your problem of console windows: there is a different solution for 
> > that (it depends on the way the executables are run in QProcess), but I 
> > would need to look into the KDE4 code which starts kdeinit4.exe. kdeinit4 
> > *is* a console app.

@Patrick: So what's the proper solution? 

I'd really like to get this fixed. It's a big show-stopper on Windows.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124905/#review84496
---


On Aug. 27, 2015, 7:31 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124905/
> ---
> 
> (Updated Aug. 27, 2015, 7:31 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn 
> Rempt.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Win: Hide console window for binaries in LIBEXEC
> 
> 
> Diffs
> -
> 
>   src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc 
>   src/ioslaves/http/kcookiejar/CMakeLists.txt 
> 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 
>   src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 
>   src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e 
>   src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc 
> 
> Diff: https://git.reviewboard.kde.org/r/124905/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 126343: KPluginMetaData: Add fields used by KAboutData and introduce conversion function

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126343/#review89480
---


Just a few nitpicks. Rest looks good to me.


src/lib/kaboutdata.h (line 979)
<https://git.reviewboard.kde.org/r/126343/#comment61241>

Can't you move that into `KAboutData::Private`? What am I missing?

Polluting the public header otherwise.



src/lib/plugin/kpluginmetadata.h (line 72)
<https://git.reviewboard.kde.org/r/126343/#comment61240>

Duplicated documentation.

Just `\sa KAboutPerson::fromJSON`?


- Kevin Funk


On Dec. 14, 2015, 11:45 a.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126343/
> ---
> 
> (Updated Dec. 14, 2015, 11:45 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Add KPluginMetaData::translators() and KAboutPerson::fromJson()
> 
> Plugins could have a list of translators in KDE4 through KAboutData so
> this commit restores this for KF5. As a side effect of now having
> authors() and translators() returning a list of KAboutPerson I also
> added KAboutPerson::fromJSON() as publc function but I can make that
> internal API instead if it's preferred.
> 
> --- 
> 
> Add KPluginMetaData::copyrightText(), extraInformation() and 
> otherContributors()
> 
> Now KPluginMetaData has well defined keys for all the information used
> by KAboutData. This means we can easily create KAboutData objects from
> a KPluginMetaData object e.g. for use in an KAboutApplicationDialog.
> For example Okular uses this to display information about generator that
> is being used for the current document.
> 
> ---
> 
> Add KAboutData::fromPluginMetaData(const KPluginMetaData &plugin)
> 
> This is useful e.g. to create an KAboutApplicationDialog for plugins
> 
> 
> Diffs
> -
> 
>   autotests/kpluginmetadatatest.cpp 25c8b8d5351eb5c5c784d528f9e90dfc8ea77982 
>   src/lib/kaboutdata.h 0dbd7a0ce7ec9220614c5f824a0f379ea5f45559 
>   src/lib/kaboutdata.cpp 5d9a55ea027fc1b8fb6e6394d72cf48f142bb664 
>   src/lib/plugin/kpluginmetadata.h a91b94ad404b6839aa3b8d13b8da19f407708c1b 
>   src/lib/plugin/kpluginmetadata.cpp 36743600788693b6449d065f0448e3195445772e 
> 
> Diff: https://git.reviewboard.kde.org/r/126343/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, used by KAboutApplicationDialog in okular: 
> https://git.reviewboard.kde.org/r/126193/
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

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

Re: Review Request 126343: KPluginMetaData: Add fields used by KAboutData and introduce conversion function

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126343/#review89815
---

Ship it!


My nitpicks have been resolved, a weak +1 from my side (other reviewers 
welcome).

- Kevin Funk


On Dec. 21, 2015, 9:45 a.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126343/
> ---
> 
> (Updated Dec. 21, 2015, 9:45 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Add KPluginMetaData::translators() and KAboutPerson::fromJson()
> 
> Plugins could have a list of translators in KDE4 through KAboutData so
> this commit restores this for KF5. As a side effect of now having
> authors() and translators() returning a list of KAboutPerson I also
> added KAboutPerson::fromJSON() as publc function but I can make that
> internal API instead if it's preferred.
> 
> --- 
> 
> Add KPluginMetaData::copyrightText(), extraInformation() and 
> otherContributors()
> 
> Now KPluginMetaData has well defined keys for all the information used
> by KAboutData. This means we can easily create KAboutData objects from
> a KPluginMetaData object e.g. for use in an KAboutApplicationDialog.
> For example Okular uses this to display information about generator that
> is being used for the current document.
> 
> ---
> 
> Add KAboutData::fromPluginMetaData(const KPluginMetaData &plugin)
> 
> This is useful e.g. to create an KAboutApplicationDialog for plugins
> 
> 
> Diffs
> -
> 
>   autotests/kpluginmetadatatest.cpp 25c8b8d5351eb5c5c784d528f9e90dfc8ea77982 
>   src/lib/kaboutdata.h 0dbd7a0ce7ec9220614c5f824a0f379ea5f45559 
>   src/lib/kaboutdata.cpp 5d9a55ea027fc1b8fb6e6394d72cf48f142bb664 
>   src/lib/plugin/kpluginmetadata.h a91b94ad404b6839aa3b8d13b8da19f407708c1b 
>   src/lib/plugin/kpluginmetadata.cpp 36743600788693b6449d065f0448e3195445772e 
> 
> Diff: https://git.reviewboard.kde.org/r/126343/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, used by KAboutApplicationDialog in okular: 
> https://git.reviewboard.kde.org/r/126193/
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

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

Review Request 126453: Fix library order

[Kevin Funk]

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

Review request for KDE Frameworks, Heiko Becker and Jeremy Whiting.


Repository: knewstuff


Description
---

Fixes issues leading to creation of QTBUG-47240


Diffs
-

  src/CMakeLists.txt cc606444e48b0e519551183c022ccecdac0aa62f 

Diff: https://git.reviewboard.kde.org/r/126453/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126453: Fix library order

[Kevin Funk]

> On Dec. 21, 2015, 4:33 p.m., Hrvoje Senjan wrote:
> > A public header here (DownloadWidget) includes QWidget

Qt5::Widgets is still in PUBLIC scope


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126453/#review89837
---


On Dec. 21, 2015, 4:06 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126453/
> ---
> 
> (Updated Dec. 21, 2015, 4:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Heiko Becker and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Fixes issues leading to creation of QTBUG-47240
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt cc606444e48b0e519551183c022ccecdac0aa62f 
> 
> Diff: https://git.reviewboard.kde.org/r/126453/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 126453: Fix library order

[Kevin Funk]

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

(Updated Jan. 1, 2016, 11 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Heiko Becker and Jeremy Whiting.


Changes
---

Submitted with commit 38685ad63b08a6c1c4de2c2ecd525188aecd3e94 by Kevin Funk to 
branch master.


Repository: knewstuff


Description
---

Fixes issues leading to creation of QTBUG-47240


Diffs
-

  src/CMakeLists.txt cc606444e48b0e519551183c022ccecdac0aa62f 

Diff: https://git.reviewboard.kde.org/r/126453/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126617: (kxmlgui) Fix compilation: QStringLiteral and multistring parameter do not mix on Windows

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126617/#review90490
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 3, 2016, 12:57 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126617/
> ---
> 
> (Updated Jan. 3, 2016, 12:57 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string. (Copy 
> pasted from Patrick Spendrin's RR)
> 
> Joining the strings here.
> 
> 
> Diffs
> -
> 
>   src/kbugreport.cpp b43f3c4 
> 
> Diff: https://git.reviewboard.kde.org/r/126617/diff/
> 
> 
> Testing
> ---
> 
> Compiles again on windows
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 126616: (ktextwidgets) Fix compilation: QStringLiteral and multistring parameter do not mix on Windows

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126616/#review90491
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 3, 2016, 12:53 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126616/
> ---
> 
> (Updated Jan. 3, 2016, 12:53 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: ktextwidgets
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string. (Copy 
> pasted from Patrick Spendrin's RR)
> 
> Replacing QStringLitearl() with QLatin1String()
> 
> 
> Diffs
> -
> 
>   src/widgets/krichtextedit.cpp 805fbe3 
> 
> Diff: https://git.reviewboard.kde.org/r/126616/diff/
> 
> 
> Testing
> ---
> 
> Compiles again on windows
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 126615: (knewstuff) Fix compilation: QStringLiteral and multistring parameter do not mix on Windows

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126615/#review90492
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 3, 2016, 12:51 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126615/
> ---
> 
> (Updated Jan. 3, 2016, 12:51 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string. (Copy 
> pasted from Patrick Spendrin's RR)
> 
> Replacing QStringLitearl() with QLatin1String()
> 
> 
> Diffs
> -
> 
>   src/ui/itemsviewdelegate.cpp 8a891ba 
> 
> Diff: https://git.reviewboard.kde.org/r/126615/diff/
> 
> 
> Testing
> ---
> 
> Compiles again on windows
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 126614: (Ki18n) Fix compilation: QStringLiteral and multistring parameter do not mix on Windows

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126614/#review90493
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 3, 2016, 12:45 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126614/
> ---
> 
> (Updated Jan. 3, 2016, 12:45 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string. (Copy 
> pasted from Patrick Spendrin's RR)
> 
> Joining the strings here.
> 
> 
> Diffs
> -
> 
>   src/kuitmarkup.cpp 9831b34 
> 
> Diff: https://git.reviewboard.kde.org/r/126614/diff/
> 
> 
> Testing
> ---
> 
> Compiles again on windows
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 126695: Fix clang warning about implicit copy ctor and explicit operator=.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126695/#review90838
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 10, 2016, 11:03 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126695/
> ---
> 
> (Updated Jan. 10, 2016, 11:03 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> QList calls both, so both are needed, but indeed operator= means the
> members can't be const. Let's just remove the const for the members
> rather than use const_cast.
> 
> Change-Id: I9e749a448dc69439ba34ceed31fd7f0032f68c3b
> 
> 
> Diffs
> -
> 
>   src/core/ksslcertificatemanager_p.h 
> 0b9a85d6f05b93dbe8e80962401dff5ca73617f8 
> 
> Diff: https://git.reviewboard.kde.org/r/126695/diff/
> 
> 
> Testing
> ---
> 
> It compiles.
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Review Request 126745: Fix karchive autotests on Windows

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: karchive


Description
---

Still not perfect (no proper dependencies set), but better:
* Moves from CMake time to post-build time of kcompressiondevicetest
* Moves the test data to the actual output dir of kcompressiondevicetest

Still doesn't regenerate the data in case examples/ changes.


Diffs
-

  autotests/CMakeLists.txt 39881f90c614200a6c840b67d14e6c518f8e57e9 

Diff: https://git.reviewboard.kde.org/r/126745/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126764: Workaround for leading slash returned by QUrl::toDisplayString(QUrl::PreferLocalFile) untill fixed in Qt

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126764/#review91214
---



I have a fix: https://codereview.qt-project.org/#/c/145963/

Feel free to patch your self-built Qt on Windows for now... :)

- Kevin Funk


On Jan. 15, 2016, 10:30 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126764/
> ---
> 
> (Updated Jan. 15, 2016, 10:30 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> The KUrlRequester has an extra leading slash when a local url is set. This is 
> due to strange behaviour of QUrl::toDisplayString(QUrl::PreferLocalFile) on 
> Windows. There is a bug report for the problem on 
> https://bugreports.qt.io/browse/QTBUG-41729 but somebody has to do the actual 
> fixing ;) Untill it is fixed this is a workaround for this place.
> 
> 
> Diffs
> -
> 
>   src/widgets/kurlrequester.cpp 06e9ddb 
> 
> Diff: https://git.reviewboard.kde.org/r/126764/diff/
> 
> 
> Testing
> ---
> 
> Kate on windows does not now have a leading slash in the Search in files 
> KUrlRequester
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 126745: Fix karchive autotests on Windows

[Kevin Funk]

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

(Updated Jan. 18, 2016, 4:58 p.m.)


Review request for KDE Frameworks and Patrick Spendrin.


Repository: karchive


Description
---

Still not perfect (no proper dependencies set), but better:
* Moves from CMake time to post-build time of kcompressiondevicetest
* Moves the test data to the actual output dir of kcompressiondevicetest

Still doesn't regenerate the data in case examples/ changes.


Diffs (updated)
-

  autotests/CMakeLists.txt 39881f90c614200a6c840b67d14e6c518f8e57e9 

Diff: https://git.reviewboard.kde.org/r/126745/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126745: Fix karchive autotests on Windows

[Kevin Funk]

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

(Updated Jan. 20, 2016, 8:59 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Patrick Spendrin.


Changes
---

Submitted with commit 123235fc5f036e42afce90bce7d1c06742679080 by Kevin Funk to 
branch master.


Repository: karchive


Description
---

Still not perfect (no proper dependencies set), but better:
* Moves from CMake time to post-build time of kcompressiondevicetest
* Moves the test data to the actual output dir of kcompressiondevicetest

Still doesn't regenerate the data in case examples/ changes.


Diffs
-

  autotests/CMakeLists.txt 39881f90c614200a6c840b67d14e6c518f8e57e9 

Diff: https://git.reviewboard.kde.org/r/126745/diff/


Testing
---


Thanks,

Kevin Funk

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

Review Request 126969: KRecursiveFilterProxyModel::match: Fix crash

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

As seen in GammaRay


Diffs
-

  src/krecursivefilterproxymodel.cpp dbb6eba421c0e680fffe43582f210ea3e42e6e7f 

Diff: https://git.reviewboard.kde.org/r/126969/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126969: KRecursiveFilterProxyModel::match: Fix crash

[Kevin Funk]

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

(Updated Feb. 2, 2016, 8:41 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Volker Krause.


Changes
---

Submitted with commit 11055706bca380b75da48b8f5d4c27c53d86372d by Kevin Funk to 
branch master.


Repository: kitemmodels


Description
---

As seen in GammaRay


Diffs
-

  src/krecursivefilterproxymodel.cpp dbb6eba421c0e680fffe43582f210ea3e42e6e7f 

Diff: https://git.reviewboard.kde.org/r/126969/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 127031: Add function to get runtime frameworks version information

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review92564
---




src/lib/kcoreaddons.h (line 38)
<https://git.reviewboard.kde.org/r/127031/#comment63107>

Maybe also add a hint / some code which shows how to use that uint? I.e. 
point to Qt's QT_VERSION_CHECK documentation or copy/paste it.


- Kevin Funk


On Feb. 19, 2016, 12:46 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 19, 2016, 12:46 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 127177: Compilation fixes for MSVC (2013)

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127177/#review92805
---


Fix it, then Ship it!





src/kcatalog.cpp (line 46)
<https://git.reviewboard.kde.org/r/127177/#comment63232>

Remove indentation. Same below.


- Kevin Funk


On Feb. 25, 2016, 5:16 p.m., Thomas Friedrichsmeier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127177/
> ---
> 
> (Updated Feb. 25, 2016, 5:16 p.m.)
> 
> 
> Review request for KDE Frameworks and kdewin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fix compilation on Windows with MSVC.
> 
> a) MSVC accepts declspec at global scope, only.
> b) QStringLiteral does not work with concatenated literals in MSVC (see 
> http://blog.qt.io/blog/2014/06/13/qt-weekly-13-qstringliteral/). Since the 
> occurences seem to be mostly for debugging, going through 
> QString::fromLatin1() in these cases should not hurt much.
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 083443d 
>   src/ktranscript.cpp 72c3755 
> 
> Diff: https://git.reviewboard.kde.org/r/127177/diff/
> 
> 
> Testing
> ---
> 
> Now builds with MSVC 2013.
> 
> No other compilers and no other platforms tested for this patch.
> 
> 
> Thanks,
> 
> Thomas Friedrichsmeier
> 
>

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

Re: Review Request 127211: Properly use static QMaps

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127211/#review92877
---


Ship it!




Ship It!

- Kevin Funk


On Feb. 28, 2016, 9:52 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127211/
> ---
> 
> (Updated Feb. 28, 2016, 9:52 p.m.)
> 
> 
> Review request for Kate and KDE Frameworks.
> 
> 
> Repository: ktexteditor
> 
> 
> Description
> ---
> 
> Only initialize them once.
> Since they're not const, use ::value rather than ::operator[], because the 
> latter will provide a default-constructed object and add it to the map.
> 
> 
> Diffs
> -
> 
>   src/vimode/cmds.cpp 7804af4 
> 
> Diff: https://git.reviewboard.kde.org/r/127211/diff/
> 
> 
> Testing
> ---
> 
> 
> 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 127265: Fix windows build of Ki18n

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/#review93140
---


Ship it!




Ship It!

- Kevin Funk


On March 3, 2016, 5:49 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127265/
> ---
> 
> (Updated March 3, 2016, 5:49 p.m.)
> 
> 
> Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
> implentations.) Unrelated Windows changes were requested and then introduced 
> which in my opinion were wrong (and in the opinion of my compiler ;-) ).
> 
> You can't just do an extern "C" dllimport declaration inside a function body:
> 
> src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
>  extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;
> 
> 
> Also that patch changed the Logic from an MSVC specific define to general 
> Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW 
> I'm pretty sure that the ifndef _MSC_VER was there for a reason.
> 
> This patch reverts the declaration move and logic change while keeping the 
> __USE_GNU_GETTEXT guard.
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 083443d 
> 
> Diff: https://git.reviewboard.kde.org/r/127265/diff/
> 
> 
> Testing
> ---
> 
> Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
> GNU/Linux.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: Review Request 127334: Fix build with -DBUILD_TEST=TRUE

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127334/#review93396
---


Ship it!




Ship It!

- Kevin Funk


On March 10, 2016, 7:04 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127334/
> ---
> 
> (Updated March 10, 2016, 7:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Dario Freddi and Martin Gräßlin.
> 
> 
> Repository: polkit-qt-1
> 
> 
> Description
> ---
> 
> Otherwise it fails with "test/test.cpp:49:14: error: 'qVariantValue'
> was not declared in this scope". qVariantValue is a obsolete
> workaround for MSVC 6, which was released 1998 and thus seems ancient
> enough to change this.
> 
> 
> Diffs
> -
> 
>   test/test.cpp afb7f64333e1122d86d2692f9cbaa94a08bec800 
> 
> Diff: https://git.reviewboard.kde.org/r/127334/diff/
> 
> 
> Testing
> ---
> 
> Builds at least. The test doesn't run successfully though (Totals: 6 passed, 
> 3 failed, 0 skipped, 0 blacklisted). I doubt it did before. There's also no 
> target to run it.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

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

Re: Review Request 127236: Leverage QDir to know what's in a KIconThemeDir

[Kevin Funk]

> On March 1, 2016, 4:37 p.m., Aleix Pol Gonzalez wrote:
> > Eh... I just realized it's not 100% correct. We have a test 
> > (testUnknownIconNotCached) that fails, unsure how I didn't see it yesterday.
> > 
> > The problem with this one is that we are not reacting when icons are 
> > introduced at runtime. I tried adding a sneaky QFileSystemWatcher/KDirWatch 
> > on KIconTheme but it didn't signal.
> > 
> > Should I just discard the patch?
> 
> David Edmundson wrote:
> Could you compare modified time of mBaseDirThemeDir and reload if needed?
> it'd be one extra stat on the directory each time, but still a saving 
> from before
> 
> Aleix Pol Gonzalez wrote:
> That doesn't work, for some reason...
> ```
>  // Install the existing icon by copying.
> +qDebug() << "1" << 
> QFileInfo(actionIconsDir).lastModified();
>  QVERIFY(QFile::copy(QStringLiteral(":/test-22x22.png"), 
> newIconPath));
> +qDebug() << "2" << 
> QFileInfo(actionIconsDir).lastModified();
> ```
> 
> Both return the same value.
> 
> Nick Shaforostoff wrote:
> there is a difference between changing a file from inside the program and 
> changing it from outside.
> 
> did you make the change externally when testing QFileSystemWatcher-based 
> solution?
> 
> Nick Shaforostoff wrote:
> also for the QFileInfo::lastModified() there may be just not enough time 
> between the tests, so try adding a 2-minute sleep there
> 
> David Faure wrote:
> QFileInfo::lastModified() doesn't include milliseconds yet. There is a 
> pending patch for Qt to implement that (as part of a much bigger task which 
> also adds QFile::setFileTime()), but yeah, that's the problem. Right now you 
> need a 1s sleep whenever unittesting changes to lastModified().
> 
> QTest::qWait(1000); // remove this once lastModified includes ms
> 
> Or at least "up to 1s, until the end of the current second", I have code 
> for that in the kdirwatch unittest for instance.
> 
> Another alternative, hacking the modification time on files (using utime, 
> like I do in ksycocatest.cpp)
> 
> (all this to avoid tests that take 15 seconds in total, I like the policy 
> that a test should run in under 5s -- otherwise people stop running them)
> 
> Nick Shaforostoff wrote:
> so, any news on this one?
> 
> Nick Shaforostoff wrote:
> even simple solution of discarding the cache after certain point of time 
> (e.g. 10 seconds) and going uncached code path would give us the benefit 
> without introducing regression, right?

/me likes that idea. You could make the cache lifetime configurable via 
environment variables, and set that to the minimum for the 
`testUnknownIconNotCached` test.

@Apol: Awesome idea indeed, this reduces a lot of strain on the file system!


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127236/#review93023
---


On March 1, 2016, 3:25 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127236/
> ---
> 
> (Updated March 1, 2016, 3:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> At the moment we're playing Battleship to see if an icon is present in a 
> subdirectory. This means that we are checking on every directory if there's 
> an icon that matches the size with a said name on every request.
> 
> This can be seen easily with strace:
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 6212
> ```
> After the patch: 
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 1993
> ```
> We reduce these accesses to let QDir keep the list of files inside the 
> directory (that was already being generated at some point, it just was being 
> discarded).
> 
> 
> Diffs
> -
> 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127236/diff/
> 
> 
> Testing
> ---
> 
> Builds, tests still pass, applications start noticeably faster.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Qt 5.6/QtWebkit

[Kevin Funk]

On Wednesday, March 16, 2016 5:59:30 PM CET René J. V. Bertin wrote:
> Aleix Pol wrote:
> > https://code.qt.io/cgit/qt/qtwebkit.git/
> 
> Right, thanks, I'd seen that one too (there's also a clone on github but it
> isn't clear how recent/unmodified that one is).
> 
> What I didn't yet see is if there's a way to do tarball fetches from
> code.qt.io that correspond to a specific commit, tag or release (purely for
> convenience in a packaging script)?

I think qt-developm...@qt-project.org is a better fit for this question.

Cheers,
Kevin

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


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

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 127406: Fix encoding for gap.xml (use UTF-8)

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127406/#review93635
---


Ship it!




Ship It!

- Kevin Funk


On March 17, 2016, 12:36 a.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127406/
> ---
> 
> (Updated March 17, 2016, 12:36 a.m.)
> 
> 
> Review request for Kate, KDE Frameworks and Daniel Vrátil.
> 
> 
> Repository: ktexteditor
> 
> 
> Description
> ---
> 
> The file is really ASCII-only (7 bit), so both ISO-8859-15 and UTF-8 works 
> but no need to use a deprecated encoding.
> (this could help systems were support for those encodings has been removed).
> 
> See also: https://mail.kde.org/pipermail/release-team/2016-March/009327.html
> 
> 
> Diffs
> -
> 
>   src/syntax/data/gap.xml 1af543d 
> 
> Diff: https://git.reviewboard.kde.org/r/127406/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

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

Re: Review Request 127380: More conservative approach to saving some disk accesses

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127380/#review93636
---



Since you asked for review: I don't know the code enough to judge. Generally 
I'd say "yes".

Does `iconPath(..., KIconLoader::MatchBest)` return results you'd have received 
with `iconPath(..., KIconLoader::MatchExact)`?

- Kevin Funk


On March 15, 2016, 1:52 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127380/
> ---
> 
> (Updated March 15, 2016, 1:52 a.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> My previous approach to KIconThemes felt like a dead end, I decided I'll take 
> a more conservative approach. Here's a first step.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 61e81f6 
>   autotests/kiconloader_benchmark.cpp PRE-CREATION 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127380/diff/
> 
> 
> Testing
> ---
> 
> Attempts to call `KIconThemeDir::iconPath` on the benchmark: 4318 after/5040 
> before= 17% less QFile::exists
> 
> 
> 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 124905: Win: Hide console window for binaries in LIBEXEC

[Kevin Funk]

> On April 18, 2016, 11:05 a.m., Gleb Popov wrote:
> > Let's do something about this. I see two solutions for this:
> > 
> > - Add another macro. If we go this route, can we put it in the same .cmake 
> > file?
> > - Add a keyword parameter to the existing macro. Because macro uses 
> > `${ARGN}` it shouldn't break anything.

@dfaure: Do you think this issue should be fixed in Qt itself?

I've just found 
http://stackoverflow.com/questions/33874243/qprocessstartdetached-but-hide-console-window
 which supports Patrick's remarks about "how we did it in KDE4 times".

* We use `QProcess:startDetached` in KF5, in combination with "KDE_FORK_SLAVES" 
(=> causes console win)
* We've been leaking QProcess and used `QProcess::start` in KDE4 times for 
'kdeinit4.exe' (=> no console win).

I haven't looked at the Windows implementation of QProcess yet, but maybe it's 
feasible to extend `QProcess::startDetached`? Ideas? Opinions? 

/me wonders why noone bothered fixing this in Qt itself yet (lots of 
discussions about the issues in forums)


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124905/#review94684
---


On Dec. 3, 2015, 8 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124905/
> ---
> 
> (Updated Dec. 3, 2015, 8 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Win: Hide console window for binaries in LIBEXEC
> 
> 
> Diffs
> -
> 
>   src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc 
>   src/ioslaves/http/kcookiejar/CMakeLists.txt 
> 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 
>   src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 
>   src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e 
>   src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc 
> 
> Diff: https://git.reviewboard.kde.org/r/124905/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: dbus-less frameworks on osx

[Kevin Funk]

On Wednesday, May 11, 2016 7:38:58 AM CEST Martin Graesslin wrote:
> On Wednesday, May 11, 2016 4:00:45 AM CEST Nick Shaforostoff wrote:
> > hi all! I'm investigating possibility of getting some kde apps to build on
> > osx with vanilla Qt without dbus.
> > 
> > would you accept patches that make that possible?

+1

I looked into that a while ago, but quickly discarded the idea, because QtDBus 
was just so broadly used in KF5. Just checked again, and it appeared to me 
it's indeed doable, when skipping a few frameworks (see below).

FYI: Just scan frameworks for "include.+QDBus", you'll hits in the following 
repositories:

bluez-qt
kactivities
kactivities-stats
kauth
kbookmarks
kcmutils
kconfigwidgets
kdbusaddons
kded
kdelibs4support
kdnssd
kglobalaccel
khtml
kiconthemes
kinit
kio
kmediaplayer
knotifications
knotifyconfig
kservice
kwallet
kxmlgui
modemmanager-qt
networkmanager-qt
solid

bluez-qt, modemmanager-qt, networkmanager-qt are heavy users of QtDBus, but 
are normally not needed for the majority of our KDE apps. I'd leave them as-
is.

Solid is another heavy user, but only in the Linux-specific backends iiuc, so 
not a problem.

You'll have some fun getting kio to built without DBus, tons of uses of QtDBus 
there.

The other frameworks only use QtDBus in a few places, definitely possible to 
make them optional. A few of them are not needed on OS X/Windows anyway -- say 
kded, kactivities, etc. -- not sure if they need to be dbus-less.

IOW: Go ahead! :)

Cheers,
Kevin

> > 
> > for example, i have just built kauth without dbus and i can prepare a
> > review request with a (nice) patch for this
> 
> Having suggested this in the past: I think that's a good idea and I fully
> support it.
> 
> Cheers,
> Martin


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

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 127911: Add a CMake option to build binary Qt resource out of icons dir.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127911/#review95520
---




CMakeLists.txt (line 24)
<https://git.reviewboard.kde.org/r/127911/#comment64740>

Rename: Use a verb -- rename to `add_binary_resource`, or 
`generate_binary_resource`

Params: `ret` -> `out`, or `outfile`



CMakeLists.txt (line 29)
<https://git.reviewboard.kde.org/r/127911/#comment64738>

This action should be deferred as well. See next comment.



CMakeLists.txt (line 32)
<https://git.reviewboard.kde.org/r/127911/#comment64739>

`cmake -E make_directory` first?


- Kevin Funk


On May 16, 2016, 6:21 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127911/
> ---
> 
> (Updated May 16, 2016, 6:21 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> I copied icons into the binary dir, because i haven't found a way to generate 
> rcc without polluting source dir.
> 
> Not sure if installation dir is right, too.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2147705 
>   icons-dark/CMakeLists.txt 36d37f1 
>   icons/CMakeLists.txt 5ded49c 
> 
> Diff: https://git.reviewboard.kde.org/r/127911/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

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

Re: Review Request 127911: Add a CMake option to build binary Qt resource out of icons dir.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127911/#review95522
---


Ship it!




Ship It!

- Kevin Funk


On May 17, 2016, 5:55 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127911/
> ---
> 
> (Updated May 17, 2016, 5:55 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: breeze-icons
> 
> 
> Description
> ---
> 
> I copied icons into the binary dir, because i haven't found a way to generate 
> rcc without polluting source dir.
> 
> Not sure if installation dir is right, too.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2147705 
>   icons-dark/CMakeLists.txt 36d37f1 
>   icons/CMakeLists.txt 5ded49c 
> 
> Diff: https://git.reviewboard.kde.org/r/127911/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

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

Re: kdesrc-build: stop after failure? --truly-verbose?

[Kevin Funk]

Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne:
> On Wed, February 26, 2014 22:30:48 Milian Wolff wrote:
> > Hey,
> > 
> > not sure this is the right list. I noticed that kdesrc-build happily
> > continues building even when a module failed to build. Is this desired?
> 
> Yes, it's on purpose. The idea is that most people are not building KDE for
> the first time and don't need to have the whole compile aborted because
> mpyne committed a fail-to-build bug in juk or something.
> 
> > Couldn't instead the _full_ error log be cat'ed and the build stopped?
> > Now,
> > I have to hunt down the error log manually which is really cumbersome. If
> > others think this behavior is good, could I vote for an additional cli
> > argument to stop after any failure?
> 
> Yes, kdesrc-build can do (most) of this. I thought I documented it as a
> command line option but it turns out that it was a kdesrc-buildrc option.
> 
> But you can still reach it via command line by passing --stop-on-failure=1
> 
> As far as the error log file, its location gets output at the end (which
> will be very soon indeed if you pass --stop-on-failure), and I think dfaure
> might still have an open bug about reporting the logfile location
> immediately upon failure.
> 
> However, what I personally do is that I added a small bash function to my
> .bashrc, "errorLog", which does something like:
> 
> errorLog() {
>   $EDITOR "~/log-kdesrc-build/latest/$1/error.log"
> }
> 
> where ~/log-kdesrc-build should be wherever your log directory is (probably
> $srcdir/log). kdesrc-build maintains symlinks throughout the log directory
> to make it easy to find the last log set for a given module, and which log
> contains the error if the module failed (i.e. if you see an error.log in a
> specific log directory it means that module failed to build that run).
> > Also, while at it, could we get a "truly verbose" flag, which actually
> > outputs the output from whatever tool is currently running?
> 
> If you file a bug I'd probably implement it. --debug did this kind of thing
> (it might even still do it, but it would be too annoying to use here). I say
> "file a bug" only because it's guaranteed it'll drop off my plate
> otherwise.

Yep, --debug still works as intended.

I use it a lot, but only if I build single packages or combined with --stop-
on-failure=1.

You should document that --debug flag, too, I'd say. I had to grep the code 
for it as well when I first wondered how to make kdesrc-build print everything 
to stdout.

> > For me as a
> > developer, its really annoying having to tail -f on some random log files
> > to get my hands on the make output... How are other developers handling
> > this?
> 
> I just watch the percentages in the kdesrc-build output personally. When I'm
> doing development I don't use kdesrc-build at all; I still retain my 'cs'
> and 'cb' shell macros to switch between individual source/build dirs as
> needed and manually do my git-fu and make-n-shake so that I can see
> compiler warnings.
> 
> I'm sorry if it's been annoying to use but I'm always open to improvements
> (especially improvements with patches, but no one else seems to like Perl...
> ;)
> 
> In the meantime there are other, better-documented, command line options
> which are useful. Documentation is available at
> http://kdesrc-build.kde.org/documentation/, and if you build kdesrc-build
> it should install a man page to $KDEDIR/share/man/man1 or thereabouts.
> 
> I've recently become a big fan of --resume-from (or -after), --stop-before
> (or -after) and --ignore-modules options myself. And always --pretend.
> 
> Regards,
>  - Michael Pyne

Cheers

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

Compile errors originating from libKF5XsltKde.a

[Kevin Funk]

Hey,

I get the following compile errors when compiling anything that depends on 
libKF5XsltKde.a from kdoctools:

When compiling kio:

[ 53%] Built target kio_file
/home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against 
'_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC
/home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may 
overflow at runtime; recompile with -fPIC
/home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against 
'_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC

Obviously, the reason is that -fPIC is missing for the static library target 
libKF5XsltKde.a.

I thought that's added implicitly when doing
target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)?
That pulls in the link flags from Qt5Core, no?

Ideas?

Important note: My Qt5 here is configured with -no-reduce-relocations (that 
might be the issue?), adding -fPIC fixes the build for me.

Greets

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

Re: Compile errors originating from libKF5XsltKde.a

[Kevin Funk]

Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk:
> Hey,
> 
> I get the following compile errors when compiling anything that depends on
> libKF5XsltKde.a from kdoctools:
> 
> When compiling kio:
> 
> [ 53%] Built target kio_file
> /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
> gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc
> against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile
> with -fPIC /home/krf/bin/ld: error:
> /home/krf/devel/install/kf5/lib/x86_64-linux-
> gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which
> may overflow at runtime; recompile with -fPIC
> /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
> gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc
> against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with
> -fPIC
> 
> Obviously, the reason is that -fPIC is missing for the static library target
> libKF5XsltKde.a.
> 
> I thought that's added implicitly when doing
> target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)?
> That pulls in the link flags from Qt5Core, no?
> 
> Ideas?
> 
> Important note: My Qt5 here is configured with -no-reduce-relocations (that
> might be the issue?), adding -fPIC fixes the build for me.
> 
> Greets

Note: That happens with any static library it seems -- just got the same for 
libkatefiletree.a.

So, any ideas how to solve this in a generic way?

Cheers

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

Re: Compile errors originating from libKF5XsltKde.a

[Kevin Funk]

Am Donnerstag, 27. Februar 2014, 15:24:30 schrieb Kevin Funk:
> Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk:
> > Hey,
> > 
> > I get the following compile errors when compiling anything that depends on
> > libKF5XsltKde.a from kdoctools:
> > 
> > When compiling kio:
> > 
> > [ 53%] Built target kio_file
> > /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
> > gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc
> > against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile
> > with -fPIC /home/krf/bin/ld: error:
> > /home/krf/devel/install/kf5/lib/x86_64-linux-
> > gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which
> > may overflow at runtime; recompile with -fPIC
> > /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux-
> > gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc
> > against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile
> > with
> > -fPIC
> > 
> > Obviously, the reason is that -fPIC is missing for the static library
> > target libKF5XsltKde.a.
> > 
> > I thought that's added implicitly when doing
> > target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)?
> > That pulls in the link flags from Qt5Core, no?
> > 
> > Ideas?
> > 
> > Important note: My Qt5 here is configured with -no-reduce-relocations
> > (that
> > might be the issue?), adding -fPIC fixes the build for me.
> > 
> > Greets
> 
> Note: That happens with any static library it seems -- just got the same for
> libkatefiletree.a.
> 
> So, any ideas how to solve this in a generic way?
> 
> Cheers

Just discussed this a bit with Stephen on IRC:

We need to set the compile flags manually on each static library used in a 
shared library -- there's no way for CMake to figure out if a static library 
will be added to a shared one.

So, we have to specify
set_target_properties(MyStaticLib PROPERTIES POSITION_INDEPENDENT_CODE TRUE)
manually for each of them

Also see:
http://cmake.3232098.n2.nabble.com/SHARED-library-containing-OBJECT-library-Missing-fPIC-tp7580514p7580571.html

I'll file some patches

Greets

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

Review Request 116124: Always compile static lib with -fPIC

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kdoctools


Description
---

Always compile static lib with -fPIC

See
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012375.html


Diffs
-

  src/CMakeLists.txt 0329bd383415b4fa265c1edd7f0f7d384fd17395 

Diff: https://git.reviewboard.kde.org/r/116124/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: kdesrc-build: stop after failure? --truly-verbose?

[Kevin Funk]

Am Donnerstag, 27. Februar 2014, 21:15:54 schrieb Michael Pyne:
> On Thu, February 27, 2014 11:35:16 Kevin Funk wrote:
> > Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne:
> > > On Wed, February 26, 2014 22:30:48 Milian Wolff wrote:
> > > > Also, while at it, could we get a "truly verbose" flag, which actually
> > > > outputs the output from whatever tool is currently running?
> > > 
> > > If you file a bug I'd probably implement it. --debug did this kind of
> > > thing
> > > (it might even still do it, but it would be too annoying to use here). I
> > > say "file a bug" only because it's guaranteed it'll drop off my plate
> > > otherwise.
> > 
> > Yep, --debug still works as intended.
> > 
> > I use it a lot, but only if I build single packages or combined with
> > --stop- on-failure=1.
> > 
> > You should document that --debug flag, too, I'd say. I had to grep the
> > code
> > for it as well when I first wondered how to make kdesrc-build print
> > everything to stdout.
> 
> It's documented in both the man page and the DocBook/website documentation.
> Do you mean that the documentation is inadequate? It's also possible it
> wasn't documented when you looked but I've already fixed it. ;)
> 
> Regards,
>  - Michael Pyne

Indeed, that's true. I was more referring to the help out you get with --help.

Greets

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

Re: Review Request 116124: Always compile static lib with -fPIC

[Kevin Funk]

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

(Updated March 2, 2014, 1:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdoctools


Description
---

Always compile static lib with -fPIC

See
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012375.html


Diffs
-

  src/CMakeLists.txt 0329bd383415b4fa265c1edd7f0f7d384fd17395 

Diff: https://git.reviewboard.kde.org/r/116124/diff/


Testing
---


Thanks,

Kevin Funk

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

Review Request 117017: Remove forward headers for KTextEditor

[Kevin Funk]

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

Review request for KDE Frameworks and Dominik Haumann.


Repository: kde4support


Description
---

Remove forward headers for KTextEditor

Some of the headers have actually been removed already. Keeping broken
forward headers actually makes it *more* difficult to port.


Diffs
-

  src/includes/KTextEditor/CommandExtension 
4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/CodeCompletionModelControllerInterface 
a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 
  src/includes/KTextEditor/CodeCompletionModel 
3511d00b212e5c56613bf4f06fedc5a5d76cb3bc 
  src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 
  src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae 
  src/includes/KTextEditor/CodeCompletionInterface 
41341c38dd92e7c1533b0ba74eceb735408a1d3f 
  src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d 
  src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 
  src/includes/KTextEditor/ConfigPage b3904bee10ffc0245bca1a928389237813850ec3 
  src/includes/KTextEditor/ConfigInterface 
0617835fc7621c4c26a2d50ca95d12d8870fffc2 
  src/includes/KTextEditor/CommandInterface 
4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/ModificationInterface 
50df2902648156dc5cd4630f587add36d320a43a 
  src/includes/KTextEditor/MessageInterface 
41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
  src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 
  src/includes/KTextEditor/HighlightInterface 
8c8c94ec679877be7e3965eba86498f06b67a883 
  src/includes/KTextEditor/MarkInterface 
87adf561b38045bdd65fc3f64f24311aa901d8ee 
  src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
  src/includes/KTextEditor/ParameterizedSessionConfigInterface 
8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
  src/includes/KTextEditor/MovingRange 89f68605ffa863862476831cfb836660a70e4931 
  src/includes/KTextEditor/MovingInterface 
bde16eaca7d68517ce7c2068186eb641daf6eab1 
  src/includes/KTextEditor/MovingCursor 
7c9eb3074e4feace09cca78962caf1ff27bd6394 
  src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 
  src/includes/KTextEditor/VariableInterface 
126a93691700fab3134400907d0ba93a4e275f0d 
  src/includes/KTextEditor/TextHintInterface 
6b05d9a4a45ac8807294599e04c7dc15db076cf0 
  src/includes/KTextEditor/TemplateInterface2 
de9d9451796710756287bfc2a627f7ae43a006b1 
  src/includes/KTextEditor/TemplateInterface 
0142d17815fabb9136836effa61114aaa1994635 
  src/includes/KTextEditor/SessionConfigInterface 
8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
  src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 
  src/includes/KTextEditor/SearchInterface 
f7dffc91739e82cceffea35de0632cb19e92ab0a 
  src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e 

Diff: https://git.reviewboard.kde.org/r/117017/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 117017: Remove forward headers for KTextEditor

[Kevin Funk]

> On March 24, 2014, 10:57 a.m., Aleix Pol Gonzalez wrote:
> > There's a slight difference, and the reason we haven't been doing this for 
> > most headers. From KDE4Support you can include headers prefixing KDE/ (such 
> > as KDE/KTextEditor/MovingRange). If you remove these that won't be possible 
> > anymore thus making porting slightly harder. Arguably people won't be doing 
> > KDE/KTextEditor, but then I don't know why people added the KDE/ at all...

Yep. I'm just fixing this up in KDevelop (where I hit that problem), replacing 
occurences of 'KDE/'.

The problem with the KTE forward headers are that some of them are already 
broken (TemplateInterface*, HighlightInterface, and others). This makes it 
harder than easier to port, because you get compile errors in the middle of the 
build process.

Arguably, I'd rather force people to get rid off the 'KDE/' prefix (which is 
easy to script) than to compile again and again to make your code work.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117017/#review53937
---


On March 24, 2014, 10:48 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117017/
> ---
> 
> (Updated March 24, 2014, 10:48 a.m.)
> 
> 
> Review request for KDE Frameworks and Dominik Haumann.
> 
> 
> Repository: kde4support
> 
> 
> Description
> ---
> 
> Remove forward headers for KTextEditor
> 
> Some of the headers have actually been removed already. Keeping broken
> forward headers actually makes it *more* difficult to port.
> 
> 
> Diffs
> -
> 
>   src/includes/KTextEditor/CommandExtension 
> 4187c61882a83cab906fa87cd16bd18229b6efb5 
>   src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 
>   src/includes/KTextEditor/CodeCompletionModelControllerInterface 
> a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 
>   src/includes/KTextEditor/CodeCompletionModel 
> 3511d00b212e5c56613bf4f06fedc5a5d76cb3bc 
>   src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 
>   src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae 
>   src/includes/KTextEditor/CodeCompletionInterface 
> 41341c38dd92e7c1533b0ba74eceb735408a1d3f 
>   src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d 
>   src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 
>   src/includes/KTextEditor/ConfigPage 
> b3904bee10ffc0245bca1a928389237813850ec3 
>   src/includes/KTextEditor/ConfigInterface 
> 0617835fc7621c4c26a2d50ca95d12d8870fffc2 
>   src/includes/KTextEditor/CommandInterface 
> 4187c61882a83cab906fa87cd16bd18229b6efb5 
>   src/includes/KTextEditor/ModificationInterface 
> 50df2902648156dc5cd4630f587add36d320a43a 
>   src/includes/KTextEditor/MessageInterface 
> 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
>   src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 
>   src/includes/KTextEditor/HighlightInterface 
> 8c8c94ec679877be7e3965eba86498f06b67a883 
>   src/includes/KTextEditor/MarkInterface 
> 87adf561b38045bdd65fc3f64f24311aa901d8ee 
>   src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
>   src/includes/KTextEditor/ParameterizedSessionConfigInterface 
> 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
>   src/includes/KTextEditor/MovingRange 
> 89f68605ffa863862476831cfb836660a70e4931 
>   src/includes/KTextEditor/MovingInterface 
> bde16eaca7d68517ce7c2068186eb641daf6eab1 
>   src/includes/KTextEditor/MovingCursor 
> 7c9eb3074e4feace09cca78962caf1ff27bd6394 
>   src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 
>   src/includes/KTextEditor/VariableInterface 
> 126a93691700fab3134400907d0ba93a4e275f0d 
>   src/includes/KTextEditor/TextHintInterface 
> 6b05d9a4a45ac8807294599e04c7dc15db076cf0 
>   src/includes/KTextEditor/TemplateInterface2 
> de9d9451796710756287bfc2a627f7ae43a006b1 
>   src/includes/KTextEditor/TemplateInterface 
> 0142d17815fabb9136836effa61114aaa1994635 
>   src/includes/KTextEditor/SessionConfigInterface 
> 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
>   src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 
>   src/includes/KTextEditor/SearchInterface 
> f7dffc91739e82cceffea35de0632cb19e92ab0a 
>   src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e 
> 
> Diff: https://git.reviewboard.kde.org/r/117017/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 117017: Remove forward headers for KTextEditor

[Kevin Funk]

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

(Updated March 24, 2014, 2:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Dominik Haumann.


Repository: kde4support


Description
---

Remove forward headers for KTextEditor

Some of the headers have actually been removed already. Keeping broken
forward headers actually makes it *more* difficult to port.


Diffs
-

  src/includes/KTextEditor/CommandExtension 
4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/CodeCompletionModelControllerInterface 
a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 
  src/includes/KTextEditor/CodeCompletionModel 
3511d00b212e5c56613bf4f06fedc5a5d76cb3bc 
  src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 
  src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae 
  src/includes/KTextEditor/CodeCompletionInterface 
41341c38dd92e7c1533b0ba74eceb735408a1d3f 
  src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d 
  src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 
  src/includes/KTextEditor/ConfigPage b3904bee10ffc0245bca1a928389237813850ec3 
  src/includes/KTextEditor/ConfigInterface 
0617835fc7621c4c26a2d50ca95d12d8870fffc2 
  src/includes/KTextEditor/CommandInterface 
4187c61882a83cab906fa87cd16bd18229b6efb5 
  src/includes/KTextEditor/ModificationInterface 
50df2902648156dc5cd4630f587add36d320a43a 
  src/includes/KTextEditor/MessageInterface 
41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
  src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 
  src/includes/KTextEditor/HighlightInterface 
8c8c94ec679877be7e3965eba86498f06b67a883 
  src/includes/KTextEditor/MarkInterface 
87adf561b38045bdd65fc3f64f24311aa901d8ee 
  src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 
  src/includes/KTextEditor/ParameterizedSessionConfigInterface 
8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
  src/includes/KTextEditor/MovingRange 89f68605ffa863862476831cfb836660a70e4931 
  src/includes/KTextEditor/MovingInterface 
bde16eaca7d68517ce7c2068186eb641daf6eab1 
  src/includes/KTextEditor/MovingCursor 
7c9eb3074e4feace09cca78962caf1ff27bd6394 
  src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 
  src/includes/KTextEditor/VariableInterface 
126a93691700fab3134400907d0ba93a4e275f0d 
  src/includes/KTextEditor/TextHintInterface 
6b05d9a4a45ac8807294599e04c7dc15db076cf0 
  src/includes/KTextEditor/TemplateInterface2 
de9d9451796710756287bfc2a627f7ae43a006b1 
  src/includes/KTextEditor/TemplateInterface 
0142d17815fabb9136836effa61114aaa1994635 
  src/includes/KTextEditor/SessionConfigInterface 
8c26b7d418e81072df4e7dffe0038d7fdc1e3010 
  src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 
  src/includes/KTextEditor/SearchInterface 
f7dffc91739e82cceffea35de0632cb19e92ab0a 
  src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e 

Diff: https://git.reviewboard.kde.org/r/117017/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Writing a Frameworks book at Randa

[Kevin Funk]

On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> Hello folks, I know that August is months away, but if you want your
> Frameworks book, now is the time to step forward.
> 
> Here are some things to think about:
> 
> Most of this book is already written somewhere. When the words have
> already been written down, all we need do is gather and arrange them.
> When you think of such an email, dot story, blog post or have eloquent
> thoughts in your head, please make a note.
> 
> If you are on this list, you are an expert. You know what the
> Frameworks will do for KDE, and you know what they *can* do for
> others. Our book will present that case. A good book will help grow
> the Frameworks team; I'm sure of it. And a good book will make your
> work more widely used. Oh, and you'll be a published author!
> 
> While in Randa, none of us will be writing full-time. In fact, I hope
> that *all* of the Frameworks people will stop by the writing room, or
> log into Booki and review, add, re-arrange, correct, or make the text
> more graceful.
> 
> To make this work a few people must volunteer to take on the writing
> of the book as their most important task at Randa. It will be mine,
> and our goal is to have a book by the end of the week. We've done it
> before, and I know we can do it again. This is a valuable work.
> 
> We need to know the core members of this team, soon. Please step
> forward, and also add yourself to the Spints page for planning and
> funding.
> 
> Valorie

Hey,

I'm wondering if we should rather try spending the time in making our KF5 
apidocs shine. You could spend plenty of time on writing introductory parts 
for the individual modules, writing tutorials and examples, and make sure 
they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an 
integral part for the docs on qt-project.org, too. Just have a look at the 
first hit for "qt docs": [1]

There's a "Getting Started" section, with overviews [2] with examples and 
tutorials [3]. That's *exactly* what we need for KF5, too. That's the best 
place to point newcomers to whenever they want to get wet with KF5. But it 
also takes time and people to get to this state.

Personally, from a developer POV, I don't really see the need for a separate 
"book". There will always be a discrepancy between the book and the actual 
code (be it completeness, accuracy, its up-to-date-ness), and for developers 
it's always an extra burden to make sure to amend the contents of the book 
whenever they change something in source code. It's much more straight-forward 
to make sure that at least the apidocs are up-to-date. The apidocs being 
inline in the source code being is an integral part in making sure they're 
amended alongside of source code changes.

Opinions? What do the frameworks devs think about it?

Greets

[1] http://qt-project.org/doc/qt-5/index.html
[2] http://qt-project.org/doc/qt-5/overviews-main.html
[3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html

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

Re: Writing a Frameworks book at Randa

[Kevin Funk]

On Wednesday 09 April 2014 15:42:47 Aleix Pol wrote:
> On Wed, Apr 9, 2014 at 3:05 PM, Kevin Funk  wrote:
> > On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> > > Hello folks, I know that August is months away, but if you want your
> > > Frameworks book, now is the time to step forward.
> > > 
> > > Here are some things to think about:
> > > 
> > > Most of this book is already written somewhere. When the words have
> > > already been written down, all we need do is gather and arrange them.
> > > When you think of such an email, dot story, blog post or have eloquent
> > > thoughts in your head, please make a note.
> > > 
> > > If you are on this list, you are an expert. You know what the
> > > Frameworks will do for KDE, and you know what they *can* do for
> > > others. Our book will present that case. A good book will help grow
> > > the Frameworks team; I'm sure of it. And a good book will make your
> > > work more widely used. Oh, and you'll be a published author!
> > > 
> > > While in Randa, none of us will be writing full-time. In fact, I hope
> > > that *all* of the Frameworks people will stop by the writing room, or
> > > log into Booki and review, add, re-arrange, correct, or make the text
> > > more graceful.
> > > 
> > > To make this work a few people must volunteer to take on the writing
> > > of the book as their most important task at Randa. It will be mine,
> > > and our goal is to have a book by the end of the week. We've done it
> > > before, and I know we can do it again. This is a valuable work.
> > > 
> > > We need to know the core members of this team, soon. Please step
> > > forward, and also add yourself to the Spints page for planning and
> > > funding.
> > > 
> > > Valorie
> > 
> > Hey,
> > 
> > I'm wondering if we should rather try spending the time in making our KF5
> > apidocs shine. You could spend plenty of time on writing introductory
> > parts
> > for the individual modules, writing tutorials and examples, and make sure
> > they're easy to reach and grasp for newcomers on apidocs.kde.org. This is
> > an
> > integral part for the docs on qt-project.org, too. Just have a look at the
> > first hit for "qt docs": [1]
> > 
> > There's a "Getting Started" section, with overviews [2] with examples and
> > tutorials [3]. That's *exactly* what we need for KF5, too. That's the best
> > place to point newcomers to whenever they want to get wet with KF5. But it
> > also takes time and people to get to this state.
> > 
> > Personally, from a developer POV, I don't really see the need for a
> > separate
> > "book". There will always be a discrepancy between the book and the actual
> > code (be it completeness, accuracy, its up-to-date-ness), and for
> > developers
> > it's always an extra burden to make sure to amend the contents of the book
> > whenever they change something in source code. It's much more
> > straight-forward
> > to make sure that at least the apidocs are up-to-date. The apidocs being
> > inline in the source code being is an integral part in making sure they're
> > amended alongside of source code changes.
> > 
> > Opinions? What do the frameworks devs think about it?
> > 
> > Greets
> > 
> > [1] http://qt-project.org/doc/qt-5/index.html
> > [2] http://qt-project.org/doc/qt-5/overviews-main.html
> > [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html
> > 
> > --
> > Kevin Funk
> > ___
> > Kde-frameworks-devel mailing list
> > Kde-frameworks-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> Hi,
> I'm unsure what to say. On one hand, people always seem inclined to have
> some literature available, especially in the shape of a book. It helps you
> go through the technologies when you don't know much what you're doing but
> you still want to learn. It offers a linear overview of interesting things
> on a related subject, meaning that if things are not interesting, you can
> opt to not include them in the book.
> 
> On the other hand, documentation is much more future-proof in terms of
> having it actively-ish maintained and it will be more useful for the
> developers who decide to stay using KF5, since they will know what to look
> for.
> A proof of this is that even though we have wonderful 

Hitting assertion in kio-trash (KF5KIOCore)

[Kevin Funk]

Hey,

While running unit tests from kdevplatform I hit the following assert in 
trash/trashimpl.cpp (from workspace/kio-extras)

Output of the unit test (which attempts to trash some folders):
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 1" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 2" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 3" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 4" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 5" 
trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 6" 
ASSERT: "fileId.endsWith( QLatin1String(".trashinfo") )" in file 
/home/krf/devel/src/kf5/kde/workspace/kio-extras/trash/trashimpl.cpp, line 272
kioslave: ### CRASH ## protocol = trash pid = 6144 signal = 6
/home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKF5KIOCore.so.5(+0x8d609)
[0x7fbbbfe79609]
(...)

Looking at the code, that assert looks very suspicious. The code above the 
assert seems to generate file ids such as '.trashinfo' or '.trashinfo 
SOME_NUMBER'. In case of the latter, the assert will always be hit.

Any ideas? Did KIO::RenameDialog::suggestName change?

Reproducable with:
./plugins/git/tests/kdevgit-test testRemoveEmptyFolder

from kdevplatform.git.

Greets

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

Re: Review Request 117695: change where dynamic replace tabs is performed

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117695/#review56264
---



src/document/katedocument.cpp
<https://git.reviewboard.kde.org/r/117695/#comment39333>

Early-return?

if (!replacetabs)
return str;

...


- Kevin Funk


On April 23, 2014, 8:49 a.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117695/
> ---
> 
> (Updated April 23, 2014, 8:49 a.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Cullmann.
> 
> 
> Repository: ktexteditor
> 
> 
> Description
> ---
> 
> This makes typeChars handle replacing tabs by spaces, instead of insertText. 
> The rationale is that insertText is often called programatically, and the 
> caller should be able to rely on the text he requests to be inserted is 
> actually inserted, and not changed on-the-fly. Examples for where the 
> previous solution caused problems are KDevelop (the codegen) and 
> kte-collaborative.
> 
> I'm not sure what the code I removed was doing (heh). It looks like it is 
> supposed to advance to the next indent level if the current indent level is 
> odd, but that still works after removing it.
> 
> The obvious user-visible change here is that tabs in pasted text will no 
> longer be replaced. But since I always found this behaviour undesirable 
> anyways, I did not bother to replicate it. I will instead wait for people to 
> yell at me for removing it. ;)
> 
> 
> Diffs
> -
> 
>   src/document/katedocument.h 83cc0317e26ef077d5292763d0ba9864103bf454 
>   src/document/katedocument.cpp 546d3e6aadc57f24c3fa766ce235addc0f02e3c3 
> 
> Diff: https://git.reviewboard.kde.org/r/117695/diff/
> 
> 
> Testing
> ---
> 
> Just some quick manual tests, it seems to still work as intended.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

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

Review Request 117951: trash: Fix KUrl->QUrl porting bug

[Kevin Funk]

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

Review request for KDE Frameworks and David Faure.


Repository: kio-extras


Description
---

trash: Fix KUrl->QUrl porting bug

Make sure we keep the old behavior


Diffs
-

  trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 
  trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 
  trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba 

Diff: https://git.reviewboard.kde.org/r/117951/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 117952: Fix KIO::suggestName() for the case of leading dots, and no other dot.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117952/#review57150
---

Ship it!


LGTM

- Kevin Funk


On May 2, 2014, 4:12 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117952/
> ---
> 
> (Updated May 2, 2014, 4:12 p.m.)
> 
> 
> Review request for KDE Frameworks and Kevin Funk.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Fix KIO::suggestName() for the case of leading dots, and no other dot.
> 
> We don't want to change the extension in that case.
> 
> With a unittest for that method, finally.
> 
> 
> Diffs
> -
> 
>   autotests/globaltest.h b955329cf7d5841d9f9c1230e41d1261a268420e 
>   autotests/globaltest.cpp 4367e53b44e077c566316081e21f429ac15b74a0 
>   src/core/global.cpp b6f523d66ef5b9308f615c485d6dcf3069b26ace 
> 
> Diff: https://git.reviewboard.kde.org/r/117952/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: Review Request 117951: trash: Fix KUrl->QUrl porting bug

[Kevin Funk]

> On May 2, 2014, 4:14 p.m., David Faure wrote:
> > I assume the test failed before the fix, right? ;-)

Yep.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117951/#review57148
---


On May 2, 2014, 4:10 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117951/
> ---
> 
> (Updated May 2, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> trash: Fix KUrl->QUrl porting bug
> 
> Make sure we keep the old behavior
> 
> 
> Diffs
> -
> 
>   trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 
>   trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 
>   trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba 
> 
> Diff: https://git.reviewboard.kde.org/r/117951/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 117951: trash: Fix KUrl->QUrl porting bug

[Kevin Funk]

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

(Updated May 2, 2014, 4:24 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Repository: kio-extras


Description
---

trash: Fix KUrl->QUrl porting bug

Make sure we keep the old behavior


Diffs
-

  trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 
  trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 
  trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba 

Diff: https://git.reviewboard.kde.org/r/117951/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Hitting assertion in kio-trash (KF5KIOCore)

[Kevin Funk]

On Wednesday 16 April 2014 21:31:01 Kevin Funk wrote:
> Hey,
> 
> While running unit tests from kdevplatform I hit the following assert in
> trash/trashimpl.cpp (from workspace/kio-extras)
> 
> Output of the unit test (which attempts to trash some folders):
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 1"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 2"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 3"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 4"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 5"
> trying to create  "/home/krf/.local/share/Trash/info/.trashinfo 6"
> ASSERT: "fileId.endsWith( QLatin1String(".trashinfo") )" in file
> /home/krf/devel/src/kf5/kde/workspace/kio-extras/trash/trashimpl.cpp, line
> 272 kioslave: ### CRASH ## protocol = trash pid = 6144 signal = 6
> /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKF5KIOCore.so.5(+0x8d60
> 9) [0x7fbbbfe79609]
> (...)
> 
> Looking at the code, that assert looks very suspicious. The code above the
> assert seems to generate file ids such as '.trashinfo' or '.trashinfo
> SOME_NUMBER'. In case of the latter, the assert will always be hit.
> 
> Any ideas? Did KIO::RenameDialog::suggestName change?
> 
> Reproducable with:
> ./plugins/git/tests/kdevgit-test testRemoveEmptyFolder
> 
> from kdevplatform.git.
> 
> Greets

Hey,

https://git.reviewboard.kde.org/r/117951/ fixed this, btw.

It was a porting bug (KUrl -> QUrl) within trashimpl.cpp

Greets

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

Re: KTextEditor & Frameworks question

[Kevin Funk]

Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann:
> > I see, yeah, thats KatePart it seems to me.
> > 
> > Anyway, I am all for going to have a KF5 KTextEditor framework, will make
> > it more approachable
> > for other projects to use it.
> > And unlike in 4.x, KTextEditor would always provide the implementation
> > directly (KatePart merged in, internally)
> > and some wrapper KParts for the people preferring to just load a simple
> > part without any more tight integration.
> > 
> > David showed me the kdeexamples/framework-template and the kdelibs-split
> > script.
> > 
> > Still, I have one question:
> > 
> > Is it really enough to init a new repository and have that one initial
> > commit + add (and then move the files around inside the new git)
> > to have history via grafting available? There is no other "trick" behind I
> > just don't see ATM?
> > 
> > I would try to convert to framework style git in some personal repo on
> > git.kde.org and post that here for review if I do it right ;)
> > 
> > Greetings
> > Christoph
> 
> I tried my luck with splitting/grafting/kdeexamples template.
> 
> Could somebody take a look what ended up in the master branch of
> 
> g...@git.kde.org:scratch/cullmann/ktexteditor.git
> 
> Any feedback welcome, if I screwed it up a lot ;)
> 
> That git shall contain a KTextEditor framework, I hope, with grafting able
> history, at least I was able to graft against kate.git using the howto. The
> structure should fit a framework, only the tests dir is missing as empty
> atm.
> 
> Greetings
> Christoph

Hey,

Just tried to build kdevplatform against the ktexteditor framework -- Didn't 
work because CMake didn't find KF5TextEditorConfig.cmake.

The problem is that all your .cmake files are missing the KF5 prefix which 
other frameworks apparently have set.
CMake cannot find the framework via find_package(KF5 ... COMPONENTS 
TextEditor), then, I suppose.

Makes sense?

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

Re: KTextEditor & Frameworks question

[Kevin Funk]

Am Dienstag, 7. Januar 2014, 19:57:56 schrieb Christoph Cullmann:
> Hi,
> 
> I just tried to fix the naming issues.
> 
> Does that try here look better
> 
> http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git
> 
> If yes, I would ask sysadmin to move to framworks, if that is ok and remove
> the stuff in frameworks branch of kate.git.
> 
> Greetings
> Christoph
> 
> - Ursprüngliche Mail -
> (snip)

Something's still wrong in case I'm not mistaken:

/home/krf/devel/install/kf5/lib/x86_64-linux-
gnu/cmake/KF5TextEditor/KF5TextEditorTargets.cmake
49:add_library(KF5::KF5TextEditor SHARED IMPORTED)
  
he KF5 suffix should be dropped, no?

I'd fix myself but atm I don't know where that magic line is generated from.

Cheers

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

Re: KTextEditor & Frameworks question

[Kevin Funk]

Am Dienstag, 7. Januar 2014, 21:20:40 schrieb Kevin Funk:
> Am Dienstag, 7. Januar 2014, 19:57:56 schrieb Christoph Cullmann:
> > Hi,
> > 
> > I just tried to fix the naming issues.
> > 
> > Does that try here look better
> > 
> > http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git
> > 
> > If yes, I would ask sysadmin to move to framworks, if that is ok and
> > remove
> > the stuff in frameworks branch of kate.git.
> > 
> > Greetings
> > Christoph
> > 
> > - Ursprüngliche Mail -
> > (snip)
> 
> Something's still wrong in case I'm not mistaken:
> 
> /home/krf/devel/install/kf5/lib/x86_64-linux-
> gnu/cmake/KF5TextEditor/KF5TextEditorTargets.cmake
> 49:add_library(KF5::KF5TextEditor SHARED IMPORTED)
> 
> he KF5 suffix should be dropped, no?
> 
> I'd fix myself but atm I don't know where that magic line is generated from.
> 
> Cheers

Ah. Something like that should fix it:

set_target_properties(KF5ItemViews PROPERTIES
  VERSION  ${KITEMVIEWS_VERSION_STRING}
  SOVERSION ${KITEMVIEWS_SOVERSION}
  EXPORT_NAME ItemViews)

'EXPORT_NAME' seems important.

Greets

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

Review Request 115347: Remove Qt5Xml dependency

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kcompletion


Description
---

Remove Qt5Xml dependency

Not needed, no?


Diffs
-

  CMakeLists.txt 94afe9f5f414a437e519242026ebaf2a838ffc88 

Diff: https://git.reviewboard.kde.org/r/115347/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 115347: Remove Qt5Xml dependency

[Kevin Funk]

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

(Updated Jan. 28, 2014, 8:39 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kcompletion


Description
---

Remove Qt5Xml dependency

Not needed, no?


Diffs
-

  CMakeLists.txt 94afe9f5f414a437e519242026ebaf2a838ffc88 

Diff: https://git.reviewboard.kde.org/r/115347/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: add test for QFileDialog::getExistingDirectory / bug?

[Kevin Funk]

Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi:
> With another addition to qfiledialogtest in
> frameworks/frameworkintegration another potential bug can be exposed:
> 
> Calling
> 
> $ ./qfiledialogtest --nameFilter "c (*.cpp)" --nameFilter "h (*.h)"
> --selectNameFilter "h (*.h)"

Works for me. Using Qt 5.2.0, if that matters.

> does not select the second filter. Can this be confirmed or maybe I am
> using the API wrong?
> 
> Gregor
> 
> On 26/01/14 17:15, Gregor Mi wrote:
> > Hi,
> > 
> > with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for
> > QFileDialog::getExistingDirectory.
> > 
> > When I execute
> > 
> > ./qfiledialogtest --staticFunction getExistingDirectory
> > 
> > then a dialog opens that lets the user select files but not directories.
> > This seems to be a bug.
> > 
> > Greetings
> > 
> > Gregor

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

Re: More work available

[Kevin Funk]

On Thursday 02 August 2012, 17:26, David Faure wrote:
> On Friday 27 July 2012 14:38:32 David Faure wrote:
> > Here's the moment you were all waiting for: I just added more very-easy
> > tasks at the top of
> > http://community.kde.org/Frameworks/Epics/kdelibs_cleanups
> 
> For the last two weeks, I've been the only committer to kdelibs frameworks
> (one week working, one week on "holidays", i.e. on my free time).
> 
> No volunteer for any of the above tasks, for almost one week now.
> 
> What can I do to make KDE Frameworks development more attractive?
> 
> It used to be hard to build - that's fixed by the "Building" wiki page.
> 
> It used to be hard to know how to contribute - that's fixed by the above
> wiki page, which has both "very easy" and "more interesting" tasks.
> (plus all the Qt-related tasks, which is even "more interesting")
> 
> Am I the only person in the world who cares about the KDE libraries?
> 
> :(
> 
> There were 30 people in Randa, 20 people in the BoF at Akademy, where's
> everyone now?
> I see lots of commits in other parts of KDE for the last two weeks, so it's
> not like everyone is at the beach... (and it's not like there were 40
> contributors previously either).

Hey there,

I planned to help out on the KDE frameworks branch during the next months 
(semester break).

Until now I didnt actually have time or didnt know where to start, but I guess 
the above link should help me to get started. I'd really like to get more 
involved into kdelibs API development and/or Qt upstream work.

Anyway, for now, and for the next week I'm at the aforesaid beach, though.
Sorry. :)

I'll come back to you in approx. 1.5 weeks. Don't be desperate!

Greets

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

Review Request: Port some uses of KProcess to QProcess

[Kevin Funk]

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

Review request for KDE Frameworks.


Description
---

Port some uses of KProcess to QProcess


Diffs
-

  kdeui/dialogs/kedittoolbar.cpp 0582934b0bf8cb7160cb48b4c8151c81b35277f0 
  kinit/klauncher.cpp 855e56041be5a5b76b9a7e9d0597ac7ad485682e 
  kio/kfile/kfilemetadatareader.cpp 88cadaa2edf1b1de24c0e91576cca368db41f470 
  kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
  kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
  kio/kio/krun_p.h 0ad15c8434599ccabcd649f251aa622d4fb0b0f7 
  staging/kwidgets/autotests/kglobalsettingstest.cpp 
4426fee08427499c777cc7fc94e4b1345c790ac2 

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


Testing
---


Thanks,

Kevin Funk

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

Review Request: Port some uses of KUrl to QUrl

[Kevin Funk]

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

Review request for KDE Frameworks.


Description
---

Port some uses of KUrl to QUrl


kio: Cleanup header a bit


kio: Merge some functions using default arguments


kio: Mark test with QSKIP_PORTING


Diffs
-

  kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
  kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
  kio/tests/kruntest.h 6f5eae6147e2fbef25025976a17869af4d0f12f9 
  kio/tests/kruntest.cpp 92496bd1d4b98ea8f7dc13977cd3d2aa0dae7145 
  kio/tests/krununittest.cpp 314da79b9ee4f95bcc9f768a95810f7de3125ac1 

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


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request: Port some uses of KUrl to QUrl

[Kevin Funk]

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

(Updated Sept. 19, 2012, 10:19 p.m.)


Review request for KDE Frameworks.


Changes
---

Good catch. Restored the old behaviour, using str.replace("/bin/sh/", m_sh). 
m_sh is initialized to findExecutable("sh").


Description
---

Port some uses of KUrl to QUrl


kio: Cleanup header a bit


kio: Merge some functions using default arguments


kio: Mark test with QSKIP_PORTING


Diffs (updated)
-

  kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
  kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
  kio/tests/kruntest.h 6f5eae6147e2fbef25025976a17869af4d0f12f9 
  kio/tests/kruntest.cpp 92496bd1d4b98ea8f7dc13977cd3d2aa0dae7145 
  kio/tests/krununittest.cpp 314da79b9ee4f95bcc9f768a95810f7de3125ac1 

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


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 106501: Port some uses of KUrl to QUrl

[Kevin Funk]

> On Feb. 7, 2013, 9:08 p.m., Albert Astals Cid wrote:
> > I see this has a shit it but marked as uncommited. Was it commited and you 
> > forgot to close the request or is still uncommited?

Yeah. I should shit this at some point :)


- Kevin


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


On Sept. 19, 2012, 10:19 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106501/
> ---
> 
> (Updated Sept. 19, 2012, 10:19 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Port some uses of KUrl to QUrl
> 
> 
> kio: Cleanup header a bit
> 
> 
> kio: Merge some functions using default arguments
> 
> 
> kio: Mark test with QSKIP_PORTING
> 
> 
> Diffs
> -
> 
>   kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
>   kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
>   kio/tests/kruntest.h 6f5eae6147e2fbef25025976a17869af4d0f12f9 
>   kio/tests/kruntest.cpp 92496bd1d4b98ea8f7dc13977cd3d2aa0dae7145 
>   kio/tests/krununittest.cpp 314da79b9ee4f95bcc9f768a95810f7de3125ac1 
> 
> Diff: http://git.reviewboard.kde.org/r/106501/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE

[Kevin Funk]

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

Review request for KDE Frameworks and Stephen Kelly.


Repository: kdelibs4support


Description
---

Do not define QT_DISABLE_DEPRECATED_BEFORE

When defining it in your own project, you'll get:
:0:0: warning:
"QT_DISABLE_DEPRECATED_BEFORE" redefined [enabled by default]

Is there any reason for it to be there?


Diffs
-

  cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc 

Diff: https://git.reviewboard.kde.org/r/119152/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119152/#review61876
---


Ah. QT_DISABLE_DEPRECATED_BEFORE defaults to QT_VERSION_CHECK(5, 0, 0) 
(qglobal.h).

That means basic functions such as QString::fromAscii are disabled because 
they're marked as deprecated since 5.0.
Question is: Do we really want to override the default value for 
QT_DISABLE_DEPRECATED_BEFORE?

- Kevin Funk


On July 6, 2014, 10:17 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119152/
> ---
> 
> (Updated July 6, 2014, 10:17 p.m.)
> 
> 
> Review request for KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> Do not define QT_DISABLE_DEPRECATED_BEFORE
> 
> When defining it in your own project, you'll get:
> :0:0: warning:
> "QT_DISABLE_DEPRECATED_BEFORE" redefined [enabled by default]
> 
> Is there any reason for it to be there?
> 
> 
> Diffs
> -
> 
>   cmake/modules/ECMQt4To5Porting.cmake 
> 4204fa541790aa38c74b9d6f0b2111af2157b2bc 
> 
> Diff: https://git.reviewboard.kde.org/r/119152/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Review Request 119241: Fix QExplicitlySharedDataPointer usage

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kservice


Description
---

Fix QExplicitlySharedDataPointer usage

One of the constructors of QExplicitlySharedDataPointer got disabled in
Qt 5.4 due to being to permissive.

Also see:
http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/


Diffs
-

  src/kbuildsycoca/kbuildservicefactory.cpp 
bc36a22ced38892a92656d37a5d63e768dec6d40 
  src/kbuildsycoca/kbuildservicegroupfactory.cpp 
ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 
  src/kbuildsycoca/kbuildservicetypefactory.cpp 
8f577a4267e8818e7e2cf5109068659439ca3221 
  src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 
  src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 
  src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd 
  src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 
  src/services/kservicetypefactory.cpp 7599c4c73220b2aca366f41ac5cd7d05abfa8afc 
  src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c 
  tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff 

Diff: https://git.reviewboard.kde.org/r/119241/diff/


Testing
---


Thanks,

Kevin Funk

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

Review Request 119242: Fix QExplicitlySharedDataPointer usage

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kio


Description
---

Fix QExplicitlySharedDataPointer usage

One of the constructors of QExplicitlySharedDataPointer got disabled in
Qt 5.4 due to being to permissive.

Also see:
http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/


Diffs
-

  src/widgets/kopenwithdialog.cpp 8cb659fde2028892de82bad64e0ea3ff285b5e3a 

Diff: https://git.reviewboard.kde.org/r/119242/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 119241: Fix QExplicitlySharedDataPointer usage

[Kevin Funk]

> On July 12, 2014, 2:01 p.m., Aleix Pol Gonzalez wrote:
> > tests/ksycocatest.cpp, line 104
> > <https://git.reviewboard.kde.org/r/119241/diff/1/?file=289736#file289736line104>
> >
> > Why does it need a static_cast if we're upcasting?
> > Also constructing a shared pointer from the data field in another one 
> > seems dangerous...

That' a downcast. The hierarchy is KService : KSycocaEntry : QSharedData.

Also, construcing it from the data field isn't dangerous -- because the 
ref-counter is inside the tracked object (QSharedData).
Note that QExplicitlySharedDataPointer is missing convenience API like we had 
in KSharedPtr, e.g. KSharedPtr::staticCast.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119241/#review62182
-------


On July 12, 2014, 9:41 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119241/
> ---
> 
> (Updated July 12, 2014, 9:41 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> Fix QExplicitlySharedDataPointer usage
> 
> One of the constructors of QExplicitlySharedDataPointer got disabled in
> Qt 5.4 due to being to permissive.
> 
> Also see:
> http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/
> 
> 
> Diffs
> -
> 
>   src/kbuildsycoca/kbuildservicefactory.cpp 
> bc36a22ced38892a92656d37a5d63e768dec6d40 
>   src/kbuildsycoca/kbuildservicegroupfactory.cpp 
> ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 
>   src/kbuildsycoca/kbuildservicetypefactory.cpp 
> 8f577a4267e8818e7e2cf5109068659439ca3221 
>   src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 
>   src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 
>   src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd 
>   src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 
>   src/services/kservicetypefactory.cpp 
> 7599c4c73220b2aca366f41ac5cd7d05abfa8afc 
>   src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c 
>   tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff 
> 
> Diff: https://git.reviewboard.kde.org/r/119241/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 119241: Fix QExplicitlySharedDataPointer usage

[Kevin Funk]

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

(Updated July 15, 2014, 10:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kservice


Description
---

Fix QExplicitlySharedDataPointer usage

One of the constructors of QExplicitlySharedDataPointer got disabled in
Qt 5.4 due to being to permissive.

Also see:
http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/


Diffs
-

  src/kbuildsycoca/kbuildservicefactory.cpp 
bc36a22ced38892a92656d37a5d63e768dec6d40 
  src/kbuildsycoca/kbuildservicegroupfactory.cpp 
ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 
  src/kbuildsycoca/kbuildservicetypefactory.cpp 
8f577a4267e8818e7e2cf5109068659439ca3221 
  src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 
  src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 
  src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd 
  src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 
  src/services/kservicetypefactory.cpp 7599c4c73220b2aca366f41ac5cd7d05abfa8afc 
  src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c 
  tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff 

Diff: https://git.reviewboard.kde.org/r/119241/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 119242: Fix QExplicitlySharedDataPointer usage

[Kevin Funk]

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

(Updated July 15, 2014, 10:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kio


Description
---

Fix QExplicitlySharedDataPointer usage

One of the constructors of QExplicitlySharedDataPointer got disabled in
Qt 5.4 due to being to permissive.

Also see:
http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/


Diffs
-

  src/widgets/kopenwithdialog.cpp 8cb659fde2028892de82bad64e0ea3ff285b5e3a 

Diff: https://git.reviewboard.kde.org/r/119242/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 119564: Add define to re-enable Qt functionality we depend on.

[Kevin Funk]

> On Aug. 2, 2014, 9:04 a.m., Alex Merry wrote:
> > I would rather change the code. The Qt behaviour was changed for a reason, 
> > to prevent accidental use of dangerous behaviour, and I'm not too keen on 
> > undoing that move for all software that uses KDECompilerSettings.
> 
> Sune Vuorela wrote:
> agreed.

Yep. I'm also *strongly* in favor of adjusting the code instead of enabling the 
define.

In fact, I thought I've fixed all of KF5. (It isn't?). 
There are some compile errors in code *using* KF5, which I'm trying to port 
ASAP.


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119564/#review63665
---


On Aug. 1, 2014, 4:06 p.m., Axel Rasmussen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119564/
> ---
> 
> (Updated Aug. 1, 2014, 4:06 p.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Bugs: 337472
> http://bugs.kde.org/show_bug.cgi?id=337472
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Upstream Qt commit e112c2e altered the way QExplicitlySharedDataPointer 
> behaves by default, such that it no longer uses a `static_cast` to cast 
> compatible pointers. A nontrivial amount of KDE code (I encountered the build 
> error in KService, although there are other users) depends on this 
> functionality, so this commit adds a define to the build system which 
> re-enables the code in Qt.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake fdc930e 
> 
> Diff: https://git.reviewboard.kde.org/r/119564/diff/
> 
> 
> Testing
> ---
> 
> I applied this patch, attempted to build KService, and the build succeeded, 
> rather than exhibiting the compile errors found in the log provided on the 
> bug report.
> 
> 
> Thanks,
> 
> Axel Rasmussen
> 
>

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

Re: Review Request 119564: Add define to re-enable Qt functionality we depend on.

[Kevin Funk]

> On Aug. 2, 2014, 9:04 a.m., Alex Merry wrote:
> > I would rather change the code. The Qt behaviour was changed for a reason, 
> > to prevent accidental use of dangerous behaviour, and I'm not too keen on 
> > undoing that move for all software that uses KDECompilerSettings.
> 
> Sune Vuorela wrote:
> agreed.
> 
> Kevin Funk wrote:
> Yep. I'm also *strongly* in favor of adjusting the code instead of 
> enabling the define.
> 
> In fact, I thought I've fixed all of KF5. (It isn't?). 
> There are some compile errors in code *using* KF5, which I'm trying to 
> port ASAP.
> 
> Axel Rasmussen wrote:
> Would we prefer just using `static_cast` like 
> QExplicitlySharedDataPointer used to do, or shall we use `dynamic_cast` and 
> check for `NULL` results to be extra safe? I am willing to write up a patch 
> that fixes this issue in KService over the next day or two.
> 
> Alex Merry wrote:
> I'd expect most of the cases to be suitable for `static_cast` (if you can 
> guarantee what it will be from the context). If in doubt, state your 
> uncertainty in the review request description so that reviewers know to take 
> extra care.

Note: KService has already been fixed two weeks ago -- see 
https://git.reviewboard.kde.org/r/119241/


- Kevin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119564/#review63665
---


On Aug. 1, 2014, 4:06 p.m., Axel Rasmussen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119564/
> ---
> 
> (Updated Aug. 1, 2014, 4:06 p.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules and KDE Frameworks.
> 
> 
> Bugs: 337472
> http://bugs.kde.org/show_bug.cgi?id=337472
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Upstream Qt commit e112c2e altered the way QExplicitlySharedDataPointer 
> behaves by default, such that it no longer uses a `static_cast` to cast 
> compatible pointers. A nontrivial amount of KDE code (I encountered the build 
> error in KService, although there are other users) depends on this 
> functionality, so this commit adds a define to the build system which 
> re-enables the code in Qt.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake fdc930e 
> 
> Diff: https://git.reviewboard.kde.org/r/119564/diff/
> 
> 
> Testing
> ---
> 
> I applied this patch, attempted to build KService, and the build succeeded, 
> rather than exhibiting the compile errors found in the log provided on the 
> bug report.
> 
> 
> Thanks,
> 
> Axel Rasmussen
> 
>

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

Re: Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE

[Kevin Funk]

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

(Updated Aug. 5, 2014, 8:06 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Stephen Kelly.


Repository: kdelibs4support


Description
---

Do not define QT_DISABLE_DEPRECATED_BEFORE

When defining it in your own project, you'll get:
:0:0: warning:
"QT_DISABLE_DEPRECATED_BEFORE" redefined [enabled by default]

Is there any reason for it to be there?


Diffs
-

  cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc 

Diff: https://git.reviewboard.kde.org/r/119152/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: kio_trash

[Kevin Funk]

On Sunday 17 August 2014 00:03:41 David Faure wrote:
> kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers
> API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash,
> support for trash in FileUndoManager, and I'm about to add a
> KIO::restoreFromTrash job).
> And KIO::trash is called from the file dialog (kdiroperator.cpp).
> So this is a missing runtime dependency if kde-workspace/kio-extras isn't
> installed.
> 
> How about we move kio_trash to the kio framework?
> 
> (If we agree, can someone do it? I still have no experience with doing this
> in a way that preserves the git history)

I guess that'd also fix my CI-related issue here [1], right:

QWARN  : GitInitTest::testRemoveEmptyFolder() couldn't create slave: "Unable 
to create io-slave:
klauncher said: Unknown protocol 'trash'.
"

(We're using KIO::trash, but the CI doesn't provide this particular slave 
because it's part of different module)

Greets

[1] 
http://build.kde.org/view/kdevelop/job/kdevplatform_frameworks_qt5/154/testReport/(root)/TestSuite/test_kdevgit/

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Porting uses of 'accuracy' in KMimeType API

[Kevin Funk]

Heya,

Context: Forward-porting some patches in KDevelop involving KMimeType API.

I've just noticed that in Qt5, QMimeDataBase/QMimeType doesn't allow me to 
retrieve the accuracy of a match anymore, while KMimeType did. For example, 
compare the possible arguments for QMimeDataBase::mimeTypeForUrl vs. 
KMimeType::findByUrl.

What's the suggested way to deal with this? As far as I can see, there are no 
porting notes about that particular matter.

(Interestingly, the QMimeDataBase implementation internally plays around with 
accuracies a lot, it just isn't exposed in the public API)

Thanks

[1] 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKMimeType.html#a3417e83a30cff614a01a29ca2a615443

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Porting uses of 'accuracy' in KMimeType API

[Kevin Funk]

On Friday 12 September 2014 10:50:36 David Faure wrote:
> On Friday 12 September 2014 09:39:42 Kevin Funk wrote:
> > Heya,
> > 
> > Context: Forward-porting some patches in KDevelop involving KMimeType API.
> > 
> > I've just noticed that in Qt5, QMimeDataBase/QMimeType doesn't allow me to
> > retrieve the accuracy of a match anymore, while KMimeType did. For
> > example,
> > compare the possible arguments for QMimeDataBase::mimeTypeForUrl vs.
> > KMimeType::findByUrl.
> > 
> > What's the suggested way to deal with this? As far as I can see, there are
> > no porting notes about that particular matter.
> 
> You're telling me everything I know already, but not the important bit which
> is: what do you need the accuracy for?

Well, this is ancient, performance-critical code inside KDevelop. We basically 
cache a extension -> language mapping for performance reasons. Just recently 
we introduced code that avoids caching extensions for which the KMimeType 
lookup yielded a very low accuracy.

Also see: https://git.reviewboard.kde.org/r/120085/

Note: I never touched that code myself.

> The mime matching tries its best to find out the mimetype based on what you
> give it (filename and/or content). The output of that is the best idea we
> have about the mimetype. What difference does it make if that's a 20% or an
> 80% accuracy?
> 
> > (Interestingly, the QMimeDataBase implementation internally plays around
> > with accuracies a lot, it just isn't exposed in the public API)
> 
> Yes, as per the mimetype spec.
> 
> My guess is that it was used as a workaround for bad api or implementation,
> like "try with the content, and if that's not accurate, try with the
> filename", or vice-versa. But QMimeDatabase has the right all-in-one methods
> for this, following the spec, i.e. "if both filename and content are
> available, then trust the filename, unless there are multiple mimetypes
> claiming the same glob, then look at content, and select the one that
> matches (or is a subclass of) one of the candidates based on the filename".
> 
> The intended way to use this is to use isDefault() on the QMimeType,
> if that's true then it couldn't find any specific mimetype for the file
> (i.e. basically accuracy 0). And otherwise, that's the mimetype.

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: plasmate fails to build on branch frameworks

[Kevin Funk]

On Sunday 14 September 2014 18:28:16 Marko Käning wrote:
> On 14 Sep 2014, at 16:24 , Marko Käning  wrote:
> > Linux/CI hang, because there was a missing dependency to kdevplatform.
> > This has been fixed by now, but Jenkins master hasn’t picked up the
> > dependency change yet.
> 
> After two hours I triggered another rebuild, which pulled the corrected deps
> in and eventually resulted in the same error as the OSX/CI system.
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Note: Plasmate needs to be fixed to work on the current kdevplatform.

We've done the invasive KUrl->QUrl port there which of course broke source 
compatibility.

Greets

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build error with frameworkintegration

[Kevin Funk]

On Monday 29 September 2014 15:32:31 Aleix Pol wrote:
> On Mon, Sep 29, 2014 at 1:25 PM, nerdopolis 
> wrote:
> > Hi.
> > 
> > It seems that a recent build error when trying to build Frameworks master
> > against QT 5.4. (well a warning being treated as an error)
> > 
> > I build all the Frameworks with my own scripts, because I need
> > checkinstall. However, other then changing the prefix to /opt, I am using
> > default configurations, except for turning on -DKDE_ENABLE_EXCEPTIONS, as
> > I
> > turned it on to get Frameworks to compile on 14.04, but I'm not sure if
> > that is needed anymore.
> > 
> > I am compiling on Ubuntu 14.10, and using the default gcc 4.9
> > 
> > This is the build error I get
> > [ 65%] Building CXX object
> > src/platformtheme/CMakeFiles/KDEPlatformTheme.dir/kfiletreeview.cpp.o
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.cpp: In member function ‘virtual QPlatformMenuItem*
> > SystemTrayMenu::createMenuItem() const’:
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.cpp:44:35: error: invalid new-expression of abstract class type
> > ‘SystemTrayMenuItem’> 
> >  return new SystemTrayMenuItem();
> >  
> >^
> > 
> > In file included from
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.cpp:20:0:
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtra
> > yicon.h:60:7: note:   because the following virtual functions are pure
> > within
> > 
> > ‘SystemTrayMenuItem’:
> >  class SystemTrayMenuItem : public QPlatformMenuItem
> >  
> >^
> > 
> > In file included from
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.h:23:0,> 
> >  from
> > 
> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.cpp:20:> 
> > /opt/include/QtGui/5.4.0/QtGui/qpa/qplatformmenu.h:81:18: note:
> >  virtual void QPlatformMenuItem::setIconSize(int)
> >  
> >  virtual void setIconSize(int size) = 0;
> >  
> >   ^

This seems to be a fairly new pure-virtual method in QPlatformMenu.

https://qt.gitorious.org/qt/qtbase/commit/b53f6fdd313f71f05b99093966736a8f7442ded8

For a work-around, to make it compile, implement that function and give it an 
empty body. We'll have to fix it properly of course :)

> > /srcbuild/kf5-frameworkintegration/src/platformtheme/kdeplatformsystemtray
> > icon.cpp:45:1: error: control reaches end of non-void function
> > [-Werror=return-type]> 
> >  }
> >  ^
> > 
> > cc1plus: some warnings being treated as errors
> > 
> > I even tried a clean rebuild of all kde frameworks master, and qt 5.4
> > 
> > How do I turn off werror?
> > 
> > Thanks.
> > ___
> > Kde-frameworks-devel mailing list
> > Kde-frameworks-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> https://git.reviewboard.kde.org/r/120422/diff/#
> 
> You don't turn off errors... ;)
> 
> Aleix

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 120435: Declare InheritanceChecker before actual use

[Kevin Funk]

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

Review request for KDE Frameworks and Ben Cooksley.


Repository: kcoreaddons


Description
---

Declare InheritanceChecker before actual use

This is actually not needed for "proper" compilers, because the use is inside a 
template,
The type is only required at instantiation time.

However, this patch makes the Coverity build tool happy. Without this patch,
we get an error for every translation unit including
kpluginfactory.h, telling us that "InheritanceChecker is not a
template"

Also see https://communities.coverity.com/thread/2903


Diffs
-

  src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 

Diff: https://git.reviewboard.kde.org/r/120435/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 120435: Declare InheritanceChecker before actual use

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120435/#review67849
---


Bump. This is a super trivial patch. :)

- Kevin Funk


On Sept. 30, 2014, 11:36 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120435/
> ---
> 
> (Updated Sept. 30, 2014, 11:36 a.m.)
> 
> 
> Review request for KDE Frameworks and Ben Cooksley.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Declare InheritanceChecker before actual use
> 
> This is actually not needed for "proper" compilers, because the use is inside 
> a template,
> The type is only required at instantiation time.
> 
> However, this patch makes the Coverity build tool happy. Without this patch,
> we get an error for every translation unit including
> kpluginfactory.h, telling us that "InheritanceChecker is not a
> template"
> 
> Also see https://communities.coverity.com/thread/2903
> 
> 
> Diffs
> -
> 
>   src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 
> 
> Diff: https://git.reviewboard.kde.org/r/120435/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 120435: Declare InheritanceChecker before actual use

[Kevin Funk]

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

(Updated Oct. 11, 2014, 8:40 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Ben Cooksley.


Repository: kcoreaddons


Description
---

Declare InheritanceChecker before actual use

This is actually not needed for "proper" compilers, because the use is inside a 
template,
The type is only required at instantiation time.

However, this patch makes the Coverity build tool happy. Without this patch,
we get an error for every translation unit including
kpluginfactory.h, telling us that "InheritanceChecker is not a
template"

Also see https://communities.coverity.com/thread/2903


Diffs
-

  src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 

Diff: https://git.reviewboard.kde.org/r/120435/diff/


Testing
---


Thanks,

Kevin Funk

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

Replacement for KMimeType::isBinaryData?

[Kevin Funk]

Heya,

I didn't find a suitable replacement for KMimeType::isBinaryData in KF5. Is 
there some?

http://lxr.kde.org/ident?v=kf5-qt5&_i=isBinaryData&_remember=1 shows exactly 
two users of this function.

Worth considering upstreaming to Qt?

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121007: Fix warning when using newer upower backend.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121007/#review69967
---

Ship it!


Finally!

- Kevin Funk


On Nov. 6, 2014, 1:05 a.m., Milian Wolff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121007/
> ---
> 
> (Updated Nov. 6, 2014, 1:05 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: solid
> 
> 
> Description
> ---
> 
> "No such signal org::freedesktop::UPower::DeviceAdded(...)"
> 
> The signature change can be detected at runtime using Qt's QMetaObject
> introspection mechanism. That prevents us from emitting the two
> pesky warnings at runtime, polluting our konsoles.
> 
> Google is full of that warning, and there is also: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1056769
> 
> 
> Diffs
> -
> 
>   src/solid/devices/backends/upower/upowermanager.cpp 
> 53c858093a1c439f0faca0c956a51199f4e882e4 
> 
> Diff: https://git.reviewboard.kde.org/r/121007/diff/
> 
> 
> Testing
> ---
> 
> warning gone!
> 
> 
> Thanks,
> 
> Milian Wolff
> 
>

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

Review Request 121082: Add TODO for private signals in KJob

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

Can't change that now because it would be BIC.


Diffs
-

  src/lib/jobs/kjob.h d4b7abd3774626f450aadb4e43185ed5bb654792 

Diff: https://git.reviewboard.kde.org/r/121082/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121082: Add TODO for private signals in KJob

[Kevin Funk]

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

(Updated Nov. 11, 2014, 8:48 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

Can't change that now because it would be BIC.


Diffs
-

  src/lib/jobs/kjob.h d4b7abd3774626f450aadb4e43185ed5bb654792 

Diff: https://git.reviewboard.kde.org/r/121082/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: How to port KTabBar::mouseMiddleClick?

[Kevin Funk]

On Monday 10 November 2014 15:19:22 Nicolás Alvarez wrote:
> 2014-11-09 7:28 GMT-03:00 Frank Reininghaus :
> > Hi,
> > 
> > 2014-11-06 2:59 GMT+01:00 Milian Wolff:
> >> Hey all,
> >> 
> >> what do I do to get middle-click-closes-tab in Qt 5 without KTabBar?
> >> Previously, we used KTabBar and its mouseMiddleClick signal.
> > 
> > AFAIK, currently the only solution is to subclass QTabBar, override
> > the mousePressEvent method and emit a signal from there. Dolphin uses
> > this approach. There were many other reasons why Emmanuel created a
> > custom QTabBar subclass for Dolphin though .
> > 
> > If many apps need the "middle click to close" bevavior, then
> > reanimating KTabBar or getting this functionality into QTabBar might
> > be better than making every app create its own tab bar class.
> 
> Or maybe contribute mouseMiddleClick to QTabBar?
> (I'm not volunteering :P)

Yep. I'm wondering if an a patch just reacting on middle clicks would be 
accepted. It's not like it breaks existing work flows, it's just there for 
convenience.

Grepping qtbase showed that QMdiArea has a similar feature:

widgets/qmdiarea.cpp
582-void QMdiAreaTabBar::mousePressEvent(QMouseEvent *event)
583-{
584:if (event->button() != Qt::MidButton) {
585-QTabBar::mousePressEvent(event);
586-return;
587-}
588-
589-QMdiSubWindow *subWindow = subWindowFromIndex(tabAt(event->pos()));
590-if (!subWindow) {
591-event->ignore();
592-return;
593-}
594-
595-subWindow->close();
596-}

Worth trying to patch this into QTabBar right away, I think.

Cheers

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 121160: Add libgit2 compile-time check for threads support

[Kevin Funk]

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

Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Add libgit2 compile-time check for threads support


Diffs
-

  CMakeLists.txt 5cace5fead7c80ede9fa82643426ab5a5e5a4035 
  src/test_libgit2_threads.c PRE-CREATION 
  src/utils/kateglobal.cpp 6e3362802c213c914430a4775ab15e3515729474 

Diff: https://git.reviewboard.kde.org/r/121160/diff/


Testing
---

Should fix the CI failure. Compiles fine for me (with threads support)


Thanks,

Kevin Funk

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

Re: Review Request 121160: Add libgit2 compile-time check for threads support

[Kevin Funk]

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

(Updated Nov. 17, 2014, 10:45 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Add libgit2 compile-time check for threads support


Diffs
-

  CMakeLists.txt 5cace5fead7c80ede9fa82643426ab5a5e5a4035 
  src/test_libgit2_threads.c PRE-CREATION 
  src/utils/kateglobal.cpp 6e3362802c213c914430a4775ab15e3515729474 

Diff: https://git.reviewboard.kde.org/r/121160/diff/


Testing
---

Should fix the CI failure. Compiles fine for me (with threads support)


Thanks,

Kevin Funk

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

Review Request 121172: Move libgit2-related macro defs into config.h

[Kevin Funk]

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

Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Only recompile dependent files in case of dep changes


Diffs
-

  CMakeLists.txt 5a597818e8b5a16899c10fd4a460e09bb233 
  config.h.cmake e1c9f34cf24eb516c540db3288c93ad5bd093df3 
  src/document/katedocument.cpp aac17c719cbabf78c2135062fe566671713cea02 
  src/utils/kateglobal.cpp 473240514eaeb7f108a5bc0a06e182d4aacc7a80 

Diff: https://git.reviewboard.kde.org/r/121172/diff/


Testing
---


Thanks,

Kevin Funk

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

Review Request 121173: Use correct version in kbuildsycoca5 executable

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kservice


Description
---

Use correct version in kbuildsycoca5 executable


Diffs
-

  src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 

Diff: https://git.reviewboard.kde.org/r/121173/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121173: Use correct version in kbuildsycoca5 executable

[Kevin Funk]

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

(Updated Nov. 19, 2014, 8:21 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kservice


Description
---

Use correct version in kbuildsycoca5 executable


Diffs
-

  src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 

Diff: https://git.reviewboard.kde.org/r/121173/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121172: Move libgit2-related macro defs into config.h

[Kevin Funk]

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

(Updated Nov. 24, 2014, 2:31 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Only recompile dependent files in case of dep changes


Diffs
-

  CMakeLists.txt 5a597818e8b5a16899c10fd4a460e09bb233 
  config.h.cmake e1c9f34cf24eb516c540db3288c93ad5bd093df3 
  src/document/katedocument.cpp aac17c719cbabf78c2135062fe566671713cea02 
  src/utils/kateglobal.cpp 473240514eaeb7f108a5bc0a06e182d4aacc7a80 

Diff: https://git.reviewboard.kde.org/r/121172/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121276: KPluginInfo::category() instead of property("X-KDE-PluginInfo-Category")

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121276/#review71029
---

Ship it!


Ship It!

- Kevin Funk


On Nov. 27, 2014, 6:07 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121276/
> ---
> 
> (Updated Nov. 27, 2014, 6:07 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcmutils
> 
> 
> Description
> ---
> 
> KPluginInfo::category() instead of property("X-KDE-PluginInfo-Category")
> 
> 
> Diffs
> -
> 
>   src/kpluginselector.cpp a0d4568c9004b97a3130e699f10847540065a82a 
> 
> Diff: https://git.reviewboard.kde.org/r/121276/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

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

Where are my systray icons cont'd

[Kevin Funk]

Heya,

I'm still missing my beloved systray icons for a few applications in Plasma 5 
on Ubuntu 14.10 (using distro provided packages). 

I have every package installed according to [1] (sni-qt, libindicator*), but 
still, systray icons for Pidgin or Skype won't show up. Also see [2].

What am I doing wrong? :)

PS: I really don't have a clue about implementation details here, so any hints 
are more than welcome.
PPS: Doesn't seem distro-related, Helio has the same issues on Fedora, self-
compiled Plasma 5

[1] http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/
[2] https://developer.pidgin.im/ticket/16456

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Where are my systray icons cont'd

[Kevin Funk]

On Thursday 27 November 2014 21:10:10 Kevin Funk wrote:
> Heya,
> 
> I'm still missing my beloved systray icons for a few applications in Plasma
> 5 on Ubuntu 14.10 (using distro provided packages).
> 
> I have every package installed according to [1] (sni-qt, libindicator*), but
> still, systray icons for Pidgin or Skype won't show up. Also see [2].
> 
> What am I doing wrong? :)
> 
> PS: I really don't have a clue about implementation details here, so any
> hints are more than welcome.
> PPS: Doesn't seem distro-related, Helio has the same issues on Fedora, self-
> compiled Plasma 5
> 
> [1]
> http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/
> [2] https://developer.pidgin.im/ticket/16456

Alright. I fixed my issue with "Pidgin" by installing another plugin: 
Installed the 'pidgin-indicator' plugin [1], which provides an AppIndicator.

PS: IOW that means, Xembed-based icons still don't seem to work for me. Is 
this an Ubuntu-only problem or am I missing something? (I have a Qt5-based 
app, using QSystemTrayIcon, whose systray icon doesn't show up)

[1] http://www.webupd8.org/2014/01/pidgin-indicator-ubuntu-appindicator.html

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: OSX/CI: kde-baseapps fails to build on branch frameworks

[Kevin Funk]

On Thursday 18 December 2014 22:20:54 Marko Käning wrote:
> /Users/marko/WC/KDECI-builds/kde-baseapps/dolphin/src/tests/kfileitemlistvie
> wtest.cpp:91:16: error: no matching constructor for initialization of
> 'QSignalSpy' QSignalSpy itemsRemovedSpy(m_model,
> &KFileItemModel::itemsRemoved); ^  
> ~~

Note: That needs Qt 5.4 -- QSignalSpy can take a PMF only since that.

> /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsi
> gnalspy.h:61:14: note: candidate constructor not viable: no known conversion
> from 'void (KItemModelBase::*)(const KItemRangeList &)' to 'const char *'
> for 2nd argument explicit QSignalSpy(const QObject *obj, const char
> *aSignal)
>  ^
> /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsig
> nalspy.h:58:7: note: candidate constructor (the implicit copy constructor)
> not viable: requires 1 argument, but 2 were provided class QSignalSpy:
> public QObject, public QList >
>   ^
> Building CXX object
> dolphin/src/CMakeFiles/kcm_dolphinviewmodes.dir/settings/viewmodes/viewsett
> ingstab.cpp.o 2 errors generated.
> [ 50%] make[2]: ***
> [dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/kfileitemlistviewte
> st.cpp.o] Error 1 make[1]: ***
> [dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/all] Error 2

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

FYI: KF5Plasma fails to build under MSVC

[Kevin Funk]

See log:

z:\kderoot\download\git\plasma\src\plasma\private/framesvg_helpers.h(47) : 
error C2051: case expression not constant
z:\kderoot\download\git\plasma\src\plasma\private/framesvg_helpers.h(49) : 
error C2051: case expression not constant
z:\kderoot\download\git\plasma\src\plasma\private/framesvg_helpers.h(51) : 
error C2051: case expression not constant
z:\kderoot\download\git\plasma\src\plasma\private/framesvg_helpers.h(53) : 
error C2051: case expression not constant

(more issues of this type (count: 4 more) down in this file)

I could fix this by adding a `EnabledBorder::TopLeft = TopBorder | LeftBorder, 
...` and use this, but this is not the right fix semantically.
Adding another enumaration along `enum foo { TopLeft = 
EnabledBorders::TopBorder | EnabledBorders::LeftBorder, ...}` inside 
framesvg_helpers.h isn't accepted by MSVC either (throws 'expected constant 
expr').

Note: Rest builds fine.

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Replacement for KMimeType::isBinaryData?

[Kevin Funk]

On Monday 05 January 2015 15:04:48 David Faure wrote:
> On Monday 05 January 2015 12:39:36 Milian Wolff wrote:
> > In KDevelop, we support file/project templates. These are archives of
> > files
> > that may contain placeholders that will get replaced with user input when
> > a
> > file/project is created from a template. This replacement can only work on
> > non-binary data, which is what the code checked in KDE4 times. In slightly
> > abbreviated code:
> > 
> > AppWizardPlugin::copyFileAndExpandMacros(sourceFile, destFile)
> > {
> > 
> >   if (isBinaryData(source)) {
> >   
> > KIO::copy(source, dest);
> >   
> >   } else {
> >   
> > destFile << expandMacros(sourceFile);
> >   
> >   }
> > 
> > }
> 
> I see.
> 
> > You have more knowledge about mimetypes than us. Can we maybe just check
> > whether the mimetype of sourceFile inherits text/plain?
> 
> Excellent idea. This would go a long way indeed.
> 
> I tried to find if this wouldn't work for some mimetypes, but I can't find
> an example - it seems that it would indeed work just fine.

+1

Can you go ahead and remove our copy of isBinaryData in kdevplatform.git then?

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS

[Kevin Funk]

On Tuesday 06 January 2015 23:55:48 Marko Käning wrote:
> Hi Christoph,
> 
> I’ve found that these projects do not make use of
> KF5_INSTALL_TARGETS_DEFAULT_ARGS at the moment:
> 
>  - systemsettings
>  - muon
>  - rocs
>  - libkdegames
>  - kiten
>  - cantor
>  - kolourpaint
>  - libkmahjongg
> 
> See for details below in order of appearance.
> 
> I figure this is only the beginning of it and more projects might turn up in
> the future.

Is KF5_INSTALL_TARGETS_DEFAULT_ARGS even correct for non-frameworks projects?
KF5_INSTALL_TARGETS_DEFAULT_ARGS's INCLUDES location points to $SOMETHING/KF5.

KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems 
more appropriate.

@Alex, please elaborate.

> 
> Thanks for taking care of these.
> 
> Regards,
> Marko
> 
> 
> 
> 
> P.S.: I’ve tested locally to prepend "KF5_” to INSTALL_TARGETS_DEFAULT_ARGS
>   for project systemsettings only, which worked fine and made the
> project install successfully again here on my OSX/CI system.
> 
> 
> 
> 
> P.P.S.: I realised by now that there are no changes on the production
> branch, which probably means that there was some change in ECM or wherever
> provoking these issues...
> 
> 
> 
> 
> ---
> 
> systemsettings:
> 
> CMake Error at core/CMakeLists.txt:37 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "systemsettingsview”.
> ---
> 
> muon:
> 
> CMake Error at libmuon/notifiers/CMakeLists.txt:7 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "MuonNotifiers".
> 
> CMake Error at libmuon/CMakeLists.txt:63 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "muonprivate”.
> ---
> 
> rocs:
> 
> CMake Error at libgraphtheory/CMakeLists.txt:106 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "rocsgraphtheory”.
> ---
> 
> libkdegames:
> 
> CMake Error at CMakeLists.txt:163 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "KF5KDEGames".
> 
> CMake Error at CMakeLists.txt:222 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "KF5KDEGamesPrivate”.
> ---
> 
> kiten:
> 
> CMake Error at lib/CMakeLists.txt:37 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "kiten".
> ---
> 
> cantor:
> 
> CMake Error at src/lib/CMakeLists.txt:75 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "cantorlibs”.
> 
> CMake Error at src/CMakeLists.txt:25 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "cantor_config".
> ---
> 
> kolourpaint:
> 
> CMake Error at CMakeLists.txt:579 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "kolourpaint_lgpl".
> ---
> 
> libkmahjongg:
> 
> CMake Error at CMakeLists.txt:64 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "KF5KMahjongglib".
> 
> CMake Error at CMakeLists.txt:67 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "KF5KMahjongglib".
> ---
> 
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121931: Unbreak KRecursiveFilterProxyModel for Qt 5.5.0+.

[Kevin Funk]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121931/#review73523
---

Ship it!


Ship It!

- Kevin Funk


On Jan. 8, 2015, 6:10 p.m., Milian Wolff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121931/
> ---
> 
> (Updated Jan. 8, 2015, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks and Stephen Kelly.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> The upstream commit f96baeb75fc36a41d2b08f880536cee5a8041e79
> with the title:
> 
> QSortFilterProxyModel: honor the roles parameter of dataChanged
> 
> changes the signature of the private _q_sourceDataChanged slot
> of QSortFilterProxyModel. I talked to Peppe and he told me to just
> use the new signature from Qt 5.5 and onwards. Note that the vector
> of roles was present in the dataChanged signal from 5.0 onwards
> already. It was simply ignored by QSFPM so far.
> 
> Indeed, this patch fixes the following crash on Kate startup for me:
> 
> QMetaObject::invokeMethod: QMetaObject::invokeMethod: No such method
> KRecursiveFilterProxyModel::_q_sourceDataChanged(QModelIndex,QModelIndex)
> Candidates are:
> _q_sourceDataChanged(QModelIndex,QModelIndex,QVector)
> ASSERT: "success" in file
> kf5/src/frameworks/kitemmodels/src/krecursivefilterproxymodel.cpp, line 55
> 
> 
> Diffs
> -
> 
>   src/krecursivefilterproxymodel.h cf14c12d064c864e5fb03ccb1e741b57c615b127 
>   src/krecursivefilterproxymodel.cpp b0753caea8693089873f161c123487a1893d5e01 
> 
> Diff: https://git.reviewboard.kde.org/r/121931/diff/
> 
> 
> Testing
> ---
> 
> sadly, there are no unit tests for this. but I can use Kate again without 
> crashes and there are no warnings on startup either.
> 
> 
> Thanks,
> 
> Milian Wolff
> 
>

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

Review Request 121991: New porting helper: convert-to-cmake-automoc.pl

[Kevin Funk]

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

Review request for KDE Frameworks.


Repository: kde-dev-scripts


Description
---

New porting helper: convert-to-cmake-automoc.pl

As the name suggests, this helper tries to port cpp files to CMake's
automoc. It attempts to remove files such as '#include ".moc"'
from cpp files where it can, and includes '#include
"moc_.cpp"' as fallback.

More information inside the documentation of the script


Diffs
-

  kf5/convert-to-cmake-automoc.pl PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/121991/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121991: New porting helper: convert-to-cmake-automoc.pl

[Kevin Funk]

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

(Updated Jan. 11, 2015, 7:26 p.m.)


Review request for KDE Frameworks.


Changes
---

K_PLUGIN_FACTORY requires "#include foo.moc" inside the source as well.


Repository: kde-dev-scripts


Description (updated)
---

New porting helper: convert-to-cmake-automoc.pl

As the name suggests, this helper tries to port cpp files to CMake's
automoc. It attempts to remove files such as '#include ".moc"'
from cpp files where it can, and includes '#include
"moc_.cpp"' as fallback.

More information inside the documentation of the script


Diffs (updated)
-

  kf5/convert-to-cmake-automoc.pl PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/121991/diff/


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 121991: New porting helper: convert-to-cmake-automoc.pl

[Kevin Funk]

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

(Updated Jan. 11, 2015, 7:29 p.m.)


Review request for KDE Frameworks and Laurent Montel.


Repository: kde-dev-scripts


Description
---

New porting helper: convert-to-cmake-automoc.pl

As the name suggests, this helper tries to port cpp files to CMake's
automoc. It attempts to remove files such as '#include ".moc"'
from cpp files where it can, and includes '#include
"moc_.cpp"' as fallback.

More information inside the documentation of the script


Diffs
-

  kf5/convert-to-cmake-automoc.pl PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/121991/diff/


Testing
---


Thanks,

Kevin Funk

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