Re: Review Request 112900: Prepare KDNSSD for moving

[Kevin Ottens]

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


Yes, looks like a tier 2 in that case. I wonder if that KConfig link could be 
spared though, it looks rather minimal somehow.


staging/kde4support/CMakeLists.txt


How is it related to the rest of the patch?


- Kevin Ottens


On Sept. 23, 2013, 5:29 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112900/
> ---
> 
> (Updated Sept. 23, 2013, 5:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Prepares the module to be moved to its own tier.
> 
> There's a rather uncommon case with this module because there's a dependency 
> against KConfig, but it only applies to when it's compiled with the mdnsd 
> backend (only when there's no Avahi but mDns instead). I guess this makes it 
> tier 2, but I'm not all that sure about that.
> 
> 
> Diffs
> -
> 
>   dnssd/CMakeLists.txt a2dd8e6 
>   dnssd/KDNSSDConfig.cmake.in PRE-CREATION 
>   dnssd/src/CMakeLists.txt 47587af 
>   dnssd/src/avahi-publicservice.cpp 119c5a8 
>   dnssd/src/mdnsd-publicservice.cpp 2a775fa 
>   dnssd/src/servicemodel.cpp 348db57 
>   staging/kde4support/CMakeLists.txt 24ee457 
> 
> Diff: http://git.reviewboard.kde.org/r/112900/diff/
> 
> 
> Testing
> ---
> 
> Builds, there are no tests.
> 
> 
> 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 112785: Add ki18n_wrap_ui macro to ki18nMacros

[Kevin Ottens]

> On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote:
> > I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least 
> > partly.
> 
> Jeremy Whiting wrote:
> well, qt5_wrap_ui wasn't around when this was created (as 
> kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look 
> into making it use qt5_wrap_ui.

Could you please look into it?


- Kevin


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


On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112785/
> ---
> 
> (Updated Sept. 17, 2013, 7:56 p.m.)
> 
> 
> Review request for KDE Frameworks and Alexander Neundorf.
> 
> 
> Description
> ---
> 
> It builds and installs, but doesn't seem to be usable from within kdelibs, 
> i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect 
> one more thing is needed to make it work from within kdelibs builds.
> 
> 
> Diffs
> -
> 
>   tier2/ki18n/CMakeLists.txt d0ed448 
>   tier2/ki18n/KI18nConfig.cmake.in 18b6e2f 
>   tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION 
>   tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112785/diff/
> 
> 
> Testing
> ---
> 
> Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

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

Re: Review Request 112907: Move KEmoticons framework to tier3

[Stephen Kelly]

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


Please split this into multiple patches. The move should be the last patch and 
it should do almost nothing but the actual move.


staging/kemoticons/autotests/CMakeLists.txt


This is wrong. You probably need to add 

 find_package(Qt5Test)


- Stephen Kelly


On Sept. 23, 2013, 7:24 p.m., David Gil Oliva wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112907/
> ---
> 
> (Updated Sept. 23, 2013, 7:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Move KEmoticons framework to tier3
> 
> Done:
> -Adjust the CMakeLists.txt to the new location.
> -Substitute kde_add_plugin to add_library.
> -Substitute Qt5::Xml to Qt5Xml in target_link_libraries
> -Substitute Qt5::Test to Qt5Test in target_link_libraries
> 
> TODO:
> Modify API to make it more coherent
> 
> 
> Diffs
> -
> 
>   staging/CMakeLists.txt 5c52cbe 
>   staging/kemoticons/CMakeLists.txt  
>   staging/kemoticons/KEmoticonsConfig.cmake.in  
>   staging/kemoticons/autotests/CMakeLists.txt b7e890c 
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-1.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-1.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-2.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-2.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-3.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-3.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-4.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-4.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-5.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-5.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-6.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-6.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-7.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-7.output  
>   staging/kemoticons/autotests/kemoticontest.h  
>   staging/kemoticons/autotests/kemoticontest.cpp  
>   staging/kemoticons/src/CMakeLists.txt  
>   staging/kemoticons/src/core/CMakeLists.txt  
>   staging/kemoticons/src/core/kemoticons.h  
>   staging/kemoticons/src/core/kemoticons.cpp  
>   staging/kemoticons/src/core/kemoticonsTheme.desktop  
>   staging/kemoticons/src/core/kemoticonsprovider.h  
>   staging/kemoticons/src/core/kemoticonsprovider.cpp  
>   staging/kemoticons/src/core/kemoticonstheme.h  
>   staging/kemoticons/src/core/kemoticonstheme.cpp  
>   staging/kemoticons/src/providers/CMakeLists.txt  
>   staging/kemoticons/src/providers/adium/CMakeLists.txt c94c0be 
>   staging/kemoticons/src/providers/adium/adium_emoticons.h  
>   staging/kemoticons/src/providers/adium/adium_emoticons.cpp  
>   staging/kemoticons/src/providers/adium/emoticonstheme_adium.desktop  
>   staging/kemoticons/src/providers/kde/CMakeLists.txt e6d4243 
>   staging/kemoticons/src/providers/kde/emoticonstheme_kde.desktop  
>   staging/kemoticons/src/providers/kde/kde_emoticons.h  
>   staging/kemoticons/src/providers/kde/kde_emoticons.cpp  
>   staging/kemoticons/src/providers/pidgin/CMakeLists.

Re: Review Request 112909: Remove KDE print stuff that has been ported to Qt5

[Kevin Ottens]

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


I'm torn on that one... If we're sure the remaining features aren't useful, I 
would propose to just move all the printing stuff from KDE4Attic to 
KDE4Support. If we're not sure, then we should move the printing stuff from 
KDE4Attic to the upcoming KPrintUtils (patch pending, it's going to contain a 
single class so far).

If we go for the KPrintUtils route I think it's a good goal to make it useless 
over time by keeping to get features merged upstream in Qt. So it's really a 
question of how fast we feel like deprecating those features.

- Kevin Ottens


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 112828: Provide ecm_add_unit_test() and ecm_add_multiple_unit_tests()

[Kevin Ottens]

> On Sept. 23, 2013, 10:49 a.m., Kevin Ottens wrote:
> > modules/ECMAddUnitTest.cmake, line 23
> > 
> >
> > I agree, it's about "automated" (vs "manual") tests here. We've no way 
> > when writing this macro to know if the user will make an automated unit 
> > test or integration test or...
> 
> Alexander Neundorf wrote:
> As I said, in cmake, a not-automated test is not a test. I.e. in cmake a 
> test is created via add_test(). This implies that it can be automatically 
> executed. Anything else is not a test in cmake.
> 
> How about ecm_add_tests()  ?
>

What would we use for the manual tests then? Just wondering since we have a 
similar macro copy/pasted all over the place for the manual tests. So I 
wouldn't be surprised if we see a patch to cover it later on.

Oh, I guess it could be ecm_add_tests vs ecm_add_manual_tests when the time 
comes.

So yeah I don't really mind if it's named ecm_add_tests or ecm_add_auto_tests. 
I'd avoid ecm_add_unit_test for the reasons I mentioned previously (it's not 
necessarily for unit tests).


- Kevin


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


On Sept. 19, 2013, 3:57 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112828/
> ---
> 
> (Updated Sept. 19, 2013, 3:57 p.m.)
> 
> 
> Review request for Extra Cmake Modules and KDE Frameworks.
> 
> 
> Description
> ---
> 
> Add a new functions to add unit tests
> 
> Every framework in KF5 has a macro similar to these, this reduces
> the unnecessary duplication inside all of the frameworks
> 
> 
> Diffs
> -
> 
>   modules/ECMAddUnitTest.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112828/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

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

Re: Review Request 112907: Move KEmoticons framework to tier3

[Kevin Ottens]

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



staging/kemoticons/src/providers/adium/CMakeLists.txt


Same comment applies than the one from Stephen for your Qt5Test change 
earlier in that patch.



staging/kemoticons/src/providers/kde/CMakeLists.txt


ditto



staging/kemoticons/src/providers/xmpp/CMakeLists.txt


ditto


- Kevin Ottens


On Sept. 23, 2013, 7:24 p.m., David Gil Oliva wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112907/
> ---
> 
> (Updated Sept. 23, 2013, 7:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Move KEmoticons framework to tier3
> 
> Done:
> -Adjust the CMakeLists.txt to the new location.
> -Substitute kde_add_plugin to add_library.
> -Substitute Qt5::Xml to Qt5Xml in target_link_libraries
> -Substitute Qt5::Test to Qt5Test in target_link_libraries
> 
> TODO:
> Modify API to make it more coherent
> 
> 
> Diffs
> -
> 
>   staging/CMakeLists.txt 5c52cbe 
>   staging/kemoticons/CMakeLists.txt  
>   staging/kemoticons/KEmoticonsConfig.cmake.in  
>   staging/kemoticons/autotests/CMakeLists.txt b7e890c 
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-1.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-1.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-2.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-2.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-3.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-3.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-4.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-4.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-5.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-5.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-6.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-6.output  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-7.input  
>   staging/kemoticons/autotests/emoticon-parser-testcases/working-7.output  
>   staging/kemoticons/autotests/kemoticontest.h  
>   staging/kemoticons/autotests/kemoticontest.cpp  
>   staging/kemoticons/src/CMakeLists.txt  
>   staging/kemoticons/src/core/CMakeLists.txt  
>   staging/kemoticons/src/core/kemoticons.h  
>   staging/kemoticons/src/core/kemoticons.cpp  
>   staging/kemoticons/src/core/kemoticonsTheme.desktop  
>   staging/kemoticons/src/core/kemoticonsprovider.h  
>   staging/kemoticons/src/core/kemoticonsprovider.cpp  
>   staging/kemoticons/src/core/kemoticonstheme.h  
>   staging/kemoticons/src/core/kemoticonstheme.cpp  
>   staging/kemoticons/src/providers/CMakeLists.txt  
>   staging/kemoticons/src/providers/adium/CMakeLists.txt c94c0be 
>   staging/kemoticons/src/providers/adium/adium_emoticons.h  
>   staging/kemoticons/src/providers/adium/adium_emoticons.cpp  
>   staging/kemoticons/src/providers/adium/emoticonstheme_adium.desktop  
>   staging/kemoticons/src/providers/kde/CMakeLists.txt e6d4243 
>   staging/kemoticons/src/providers/kde/emoticonstheme_kde.desktop  
>   staging/kemoticons/src/pr

Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros

[Chusslove Illich]

> On Sept. 23, 2013, 12:37 p.m., Kevin Ottens wrote:
> > I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least 
> > partly.
> 
> Jeremy Whiting wrote:
> well, qt5_wrap_ui wasn't around when this was created (as 
> kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look 
> into making it use qt5_wrap_ui.
> 
> Kevin Ottens wrote:
> Could you please look into it?

This is why I asked Jeremy in the other review, that motivated this one, to
commit using the plain qt5_wrap_ui, until I get to doing the proper thing
for k18n_wrap_ui.

Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I
would call it k18n_qt5_wrap_ui. If uic would have some additional command
line options, k18n_wrap_ui would internally really be a wrapper for
qt5_wrap_ui; but without these options, it may end up just copying the code
(little as there is) from qt5_wrap_ui and adding its own stuff atop.
k18n_qt5_wrap_ui must also have its own macro options to support the new/
modified ki18n functionality (namely setting the translation domain and
activating the KUIT markup processing).


- Chusslove


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


On Sept. 17, 2013, 9:56 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112785/
> ---
> 
> (Updated Sept. 17, 2013, 9:56 p.m.)
> 
> 
> Review request for KDE Frameworks and Alexander Neundorf.
> 
> 
> Description
> ---
> 
> It builds and installs, but doesn't seem to be usable from within kdelibs, 
> i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect 
> one more thing is needed to make it work from within kdelibs builds.
> 
> 
> Diffs
> -
> 
>   tier2/ki18n/CMakeLists.txt d0ed448 
>   tier2/ki18n/KI18nConfig.cmake.in 18b6e2f 
>   tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION 
>   tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112785/diff/
> 
> 
> Testing
> ---
> 
> Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

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

Build failed in Jenkins: kdelibs_frameworks_qt5 #1246

[KDE CI System]

See 

Changes:

[mklapetek] Use QStringLiteral rather than QLatin1String

[steveire] Define isnan() for MSVC

[steveire] Don't use QStringLiteral as a default value initializer.

[steveire] Use the correct moc include on Windows.

[steveire] Replace numbers[m_count] with a vector.

[steveire] Enable a successful partial-build with MSVC.

[steveire] Require the CMake 2.8.11 final release.

[steveire] Fix up public dependencies of KConfigWidgets.

[steveire] Fix up public dependencies of KDE4Attic.

[steveire] Fix up kservice public dependencies.

[steveire] Fix up the public depends of KIconThemes.

[steveire] Fix up KJobWidgets public dependencies.

[steveire] Fix up KIO public dependencies.

[steveire] Fix up KXmlGui public dependencies.

[steveire] Fix up KInterprocessWindowing dependencies.

--
[...truncated 508 lines...]
-- Looking for include file sys/select.h - found
-- Check size of struct ucred
-- Check size of struct ucred - failed
-- KF5[InstallDirs]: Loaded settings from 
/srv/jenkins/install/linux/x64_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDEInstallDirs.cmake
-- KF5[CMake]: Loaded settings from 
/srv/jenkins/install/linux/x64_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDECMakeSettings.cmake
-- KF5[Compiler]: Loaded settings from 
/srv/jenkins/install/linux/x64_64/g++/qt5/kdesupport/extra-cmake-modules/master/share/ECM/kde-modules/KDECompilerSettings.cmake
CMake Warning at dnssd/CMakeLists.txt:27 (find_package):
  By not providing "FindAvahi.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Avahi", but
  CMake did not find one.

  Could not find a package configuration file provided by "Avahi" with any of
  the following names:

AvahiConfig.cmake
avahi-config.cmake

  Add the installation prefix of "Avahi" to CMAKE_PREFIX_PATH or set
  "Avahi_DIR" to a directory containing one of the above files.  If "Avahi"
  provides a separate development package or SDK, be sure it has been
  installed.


CMake Warning at dnssd/src/CMakeLists.txt:39 (find_package):
  By not providing "FindDNSSD.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "DNSSD", but
  CMake did not find one.

  Could not find a package configuration file provided by "DNSSD" with any of
  the following names:

DNSSDConfig.cmake
dnssd-config.cmake

  Add the installation prefix of "DNSSD" to CMAKE_PREFIX_PATH or set
  "DNSSD_DIR" to a directory containing one of the above files.  If "DNSSD"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Found ACL support: /usr/lib64/libacl.so;/usr/lib64/libattr.so
-- Looking for getgrouplist
-- Looking for getgrouplist - not found
-- Looking for include file arpa/nameser_compat.h
-- Looking for include file arpa/nameser_compat.h - not found
-- Looking for include file arpa/nameser8_compat.h
-- Looking for include file arpa/nameser8_compat.h - not found
-- Looking for include files sys/types.h, netinet/in.h
-- Looking for include files sys/types.h, netinet/in.h - found
-- Looking for res_init in resolv
-- Looking for res_init in resolv - not found
-- Looking for __res_init in resolv
-- Looking for __res_init in resolv - found
-- Looking for gethostbyname in nsl
-- Looking for gethostbyname in nsl - found
-- Looking for connect in socket
-- Looking for connect in socket - not found
-- Looking for posix_fadvise
-- Looking for posix_fadvise - found
-- Found ACL support: /usr/lib64/libacl.so;/usr/lib64/libattr.so
-- Looking for strtoll
-- Looking for strtoll - not found
-- Found GSSAPI: -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
-- Looking for include file sys/time.h
-- Looking for include file sys/time.h - found
CMake Warning at CMakeLists.txt:208 (find_package):
  Could not find a package configuration file provided by "Phonon4Qt5"
  (requested version 4.6.60) with any of the following names:

Phonon4Qt5Config.cmake
phonon4qt5-config.cmake

  Add the installation prefix of "Phonon4Qt5" to CMAKE_PREFIX_PATH or set
  "Phonon4Qt5_DIR" to a directory containing one of the above files.  If
  "Phonon4Qt5" provides a separate development package or SDK, be sure it has
  been installed.


CMake Warning at interfaces/CMakeLists.txt:5 (find_package):
  Could not find a package configuration file provided by "Phonon4Qt5"
  (requested version 4.6.60) with any of the following names:

Phonon4Qt5Config.cmake
phonon4qt5-config.cmake

  Add the installation prefix of "Phonon4Qt5" to CMAKE_PREFIX_PATH or set
  "Phonon4Qt5_DIR" to a directory containing one of the above files.  If
  "Phonon4Qt5" provides a separate development package or SDK, be sure it has
  been installed.


-- Looking for __progname
-- Looking for __progname - found
-- Looking for __progname_full
-- Looking fo

Review Request 112913: Move KModifierKeyInfo from GuiAddons to KWindowSystem

[Martin Gräßlin]

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

Review request for KDE Frameworks.


Description
---

As discussed in https://git.reviewboard.kde.org/r/112443/

It's quite windowing system specific and only implemented for X11 so
it makes more sense in the framework which is about the windowing
system specific code.


Diffs
-

  tier1/kguiaddons/src/lib/CMakeLists.txt dc6aafa 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.h a5b1785 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.cpp 7068d6f 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider.cpp 696c577 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_dummy.cpp 7913d29 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_p.h ee8e82e 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_x11.cpp 2f28d41 
  tier1/kguiaddons/tests/CMakeLists.txt 4d91ed8 
  tier1/kguiaddons/tests/kmodifierkeyinfotest.cpp 39984a0 
  tier1/kwindowsystem/src/CMakeLists.txt 31fb53e 
  tier1/kwindowsystem/src/kmodifierkeyinfo.h PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfo.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_dummy.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_p.h PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_x11.cpp PRE-CREATION 
  tier1/kwindowsystem/tests/CMakeLists.txt 5cf5868 
  tier1/kwindowsystem/tests/kmodifierkeyinfotest.cpp PRE-CREATION 

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


Testing
---

compiled


Thanks,

Martin Gräßlin

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

Re: Review Request 112909: Remove KDE print stuff that has been ported to Qt5

[Martin Klapetek]

> On Sept. 24, 2013, 7:10 a.m., Kevin Ottens wrote:
> > I'm torn on that one... If we're sure the remaining features aren't useful, 
> > I would propose to just move all the printing stuff from KDE4Attic to 
> > KDE4Support. If we're not sure, then we should move the printing stuff from 
> > KDE4Attic to the upcoming KPrintUtils (patch pending, it's going to contain 
> > a single class so far).
> > 
> > If we go for the KPrintUtils route I think it's a good goal to make it 
> > useless over time by keeping to get features merged upstream in Qt. So it's 
> > really a question of how fast we feel like deprecating those features.

Either way, these need to be removed as otherwise the print dialog will now 
have duplicated controls.

So I propose to clean it up first (merge this) then decide what to do next and 
do it. KPrintUtils seems perfect for this.


- Martin


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


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: kde-workspace master becomes Qt5-based

[Martin Gräßlin]

On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> Hi all,
> 
> We're planning to merge the frameworks-scratch branch of kde-workspace into
> master next Monday. That means if you're building your Plasma yourself from
> Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> KDE/4.11 branch. The build will fail otherwise, so you will notice.
> 
> This was a public service announcement. (And you can ask questions here.)
Follow-up: frameworks-scratch got just merged into master.

Please do not push into the frameworks-scratch branch any more!

Cheers
Martin

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 112909: Remove KDE print stuff that has been ported to Qt5

[Kevin Ottens]

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

Ship it!


Ship It!

- Kevin Ottens


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Jenkins build is back to stable : kdelibs_frameworks_qt5 #1248

[KDE CI System]

See 

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

Jenkins build became unstable: kdelibs_frameworks_qt5 #1249

[KDE CI System]

See 

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

Re: QTimeZone merged for 5.2

[Kevin Ottens]

On Monday 23 September 2013 09:33:54 Kevin Ottens wrote:
> On Monday 23 September 2013 09:06:33 John Layt wrote:
> > Hi,
> > 
> > I am extremely relived to announce that QTimeZone finally got merged
> > late late last night, thanks to the efforts of Thiago in fighting the
> > CI system :-)  Combined with other changes in QDateTime, this should
> > mean we're free of KDateTime and KTimeZone, albeit with a few caveats.
> > 
> >  I'll be doing a lightning talk at Qt Dev Days on the topic, so I'll
> > 
> > be documenting all the gotcha's people will need to look out for soon.
> > 
> > Thanks also to the work from Martin and Rohan, all the necessary CUPS
> > features have been merged into Qt 5.2, and a huge thanks to Alex for
> > taking on QCollator and getting it in.  I owe you all a beer or three
> > next time I see you :-)
> > 
> > I was less successful on the QLocale front, unfortunately there was
> > too much resistance from Windows devs to using ICU everywhere, so that
> > plan has been shelved and we've moved on to Plan C for 5.3.  I'll be
> > working through what that means for us soon, but I don't see any
> > immediate problems for us in still switching to QLocale.
> 
> Yay!
> 
> OK, let's attempt to move KLocale, KDateTime and friends to kde4support now.
> With some luck we'll be able to completely get rid of KDE4Attic before
> release.

Hmm, looking at that closer... indeed it looks like we can get rid of 
K*TimeZone in favor of QTimeZone. But what would you advise for porting away 
from KCalendarSystem and KLocalizedDate?

Alternatives for those would be needed to move the date/time widgets currently 
stuck in KDE4Attic to a more proper framework.

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

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



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

Jenkins build is back to stable : kdelibs_frameworks_qt5 #1250

[KDE CI System]

See 

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

Re: Review Request 112900: Prepare KDNSSD for moving

[Aleix Pol Gonzalez]

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

(Updated Sept. 24, 2013, 11:14 a.m.)


Review request for KDE Frameworks.


Changes
---

Remove the build fix, didn't belong to the patch.


Description
---

Prepares the module to be moved to its own tier.

There's a rather uncommon case with this module because there's a dependency 
against KConfig, but it only applies to when it's compiled with the mdnsd 
backend (only when there's no Avahi but mDns instead). I guess this makes it 
tier 2, but I'm not all that sure about that.


Diffs (updated)
-

  dnssd/CMakeLists.txt a2dd8e6 
  dnssd/KDNSSDConfig.cmake.in PRE-CREATION 
  dnssd/src/CMakeLists.txt 47587af 
  dnssd/src/avahi-publicservice.cpp 119c5a8 
  dnssd/src/mdnsd-publicservice.cpp 2a775fa 
  dnssd/src/servicemodel.cpp 348db57 

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


Testing
---

Builds, there are no tests.


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 112902: Start cleanup for kdewebkit

[Aleix Pol Gonzalez]

> On Sept. 24, 2013, 6:58 a.m., Kevin Ottens wrote:
> > staging/kio/src/widgets/renamedialog.h, line 25
> > 
> >
> > How is it related to the rest of the patch?

KSqueezedTextLabel is in KWidgetsAddons which is not a public dependency of 
KIOWidgets, so it was not being found when building.

It's either that or make KWidgetsAddons public.


- Aleix


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


On Sept. 23, 2013, 5:27 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112902/
> ---
> 
> (Updated Sept. 23, 2013, 5:27 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Start to figure out the port of the cmake to KF5 standards.
> 
> 
> Diffs
> -
> 
>   kdewebkit/CMakeLists.txt cdc5835 
>   kdewebkit/kwebpage.cpp 73dd5a7 
>   staging/kde4support/CMakeLists.txt 24ee457 
>   staging/kio/src/widgets/renamedialog.h 9a14451 
> 
> Diff: http://git.reviewboard.kde.org/r/112902/diff/
> 
> 
> Testing
> ---
> 
> Builds, there are no tests.
> 
> 
> 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 112902: Start cleanup for kdewebkit

[Aleix Pol Gonzalez]

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

(Updated Sept. 24, 2013, 11:19 a.m.)


Review request for KDE Frameworks.


Changes
---

remove build fix, that is not part of the patch.


Description
---

Start to figure out the port of the cmake to KF5 standards.


Diffs (updated)
-

  staging/kio/src/widgets/renamedialog.h 9a14451 
  kdewebkit/kwebpage.cpp 73dd5a7 
  kdewebkit/CMakeLists.txt cdc5835 

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


Testing
---

Builds, there are no tests.


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 112901: Remove weird cmake indirections

[Aleix Pol Gonzalez]

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

(Updated Sept. 24, 2013, 11:36 a.m.)


Review request for Build System and KDE Frameworks.


Changes
---

Don't specifically say we want SHARED libraries, let cmake use its defaults 
wisely.


Description
---

There were some un-reviewed cmake files where libraries would be defined with a 
${LIBRARY_TYPE}. It seems to be something coming from the KDE4 times that 
didn't follow through.

I propose to remove all the uses for the moment, it's not ever being set anyway.


Diffs (updated)
-

  kdesu/CMakeLists.txt e526643 
  interfaces/kmediaplayer/CMakeLists.txt 3d1797d 
  interfaces/kimproxy/library/CMakeLists.txt 36e55ef 
  kdewebkit/CMakeLists.txt cdc5835 
  kfile/CMakeLists.txt e05137d 
  khtml/CMakeLists.txt 4e1bb80 
  kio/CMakeLists.txt 25dc6d9 
  kio/misc/kntlm/CMakeLists.txt fe70a8d 
  kjsembed/kjsembed/CMakeLists.txt 8ed55c1 
  knewstuff/src/CMakeLists.txt c313981 
  knotify/config/CMakeLists.txt 69e1c11 
  kparts/CMakeLists.txt 6ab9391 
  kpty/CMakeLists.txt 9a79827 
  kross/core/CMakeLists.txt 52cd3d4 
  kross/qts/CMakeLists.txt 1a30bd1 
  kross/ui/CMakeLists.txt 9e7806d 
  kutils/CMakeLists.txt 0cb281d 
  staging/kde4support/CMakeLists.txt 24ee457 
  staging/kemoticons/src/core/CMakeLists.txt f7fb463 
  staging/ktextwidgets/src/CMakeLists.txt 4787c10 

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


Testing
---

Everything still builds


Thanks,

Aleix Pol Gonzalez

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

Re: Making KDocTools independent of KArchive

[Albert Astals Cid]

El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure:
> On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote:
> > Maybe we can use a third-party docbook-to-manpage conversion tool. On
> > Linux
> > it would be easy to install, and on Windows it wouldn't be needed ("what's
> > a manpage?"). And still leave it optional everywhere...
> 
> Thats a very good question. Maybe in that case kdoctools is indeed overkill.
> Someone would have to investigate if something else could be used though.

That's really weird, we have a solution that works, and you want to use 
something else?

What does that gives us?

That stuff in kde now depends in two docbook-to-manpage conversion tools 
instead of one?

Are you sure that's an improvement?

Albert

> 
> Cheers.

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

Re: kde-workspace master becomes Qt5-based

[Albert Astals Cid]

El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va 
escriure:
> On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> > Hi all,
> > 
> > We're planning to merge the frameworks-scratch branch of kde-workspace
> > into
> > master next Monday. That means if you're building your Plasma yourself
> > from
> > Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> > KDE/4.11 branch. The build will fail otherwise, so you will notice.
> > 
> > This was a public service announcement. (And you can ask questions here.)
> 
> Follow-up: frameworks-scratch got just merged into master.
> 
> Please do not push into the frameworks-scratch branch any more!

Can this be blocked more efficiently in the git repo instead of relying on 
people to do the right thing?

Cheers,
  Albert

> 
> Cheers
> Martin

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

Re: Making KDocTools independent of KArchive

[Kevin Ottens]

On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote:
> El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va 
escriure:
> > On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote:
> > > Maybe we can use a third-party docbook-to-manpage conversion tool. On
> > > Linux
> > > it would be easy to install, and on Windows it wouldn't be needed
> > > ("what's
> > > a manpage?"). And still leave it optional everywhere...
> > 
> > Thats a very good question. Maybe in that case kdoctools is indeed
> > overkill. Someone would have to investigate if something else could be
> > used though.
> That's really weird, we have a solution that works, and you want to use
> something else?
> 
> What does that gives us?
> 
> That stuff in kde now depends in two docbook-to-manpage conversion tools
> instead of one?
> 
> Are you sure that's an improvement?

Well, as highlighted we have a dependency issue there, so it's either:
 1) no docbook in tier 1 and tier 2 frameworks;
 2) we use a different docbook to manpage tool for tier 1 and tier 2 
frameworks.

Pick your poison. But we can't keep said dependency issue.

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

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



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

Review Request 112915: Fix kcrash standalone build

[Aurélien Gâteau]

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

Review request for KDE Frameworks.


Description
---

- find kcrash deps in kcrash/CMakeLists.txt
- fix kcrash dir in superbuild/CMakeLists.txt


Diffs
-

  superbuild/CMakeLists.txt 2abe36a 
  tier2/kcrash/CMakeLists.txt 62ae2ba 

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


Testing
---

Still builds


Thanks,

Aurélien Gâteau

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

Re: Review Request 112882: Split remaining KUtils into kcmutils and kprintutils

[Commit Hook]

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


This review has been submitted with commit 
c90e676fe270bb63d6d60f907ac177cb253a460d by David Edmundson to branch 
frameworks.

- Commit Hook


On Sept. 22, 2013, 12:32 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112882/
> ---
> 
> (Updated Sept. 22, 2013, 12:32 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Split remaining KUtils into kcmutils and kprintutils and move them to staging
> 
> --
> 
> There's still a few things that need doing before it's ready for moving into 
> a real tier. Those will come in a different commit/review.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4dff35d 
>   kutils/CMakeLists.txt 0cb281d 
>   kutils/Mainpage.dox  
>   kutils/TODO  
>   kutils/dummy.cpp 668f87b 
>   kutils/kcmodulecontainer.h  
>   kutils/kcmodulecontainer.cpp  
>   kutils/kcmoduleinfo.h  
>   kutils/kcmoduleinfo.cpp  
>   kutils/kcmoduleloader.h  
>   kutils/kcmoduleloader.cpp  
>   kutils/kcmoduleproxy.h  
>   kutils/kcmoduleproxy.cpp  
>   kutils/kcmoduleproxy_p.h  
>   kutils/kcmultidialog.h  
>   kutils/kcmultidialog.cpp  
>   kutils/kcmultidialog_p.h  
>   kutils/kdeglobals.kcfg  
>   kutils/kdeglobals.kcfgc  
>   kutils/kpluginselector.h  
>   kutils/kpluginselector.cpp  
>   kutils/kpluginselector_p.h  
>   kutils/kprintpreview.h  
>   kutils/kprintpreview.cpp  
>   kutils/ksettings/README.dox  
>   kutils/ksettings/TODO  
>   kutils/ksettings/componentsdialog.cpp  
>   kutils/ksettings/componentsdialog_p.h  
>   kutils/ksettings/dialog.h  
>   kutils/ksettings/dialog.cpp  
>   kutils/ksettings/dialog_p.h  
>   kutils/ksettings/dispatcher.h  
>   kutils/ksettings/dispatcher.cpp  
>   kutils/ksettings/dispatcher_p.h  
>   kutils/ksettings/pluginpage.h  
>   kutils/ksettings/pluginpage.cpp  
>   kutils/ksettingswidgetadaptor.h  
>   kutils/ksettingswidgetadaptor.cpp  
>   staging/CMakeLists.txt 5c52cbe 
>   staging/kcmutils/CMakeLists.txt PRE-CREATION 
>   staging/kcmutils/KCMUtilsConfig.cmake.in PRE-CREATION 
>   staging/kcmutils/src/CMakeLists.txt PRE-CREATION 
>   staging/kprintutils/CMakeLists.txt PRE-CREATION 
>   staging/kprintutils/KPrintUtilsConfig.cmake.in PRE-CREATION 
>   staging/kprintutils/src/CMakeLists.txt PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112882/diff/
> 
> 
> Testing
> ---
> 
> build + compiles
> 
> 
> 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 112882: Split remaining KUtils into kcmutils and kprintutils

[David Edmundson]

> On Sept. 23, 2013, 11:18 a.m., Kevin Ottens wrote:
> > staging/kprintutils/KPrintUtilsConfig.cmake.in, line 3
> > 
> >
> > I surely has other dependencies.
> 
> Aleix Pol Gonzalez wrote:
> Most things in staging have faulty *Config.cmake.in files, I'd say we can 
> iterate over those before moving to its own tier.
> 
> Kevin Ottens wrote:
> Sure, I probably won't catch them again though. :-)

Fixed all. I would probably have wasted a while debugging them later.

Thanks.


- David


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


On Sept. 24, 2013, 12:22 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112882/
> ---
> 
> (Updated Sept. 24, 2013, 12:22 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Split remaining KUtils into kcmutils and kprintutils and move them to staging
> 
> --
> 
> There's still a few things that need doing before it's ready for moving into 
> a real tier. Those will come in a different commit/review.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4dff35d 
>   kutils/CMakeLists.txt 0cb281d 
>   kutils/Mainpage.dox  
>   kutils/TODO  
>   kutils/dummy.cpp 668f87b 
>   kutils/kcmodulecontainer.h  
>   kutils/kcmodulecontainer.cpp  
>   kutils/kcmoduleinfo.h  
>   kutils/kcmoduleinfo.cpp  
>   kutils/kcmoduleloader.h  
>   kutils/kcmoduleloader.cpp  
>   kutils/kcmoduleproxy.h  
>   kutils/kcmoduleproxy.cpp  
>   kutils/kcmoduleproxy_p.h  
>   kutils/kcmultidialog.h  
>   kutils/kcmultidialog.cpp  
>   kutils/kcmultidialog_p.h  
>   kutils/kdeglobals.kcfg  
>   kutils/kdeglobals.kcfgc  
>   kutils/kpluginselector.h  
>   kutils/kpluginselector.cpp  
>   kutils/kpluginselector_p.h  
>   kutils/kprintpreview.h  
>   kutils/kprintpreview.cpp  
>   kutils/ksettings/README.dox  
>   kutils/ksettings/TODO  
>   kutils/ksettings/componentsdialog.cpp  
>   kutils/ksettings/componentsdialog_p.h  
>   kutils/ksettings/dialog.h  
>   kutils/ksettings/dialog.cpp  
>   kutils/ksettings/dialog_p.h  
>   kutils/ksettings/dispatcher.h  
>   kutils/ksettings/dispatcher.cpp  
>   kutils/ksettings/dispatcher_p.h  
>   kutils/ksettings/pluginpage.h  
>   kutils/ksettings/pluginpage.cpp  
>   kutils/ksettingswidgetadaptor.h  
>   kutils/ksettingswidgetadaptor.cpp  
>   staging/CMakeLists.txt 5c52cbe 
>   staging/kcmutils/CMakeLists.txt PRE-CREATION 
>   staging/kcmutils/KCMUtilsConfig.cmake.in PRE-CREATION 
>   staging/kcmutils/src/CMakeLists.txt PRE-CREATION 
>   staging/kprintutils/CMakeLists.txt PRE-CREATION 
>   staging/kprintutils/KPrintUtilsConfig.cmake.in PRE-CREATION 
>   staging/kprintutils/src/CMakeLists.txt PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112882/diff/
> 
> 
> Testing
> ---
> 
> build + compiles
> 
> 
> 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 112882: Split remaining KUtils into kcmutils and kprintutils

[Commit Hook]

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

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


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Description
---

Split remaining KUtils into kcmutils and kprintutils and move them to staging

--

There's still a few things that need doing before it's ready for moving into a 
real tier. Those will come in a different commit/review.


Diffs
-

  CMakeLists.txt 4dff35d 
  kutils/CMakeLists.txt 0cb281d 
  kutils/Mainpage.dox  
  kutils/TODO  
  kutils/dummy.cpp 668f87b 
  kutils/kcmodulecontainer.h  
  kutils/kcmodulecontainer.cpp  
  kutils/kcmoduleinfo.h  
  kutils/kcmoduleinfo.cpp  
  kutils/kcmoduleloader.h  
  kutils/kcmoduleloader.cpp  
  kutils/kcmoduleproxy.h  
  kutils/kcmoduleproxy.cpp  
  kutils/kcmoduleproxy_p.h  
  kutils/kcmultidialog.h  
  kutils/kcmultidialog.cpp  
  kutils/kcmultidialog_p.h  
  kutils/kdeglobals.kcfg  
  kutils/kdeglobals.kcfgc  
  kutils/kpluginselector.h  
  kutils/kpluginselector.cpp  
  kutils/kpluginselector_p.h  
  kutils/kprintpreview.h  
  kutils/kprintpreview.cpp  
  kutils/ksettings/README.dox  
  kutils/ksettings/TODO  
  kutils/ksettings/componentsdialog.cpp  
  kutils/ksettings/componentsdialog_p.h  
  kutils/ksettings/dialog.h  
  kutils/ksettings/dialog.cpp  
  kutils/ksettings/dialog_p.h  
  kutils/ksettings/dispatcher.h  
  kutils/ksettings/dispatcher.cpp  
  kutils/ksettings/dispatcher_p.h  
  kutils/ksettings/pluginpage.h  
  kutils/ksettings/pluginpage.cpp  
  kutils/ksettingswidgetadaptor.h  
  kutils/ksettingswidgetadaptor.cpp  
  staging/CMakeLists.txt 5c52cbe 
  staging/kcmutils/CMakeLists.txt PRE-CREATION 
  staging/kcmutils/KCMUtilsConfig.cmake.in PRE-CREATION 
  staging/kcmutils/src/CMakeLists.txt PRE-CREATION 
  staging/kprintutils/CMakeLists.txt PRE-CREATION 
  staging/kprintutils/KPrintUtilsConfig.cmake.in PRE-CREATION 
  staging/kprintutils/src/CMakeLists.txt PRE-CREATION 

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


Testing
---

build + compiles


Thanks,

David Edmundson

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

Re: Re: kde-workspace master becomes Qt5-based

[Martin Gräßlin]

On Tuesday 24 September 2013 13:51:57 Albert Astals Cid wrote:
> El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va
> 
> escriure:
> > On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> > > Hi all,
> > > 
> > > We're planning to merge the frameworks-scratch branch of kde-workspace
> > > into
> > > master next Monday. That means if you're building your Plasma yourself
> > > from
> > > Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> > > KDE/4.11 branch. The build will fail otherwise, so you will notice.
> > > 
> > > This was a public service announcement. (And you can ask questions
> > > here.)
> > 
> > Follow-up: frameworks-scratch got just merged into master.
> > 
> > Please do not push into the frameworks-scratch branch any more!
> 
> Can this be blocked more efficiently in the git repo instead of relying on
> people to do the right thing?
Ben already did that. Which means kudos to our awesome sysadmins!

Cheers
Martin

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: Making KDocTools independent of KArchive

[Aleix Pol]

On Tue, Sep 24, 2013 at 2:09 PM, Kevin Ottens  wrote:

> On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote:
> > El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va
> escriure:
> > > On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote:
> > > > Maybe we can use a third-party docbook-to-manpage conversion tool. On
> > > > Linux
> > > > it would be easy to install, and on Windows it wouldn't be needed
> > > > ("what's
> > > > a manpage?"). And still leave it optional everywhere...
> > >
> > > Thats a very good question. Maybe in that case kdoctools is indeed
> > > overkill. Someone would have to investigate if something else could be
> > > used though.
> > That's really weird, we have a solution that works, and you want to use
> > something else?
> >
> > What does that gives us?
> >
> > That stuff in kde now depends in two docbook-to-manpage conversion tools
> > instead of one?
> >
> > Are you sure that's an improvement?
>
> Well, as highlighted we have a dependency issue there, so it's either:
>  1) no docbook in tier 1 and tier 2 frameworks;
>  2) we use a different docbook to manpage tool for tier 1 and tier 2
> frameworks.
>
> Pick your poison. But we can't keep said dependency issue.
>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> Sponsored by KDAB to work on KDE Frameworks
> KDAB - proud supporter of KDE, http://www.kdab.com
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
Maybe we can bundle the generated documentation?
I think we're making it more of a problem than actually is... Maybe the
problem here is considering kdoctools as a framework instead of a tool set.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 112311: Port kmimetypechooser.cpp from Krun to QProcess

[Commit Hook]

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


This review has been submitted with commit 
2e43321d82a578176dac78d3c745707cbc3f2849 by Vishesh Handa to branch frameworks.

- Commit Hook


On Sept. 2, 2013, 3:13 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112311/
> ---
> 
> (Updated Sept. 2, 2013, 3:13 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Title says it all
> 
> 
> Diffs
> -
> 
>   kio/kio/kmimetypechooser.cpp 616b033 
> 
> Diff: http://git.reviewboard.kde.org/r/112311/diff/
> 
> 
> Testing
> ---
> 
> Tested by running kmimetypechoosertest, the behavior is same with or without 
> this patch.
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

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

Re: Review Request 112311: Port kmimetypechooser.cpp from Krun to QProcess

[Commit Hook]

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

(Updated Sept. 24, 2013, 1:10 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Description
---

Title says it all


Diffs
-

  kio/kio/kmimetypechooser.cpp 616b033 

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


Testing
---

Tested by running kmimetypechoosertest, the behavior is same with or without 
this patch.


Thanks,

Vishesh Handa

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

Re: Review Request 112830: Start splitting KParts

[Commit Hook]

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

(Updated Sept. 24, 2013, 1:23 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Description
---

Started reorganizing KParts, everything stopped compiling, that fixes it too.

Make string to QStrign casts explicit.
KParts was exporting the "kio" linking, don't do it anymore.


Diffs
-

  interfaces/kmediaplayer/CMakeLists.txt 3d1797d 
  interfaces/terminal/example/CMakeLists.txt 57201fa 
  kdewebkit/CMakeLists.txt cdc5835 
  khtml/CMakeLists.txt 4e1bb80 
  khtml/html/ksslkeygen.cpp a3118da 
  khtml/html/ksslkeygen_p.h 95c1a71 
  khtml/java/CMakeLists.txt ef1675c 
  khtml/java/tests/CMakeLists.txt 59bef3a 
  khtml/kmultipart/CMakeLists.txt 6a72fac 
  khtml/tests/CMakeLists.txt 99b3bdd 
  kio/CMakeLists.txt 25dc6d9 
  kparts/CMakeLists.txt 6ab9391 
  kparts/autotests/CMakeLists.txt PRE-CREATION 
  kparts/autotests/openorsavequestion_unittest.cpp PRE-CREATION 
  kparts/autotests/parttest.h PRE-CREATION 
  kparts/autotests/parttest.cpp PRE-CREATION 
  kparts/browserrun.h e758241 
  kparts/tests/CMakeLists.txt 83a97f1 
  kparts/tests/normalktm.cpp dcc3a5e 
  kparts/tests/notepad.cpp b7c3778 
  kparts/tests/openorsavequestion.cpp c080cfc 
  kparts/tests/openorsavequestion_unittest.cpp 72285b1 
  kparts/tests/parts.cpp ee198e3 
  kparts/tests/parttest.h 19f7651 
  kparts/tests/parttest.cpp 828666f 
  kparts/tests/partviewer.cpp eeeb63a 
  kparts/tests/plugin_spellcheck.cpp 073144b 
  kparts/tests/testmainwindow.cpp fd77af0 
  kross/modules/CMakeLists.txt b18c98b 
  kross/ui/CMakeLists.txt 9e7806d 
  kutils/CMakeLists.txt 0cb281d 
  staging/xmlgui/tests/krichtexteditor/CMakeLists.txt 372856b 

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


Testing
---

Builds


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 112830: Start splitting KParts

[Commit Hook]

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


This review has been submitted with commit 
270a19b6bf9157361caa757a2fadbf44049b24cf by Aleix Pol to branch frameworks.

- Commit Hook


On Sept. 23, 2013, noon, Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112830/
> ---
> 
> (Updated Sept. 23, 2013, noon)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Started reorganizing KParts, everything stopped compiling, that fixes it too.
> 
> Make string to QStrign casts explicit.
> KParts was exporting the "kio" linking, don't do it anymore.
> 
> 
> Diffs
> -
> 
>   interfaces/kmediaplayer/CMakeLists.txt 3d1797d 
>   interfaces/terminal/example/CMakeLists.txt 57201fa 
>   kdewebkit/CMakeLists.txt cdc5835 
>   khtml/CMakeLists.txt 4e1bb80 
>   khtml/html/ksslkeygen.cpp a3118da 
>   khtml/html/ksslkeygen_p.h 95c1a71 
>   khtml/java/CMakeLists.txt ef1675c 
>   khtml/java/tests/CMakeLists.txt 59bef3a 
>   khtml/kmultipart/CMakeLists.txt 6a72fac 
>   khtml/tests/CMakeLists.txt 99b3bdd 
>   kio/CMakeLists.txt 25dc6d9 
>   kparts/CMakeLists.txt 6ab9391 
>   kparts/autotests/CMakeLists.txt PRE-CREATION 
>   kparts/autotests/openorsavequestion_unittest.cpp PRE-CREATION 
>   kparts/autotests/parttest.h PRE-CREATION 
>   kparts/autotests/parttest.cpp PRE-CREATION 
>   kparts/browserrun.h e758241 
>   kparts/tests/CMakeLists.txt 83a97f1 
>   kparts/tests/normalktm.cpp dcc3a5e 
>   kparts/tests/notepad.cpp b7c3778 
>   kparts/tests/openorsavequestion.cpp c080cfc 
>   kparts/tests/openorsavequestion_unittest.cpp 72285b1 
>   kparts/tests/parts.cpp ee198e3 
>   kparts/tests/parttest.h 19f7651 
>   kparts/tests/parttest.cpp 828666f 
>   kparts/tests/partviewer.cpp eeeb63a 
>   kparts/tests/plugin_spellcheck.cpp 073144b 
>   kparts/tests/testmainwindow.cpp fd77af0 
>   kross/modules/CMakeLists.txt b18c98b 
>   kross/ui/CMakeLists.txt 9e7806d 
>   kutils/CMakeLists.txt 0cb281d 
>   staging/xmlgui/tests/krichtexteditor/CMakeLists.txt 372856b 
> 
> Diff: http://git.reviewboard.kde.org/r/112830/diff/
> 
> 
> Testing
> ---
> 
> Builds
> 
> 
> 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 112909: Remove KDE print stuff that has been ported to Qt5

[John Layt]

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

Ship it!


Agree to merge this as is, it removes the stuff that would be duplicated in the 
Qt dialog.  As for longer-term, I don't see any of those features being much 
used or of much use at all.  If I'm wrong and people start complaining and can 
make a reasonable case, then I'll accept them being added into the Qt dialog.  
If any feature will be missed, it would be the Advanced option of directly 
entering CUPS options.  I suspect there are some power users out there using 
that to get around some of Qt's short-comings, like advanced page ranges 
"3,7-9,15".  However the usability is terrible and just shouldn't be done that 
way.  If people make a case for it, then we can look at a better ui for it in 
Qt, e.g. one that has them choosing from a combo of valid values.  That leaves 
the convenience api for server-side/client-side page selection, which for a 
one-line code saving is really not worth it.  The only other reason I can think 
of for keeping the api is if we ever want to re-add a univ
 ersal KDE tab to the dialog, for example for Color Management.  I had a 
cunning plan for that about a year ago, I need to go dig it up and see what 
actually needs doing and if I can get away with putting it into Qt instead.  If 
we don't need it for that, then I say get rid of it entirely: we don't know 
what any future needs might be, so we have no guarantee that the current api 
will work for that, so lets not lock outselves into something until we actually 
need to.

Oh, and I need to look at the rationale behind KPrintPreview to see if we 
really need it still.

- John Layt


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 112915: Fix kcrash standalone build

[David Edmundson]

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



superbuild/CMakeLists.txt


why have you removed kconfigwidgets?


- David Edmundson


On Sept. 24, 2013, 12:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112915/
> ---
> 
> (Updated Sept. 24, 2013, 12:19 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> - find kcrash deps in kcrash/CMakeLists.txt
> - fix kcrash dir in superbuild/CMakeLists.txt
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 2abe36a 
>   tier2/kcrash/CMakeLists.txt 62ae2ba 
> 
> Diff: http://git.reviewboard.kde.org/r/112915/diff/
> 
> 
> Testing
> ---
> 
> Still builds
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Review Request 112901: Remove weird cmake indirections

[Aleix Pol Gonzalez]

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

(Updated Sept. 24, 2013, 1:32 p.m.)


Review request for Build System and KDE Frameworks.


Changes
---

removed something that didn't belong to the patch


Description
---

There were some un-reviewed cmake files where libraries would be defined with a 
${LIBRARY_TYPE}. It seems to be something coming from the KDE4 times that 
didn't follow through.

I propose to remove all the uses for the moment, it's not ever being set anyway.


Diffs (updated)
-

  interfaces/kimproxy/library/CMakeLists.txt 36e55ef 
  interfaces/kmediaplayer/CMakeLists.txt 3d1797d 
  kdesu/CMakeLists.txt e526643 
  kdewebkit/CMakeLists.txt cdc5835 
  kfile/CMakeLists.txt e05137d 
  khtml/CMakeLists.txt 4e1bb80 
  kio/CMakeLists.txt 25dc6d9 
  kio/misc/kntlm/CMakeLists.txt fe70a8d 
  kjsembed/kjsembed/CMakeLists.txt 8ed55c1 
  knewstuff/src/CMakeLists.txt c313981 
  knotify/config/CMakeLists.txt 69e1c11 
  kparts/CMakeLists.txt 6ab9391 
  kpty/CMakeLists.txt 9a79827 
  kross/core/CMakeLists.txt 52cd3d4 
  kross/qts/CMakeLists.txt 1a30bd1 
  kross/ui/CMakeLists.txt 9e7806d 
  kutils/CMakeLists.txt 0cb281d 
  staging/kemoticons/src/core/CMakeLists.txt f7fb463 
  staging/ktextwidgets/src/CMakeLists.txt 4787c10 

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


Testing
---

Everything still builds


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 112829: Move XMLGUI to Tier3

[David Edmundson]

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


There's a KDE5 TODO in kmainwindow.h to remove the window flags from the 
constructor.


- David Edmundson


On Sept. 19, 2013, 4:44 p.m., Àlex Fiestas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112829/
> ---
> 
> (Updated Sept. 19, 2013, 4:44 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Move xmlgui to tier3, done all the checks.
> 
> 
> Diffs
> -
> 
>   staging/CMakeLists.txt 2a31994 
>   staging/xmlgui/CMakeLists.txt  
>   staging/xmlgui/TODO.xmlgui  
>   staging/xmlgui/XmlGuiConfig.cmake.in  
>   staging/xmlgui/autotests/CMakeLists.txt  
>   staging/xmlgui/autotests/kactioncategorytest.h  
>   staging/xmlgui/autotests/kactioncategorytest.cpp  
>   staging/xmlgui/autotests/kactioncollectiontest.h  
>   staging/xmlgui/autotests/kactioncollectiontest.cpp  
>   staging/xmlgui/autotests/kglobalshortcuttest.h  
>   staging/xmlgui/autotests/kglobalshortcuttest.cpp  
>   staging/xmlgui/autotests/kmainwindow_unittest.h  
>   staging/xmlgui/autotests/kmainwindow_unittest.cpp  
>   staging/xmlgui/autotests/ktoolbar_unittest.cpp  
>   staging/xmlgui/autotests/kxmlgui_unittest.h  
>   staging/xmlgui/autotests/kxmlgui_unittest.cpp  
>   staging/xmlgui/autotests/testguiclient.h  
>   staging/xmlgui/autotests/testxmlguiwindow.h  
>   staging/xmlgui/make_kdepackages.sh  
>   staging/xmlgui/make_kdepackages_updated.py  
>   staging/xmlgui/src/CMakeLists.txt b1d7d17 
>   staging/xmlgui/src/README  
>   staging/xmlgui/src/TODO  
>   staging/xmlgui/src/aboutkde.png  
>   staging/xmlgui/src/config-xmlgui.h.cmake  
>   staging/xmlgui/src/kaboutapplicationconfigattica_p.h.cmake  
>   staging/xmlgui/src/kaboutapplicationdialog.h  
>   staging/xmlgui/src/kaboutapplicationdialog.cpp  
>   staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.h  
>   staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.cpp  
>   staging/xmlgui/src/kaboutapplicationpersonlistview_p.h  
>   staging/xmlgui/src/kaboutapplicationpersonlistview_p.cpp  
>   staging/xmlgui/src/kaboutapplicationpersonmodel_p.h  
>   staging/xmlgui/src/kaboutapplicationpersonmodel_p.cpp  
>   staging/xmlgui/src/kaboutkdedialog_p.h  
>   staging/xmlgui/src/kaboutkdedialog_p.cpp  
>   staging/xmlgui/src/kactioncategory.h  
>   staging/xmlgui/src/kactioncategory.cpp  
>   staging/xmlgui/src/kactioncollection.h  
>   staging/xmlgui/src/kactioncollection.cpp  
>   staging/xmlgui/src/kactionconflictdetector.cpp  
>   staging/xmlgui/src/kbugreport.h  
>   staging/xmlgui/src/kbugreport.cpp  
>   staging/xmlgui/src/kcheckaccelerators.h  
>   staging/xmlgui/src/kcheckaccelerators.cpp  
>   staging/xmlgui/src/kdepackages.h  
>   staging/xmlgui/src/kedittoolbar.h  
>   staging/xmlgui/src/kedittoolbar.cpp  
>   staging/xmlgui/src/kedittoolbar_p.h  
>   staging/xmlgui/src/kglobalaccel.h  
>   staging/xmlgui/src/kglobalaccel.cpp  
>   staging/xmlgui/src/kglobalaccel_p.h  
>   staging/xmlgui/src/kglobalshortcutinfo.h  
>   staging/xmlgui/src/kglobalshortcutinfo.cpp  
>   staging/xmlgui/src/kglobalshortcutinfo_dbus.cpp  
>   staging/xmlgui/src/kglobalshortcutinfo_p.h  
>   staging/xmlgui/src/khelpclient.h  
>   staging/xmlgui/src/khelpclient.cpp  
>   staging/xmlgui/src/khelpmenu.h  
>   staging/xmlgui/src/khelpmenu.cpp  
>   staging/xmlgui/src/kkeysequencewidget.h  
>   staging/xmlgui/src/kkeysequencewidget.cpp  
>   staging/xmlgui/src/kkeysequencewidget_p.h  
>   staging/xmlgui/src/kmainwindow.h  
>   staging/xmlgui/src/kmainwindow.cpp  
>   staging/xmlgui/src/kmainwindow_p.h  
>   staging/xmlgui/src/kmainwindowiface.cpp  
>   staging/xmlgui/src/kmainwindowiface_p.h  
>   staging/xmlgui/src/kmenumenuhandler_p.h  
>   staging/xmlgui/src/kmenumenuhandler_p.cpp  
>   staging/xmlgui/src/kpartgui.dtd  
>   staging/xmlgui/src/kshortcuteditwidget.cpp  
>   staging/xmlgui/src/kshortcutschemeseditor.cpp  
>   staging/xmlgui/src/kshortcutschemeshelper.cpp  
>   staging/xmlgui/src/kshortcutschemeshelper_p.h  
>   staging/xmlgui/src/kshortcutsdialog.h  
>   staging/xmlgui/src/kshortcutsdialog.cpp  
>   staging/xmlgui/src/kshortcutsdialog.ui  
>   staging/xmlgui/src/kshortcutsdialog_p.h  
>   staging/xmlgui/src/kshortcutseditor.h  
>   staging/xmlgui/src/kshortcutseditor.cpp  
>   staging/xmlgui/src/kshortcutseditordelegate.cpp  
>   staging/xmlgui/src/kshortcutseditoritem.cpp  
>   staging/xmlgui/src/kshortcutwidget.h  
>   staging/xmlgui/src/kshortcutwidget.cpp  
>   staging/xmlgui/src/kshortcutwidget.ui  
>   staging/xmlgui/src/kswitchlanguagedialog_p.h  
>   staging/xmlgui/src/kswitchlanguagedialog_p.cpp  
>   staging/xmlgui/src/ktoggleto

Re: Review Request 112915: Fix kcrash standalone build

[Aurélien Gâteau]

> On Sept. 24, 2013, 3:32 p.m., David Edmundson wrote:
> > superbuild/CMakeLists.txt, line 46
> > 
> >
> > why have you removed kconfigwidgets?

Because it does not build with superbuild right now. The original intent of my 
patch was to fix superbuild, but I agree it does not make much sense there. 
Going to bring it back.


- Aurélien


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


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112915/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> - find kcrash deps in kcrash/CMakeLists.txt
> - fix kcrash dir in superbuild/CMakeLists.txt
> 
> 
> Diffs
> -
> 
>   superbuild/CMakeLists.txt 2abe36a 
>   tier2/kcrash/CMakeLists.txt 62ae2ba 
> 
> Diff: http://git.reviewboard.kde.org/r/112915/diff/
> 
> 
> Testing
> ---
> 
> Still builds
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Review Request 112915: Fix kcrash standalone build

[Aurélien Gâteau]

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

(Updated Sept. 24, 2013, 3:39 p.m.)


Review request for KDE Frameworks.


Changes
---

Bring back kconfigwidgets in superbuild/CMakeLists.txt


Description
---

- find kcrash deps in kcrash/CMakeLists.txt
- fix kcrash dir in superbuild/CMakeLists.txt


Diffs (updated)
-

  superbuild/CMakeLists.txt 2abe36a 
  tier2/kcrash/CMakeLists.txt 62ae2ba 

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


Testing
---

Still builds


Thanks,

Aurélien Gâteau

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

Jenkins build became unstable: kdelibs_frameworks_qt5 #1257

[KDE CI System]

See 

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

Re: Review Request 112909: Remove KDE print stuff that has been ported to Qt5

[Martin Klapetek]

> On Sept. 24, 2013, 1:27 p.m., John Layt wrote:
> > Agree to merge this as is, it removes the stuff that would be duplicated in 
> > the Qt dialog.  As for longer-term, I don't see any of those features being 
> > much used or of much use at all.  If I'm wrong and people start complaining 
> > and can make a reasonable case, then I'll accept them being added into the 
> > Qt dialog.  If any feature will be missed, it would be the Advanced option 
> > of directly entering CUPS options.  I suspect there are some power users 
> > out there using that to get around some of Qt's short-comings, like 
> > advanced page ranges "3,7-9,15".  However the usability is terrible and 
> > just shouldn't be done that way.  If people make a case for it, then we can 
> > look at a better ui for it in Qt, e.g. one that has them choosing from a 
> > combo of valid values.  That leaves the convenience api for 
> > server-side/client-side page selection, which for a one-line code saving is 
> > really not worth it.  The only other reason I can think of for keeping the 
> > api is if we ever want to re-add a 
 universal KDE tab to the dialog, for example for Color Management.  I had a 
cunning plan for that about a year ago, I need to go dig it up and see what 
actually needs doing and if I can get away with putting it into Qt instead.  If 
we don't need it for that, then I say get rid of it entirely: we don't know 
what any future needs might be, so we have no guarantee that the current api 
will work for that, so lets not lock outselves into something until we actually 
need to.
> > 
> > Oh, and I need to look at the rationale behind KPrintPreview to see if we 
> > really need it still.

Ok, let me know if I can help with anything around this.


- Martin


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


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Review Request 112918: Add index argument to KWidgetItemDelegate::createItemWidgets

[David Edmundson]

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

Review request for KDE Frameworks.


Description
---

Add index argument to KWidgetItemDelegate::createItemWidgets

This fixes a KDE5 TODO which used to pass an argument as a property


Diffs
-

  tier1/itemviews/tests/kwidgetitemdelegatetest.cpp 
cfca1f9ae3df9bec1e8a570f03b5256cc935e8bb 
  tier1/itemviews/src/kwidgetitemdelegatepool.cpp 
e9bbcad0b030c8d03fadeb6635bfa0d69d996ac9 
  tier1/itemviews/src/kwidgetitemdelegate.h 
b874c10e9a7ab9ee9bf756ae82ce99bd64ec92d1 

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


Testing
---


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 112909: Remove KDE print stuff that has been ported to Qt5

[Commit Hook]

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


This review has been submitted with commit 
ae788001f3f1ed03c9dec68f8b9020ac5f99025a by Martin Klapetek to branch 
frameworks.

- Commit Hook


On Sept. 23, 2013, 6:47 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112909/
> ---
> 
> (Updated Sept. 23, 2013, 6:47 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Description
> ---
> 
> Most of the printing features are now part of Qt 5.2 and basically only 4 
> features are left:
>  - Page Label
>  - Page Border
>  - Mirror Pages
>  - (Advanced) Job Options
>  - Server-side paging
> 
> I've dropped Job Options as it was quite terrible way to edit/pass CUPS 
> options directly. Server-side paging is actually just a convenient feature as 
> with QPrintDialog, apps that can't do paging themselves need 2 lines of code 
> to set the printing dialog up, thanks to KDEPrintDialog only one line is 
> needed. The rest I've put under Page Options tab in the print dialog. To be 
> honest I don't think they are that useful (or used, even) but we have the 
> code and CUPS support already. If these options were to be dropped however, 
> I'd drop the whole KDE Print support then as it would become just a 
> convenient wrapper around QPrintDialog.
> 
> 
> Diffs
> -
> 
>   staging/kde4attic/src/CMakeLists.txt 4acf1b6 
>   staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
>   staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
>   staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
>   staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
>   staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
>   staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 
> 
> Diff: http://git.reviewboard.kde.org/r/112909/diff/
> 
> 
> Testing
> ---
> 
> Tested with Konsole5.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 112909: Remove KDE print stuff that has been ported to Qt5

[Commit Hook]

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

(Updated Sept. 24, 2013, 2:03 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and John Layt.


Description
---

Most of the printing features are now part of Qt 5.2 and basically only 4 
features are left:
 - Page Label
 - Page Border
 - Mirror Pages
 - (Advanced) Job Options
 - Server-side paging

I've dropped Job Options as it was quite terrible way to edit/pass CUPS options 
directly. Server-side paging is actually just a convenient feature as with 
QPrintDialog, apps that can't do paging themselves need 2 lines of code to set 
the printing dialog up, thanks to KDEPrintDialog only one line is needed. The 
rest I've put under Page Options tab in the print dialog. To be honest I don't 
think they are that useful (or used, even) but we have the code and CUPS 
support already. If these options were to be dropped however, I'd drop the 
whole KDE Print support then as it would become just a convenient wrapper 
around QPrintDialog.


Diffs
-

  staging/kde4attic/src/CMakeLists.txt 4acf1b6 
  staging/kde4attic/src/kcupsoptionsjobwidget.ui 182b23e 
  staging/kde4attic/src/kcupsoptionsjobwidget_p.cpp 3c7913d 
  staging/kde4attic/src/kcupsoptionspageswidget.ui a68865d 
  staging/kde4attic/src/kcupsoptionspageswidget_p.h ede67e6 
  staging/kde4attic/src/kcupsoptionspageswidget_p.cpp 79c6834 
  staging/kde4attic/src/kcupsoptionssettingswidget_p.cpp 7b58a37 
  staging/kde4attic/src/kdeprintdialog.cpp 4722f4c 

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


Testing
---

Tested with Konsole5.


Thanks,

Martin Klapetek

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

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Kevin Ottens]

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

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


Review request for KDE Frameworks and kdelibs.


Changes
---

Aimed at the frameworks branch.


Description
---

This is a two-commit patch:

1. Add a KColorUtils::getHcy() method

2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
KColorSpaces::KHCY

This is a required first step to make kconfigwidgets build standalone


Diffs
-

  staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
  tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
  tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 

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


Testing
---

kcolorutilsdemo still works.


Thanks,

Aurélien Gâteau

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

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Sune Vuorela]

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



tier1/kguiaddons/src/lib/colors/kcolorutils.cpp


My initial reaction is that it could return a bool wether or not things 
went okay, given there is a 'path that does nothing' in the code. Besides that, 
everything looks great.


- Sune Vuorela


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Review Request 112918: Add index argument to KWidgetItemDelegate::createItemWidgets

[David Edmundson]

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

(Updated Sept. 24, 2013, 2:25 p.m.)


Review request for KDE Frameworks.


Changes
---

Update porting guide + other code using this.


Description
---

Add index argument to KWidgetItemDelegate::createItemWidgets

This fixes a KDE5 TODO which used to pass an argument as a property


Diffs (updated)
-

  tier1/itemviews/tests/kwidgetitemdelegatetest.cpp 
cfca1f9ae3df9bec1e8a570f03b5256cc935e8bb 
  tier1/itemviews/src/kwidgetitemdelegatepool.cpp 
e9bbcad0b030c8d03fadeb6635bfa0d69d996ac9 
  tier1/itemviews/src/kwidgetitemdelegate.h 
b874c10e9a7ab9ee9bf756ae82ce99bd64ec92d1 

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


Testing
---


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 112816: Do not use internal headers in kcolorutilsdemo

[Kevin Ottens]

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


Probably we'll need an extra patch on top of this one so that KColorSpaces 
become private, no need to export it anymore imo.

- Kevin Ottens


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Aurélien Gâteau]

> On Sept. 24, 2013, 4:23 p.m., Sune Vuorela wrote:
> > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp, line 42
> > 
> >
> > My initial reaction is that it could return a bool wether or not things 
> > went okay, given there is a 'path that does nothing' in the code. Besides 
> > that, everything looks great.

I wrote it this way to be consistent with QColor::get*() methods. I think users 
of such code are going to be used to QColor API, so it makes more sense this 
way, what do you think?


- Aurélien


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


On Sept. 24, 2013, 4:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 4:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Review Request 112918: Add index argument to KWidgetItemDelegate::createItemWidgets

[David Edmundson]

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

(Updated Sept. 24, 2013, 2:33 p.m.)


Review request for KDE Frameworks.


Changes
---

Edit: Stupid post-review.


Description
---

Add index argument to KWidgetItemDelegate::createItemWidgets

This fixes a KDE5 TODO which used to pass an argument as a property


Diffs (updated)
-

  staging/kcmutils/src/kpluginselector.cpp 
77cbfda5987195f15341e41c3280726e5583d87e 
  KDE5PORTING.html 57ecf2e007e270b634cc8d16462b73e96553c92d 
  staging/kcmutils/src/kpluginselector_p.h 
2dffae05dd87cc299ecdb05612f02dd2ad37cd2c 
  staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.h 
0e325915070006d2cfa093719d5c967f3181737d 
  staging/xmlgui/src/kaboutapplicationpersonlistdelegate_p.cpp 
84f9ca548068088c0bc0ff99fa460e5f7fecbccd 
  tier1/itemviews/src/kwidgetitemdelegate.h 
b874c10e9a7ab9ee9bf756ae82ce99bd64ec92d1 
  tier1/itemviews/src/kwidgetitemdelegatepool.cpp 
e9bbcad0b030c8d03fadeb6635bfa0d69d996ac9 
  tier1/itemviews/tests/kwidgetitemdelegatetest.cpp 
cfca1f9ae3df9bec1e8a570f03b5256cc935e8bb 

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


Testing
---


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 112816: Do not use internal headers in kcolorutilsdemo

[Sune Vuorela]

> On Sept. 24, 2013, 2:23 p.m., Sune Vuorela wrote:
> > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp, line 42
> > 
> >
> > My initial reaction is that it could return a bool wether or not things 
> > went okay, given there is a 'path that does nothing' in the code. Besides 
> > that, everything looks great.
> 
> Aurélien Gâteau wrote:
> I wrote it this way to be consistent with QColor::get*() methods. I think 
> users of such code are going to be used to QColor API, so it makes more sense 
> this way, what do you think?

I'm convinced.


- Sune


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


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

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

Re: Templates for frameworks CMake files

[Stephen Kelly]

Aurélien Gâteau wrote:

> Hi,
> 
> I have been playing around with itemviews CMake files and put together
> some templates for the top level CMakeLists.txt and *Config.cmake.in. You
> can find them attached there. Any one against me adding those to the
> repository?
> 
> Aurélien
> CMakeLists.txt
>   cmake_minimum_required(VERSION 2.8.11)

This template will be out of date whenever we require a new cmake.

>  
>  project(FooBar)
>  
>  find_package(ECM 0.0.8 REQUIRED NO_MODULE)

The latest ECM is 0.0.9

>  set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
>  
>  set(REQUIRED_QT_VERSION "5.2.0")

ECM and Qt version bumps are not as much an issue as the cmake one. The ECM 
and Qt version deps are not as likely to change.

>  # Required Qt5 components to build this framework
>  # For example:
>  # find_package(Qt5 ${REQUIRED_QT_VERSION} REQUIRED NO_MODULE COMPONENTS
>  # Widgets)

Simplify by putting NO_MODULE before REQUIRED and removing COMPONENTS:

 find_package(Qt5 ${REQUIRED_QT_VERSION} NO_MODULE REQUIRED Widgets)

>  if(NOT kdelibs_SOURCE_DIR)
>  find_package(KF5 5.0.0 REQUIRED MODULE COMPONENTS CMake Compiler
>  InstallDirs) # Required KF5 frameworks to build this framework

I still think this stuff is odd. We're building KF5, yet we need to find KF5 
to do so.



>   FooBarConfigVersion.cmake.in
>   @PACKAGE_INIT@
>  
>  # Required components to use this framework
>  # For example:
>  # find_dependency(Qt5Widgets @REQUIRED_QT_VERSION@)
>  # find_dependency(KCoreAddons ${PACKAGE_VERSION})

We might want to change this before you template it. Currently,

 find_package(KAnyTier2Framework)

will result in finding its dependency with 

 find_package(KDependentTier1Framework)

ie, the dependency is not found by version unless a version is specified 
when finding KAnyTier2Framework. ie:

 find_package(KAnyTier2Framework 5.3)

will call 

 find_package(KDependentTier1Framework 5.3)

However, it might make sense for even 

 find_package(KAnyTier2Framework)

to require the same or later version as KAnyTier2Framework. 

That would be another change that would affect your template, and which 
would make 

 find_dependency(KCoreAddons ${PACKAGE_VERSION})

'wrong'.

>  
>  set(FooBar_INSTALL_PREFIX "@PACKAGE_CMAKE_INSTALL_PREFIX@")

IMO this should be removed from all config files and not added to new ones:

 http://thread.gmane.org/gmane.comp.kde.devel.frameworks/1194/focus=1318

It is unused and not useful or needed. ie  

 git grep -l PACKAGE_CMAKE_INSTALL_PREFIX | xargs \
   sed -i '/PACKAGE_CMAKE_INSTALL_PREFIX/d'

and remove the CMAKE_INSTALL_PREFIX from the configure_package_config_file 
invocations.

>  set_and_check(FooBar_INCLUDE_DIR "@PACKAGE_INCLUDE_INSTALL_DIR@")
>  set(FooBar_INCLUDE_DIRS ${FooBar_INCLUDE_DIR} )

As the include dirs are encoded into the imported targets, this is 
superfluous. No one needs to use it, and it might contain different/out of 
date information compared to what is encoded in the target.

If it is decided to remove them, then the INCLUDE_INSTALL_DIR should be 
removed from the configure_package_config_file too.

>  include("${CMAKE_CURRENT_LIST_DIR}/FooBarTargets.cmake")

Thanks,

Steve.


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

Re: Frameworks Overview

[Sebastian Kügler]

On Monday, September 23, 2013 15:08:57 Jos Poortvliet wrote:
> On Mon, Sep 23, 2013 at 11:43 AM, Sebastian Kügler  wrote:
> > Technically, this is the current focus. We're splitting kdelibs.
> > 
> > As to communication, it probably needs a bit of boilerplate. (Which the
> > bits I wrote don't contain purposefully.) Otherwise, you're right, we
> > need to work on the presentation side here.
> 
> Anything I can help with? Having some time off so I can do some
> writing or even hacking on a site* where it makes sense
> 
> 
> * I can handle some web stuff provided it ain't too complicated

I think a critical look what exactly needs doing is needed. Probably Cornelius 
has more detailed ideas. Right?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KF5 Update Meeting Minutes 2013-w39

[Kevin Ottens]

Hello everyone,

This is the minutes of the Week 39 KF5 meeting. As usual it has been held on 
#kde-devel at 4pm Paris time.

Were present: afiestas, agateau, apol, d_ed, dfaure, mck182, mgraesslin, 
sebas, shadeslayer, teo, vHanda, wojtask9 and myself.

Announcement:
 * I will be away next week, afiestas will be running the meetings in the 
meantime.

Topics discussed:
 * mck182 has been working on the printing support, all the planned features 
are upstream now, still a few bugs but he's working on them;
 * he also has some KTextWidgets work in the pipe, and would like to bring 
kregexpedit into frameworks;

 * afiestas moved KIO::NetAccess to KDE4Support;
 * he moved KPixmapSequencer moved to KWidgetsAddons;
 * he's also working on moving KIconThemes and XmlGui to their final place;

 * agateau moved ItemViews to tier1;
 * he also fixed kguiaddons standalone build;
 * and he's preparing kconfigwidgets move;
 * he'll also do the prep work to have superbuild supported as a requirement 
to mark a split as done;

 * apol is working on splitting KParts, dnssd and KDEWebKit;
 * he's also cleaning up the cmake files;

 * d_ed has been working on shortcut overrides on the Qt side, it's almost 
done now;
 * he's also split kutils in staging;
 * he's also tackling some of the TODOs in code which got overlooked;

 * dfaure finished porting away from KSSLCertificate and deprecated most of 
kio/kssl;
 * he did some reviews too;
 * the KIO split up still needs to be completed;

 * mgraesslin spent time writing unit tests for NETRootInfo and NETWinInfo;
 * he's also porting to XCB datatypes instead of XLib ones as he goes;
 * he moved KModifierKeyInfo to kwindowsystem;

 * sebas got his KPluginFactory code merged, porting docs are pending;
 * he's working on the plugin installation;
 * and he's trying to find a solution for porting our xembed based systemtray 
items;

 * shadeslayer is still looking into the queued dialog support for 
KJobUiDelegate;

 * teo is finalizing his work on KEncodingFileDialog;
 * after that KFileDialog will get to its final home;
 * he also plans to use the mime filter API of QFileDialog in our calls;

 * vHanda is completing his work to move the kio tests at the right place;
 * he's also cleaning up the nepomuk uses;

 * wojtask9 is working on the script to produce the framework graph;
 * he's also working on KStyle;

 * ervin is reviewing, reviewing and reviewing;
 * he's also trying to plan the splitting of KDE4Attic, there's a chance of 
releasing without it.

If you got questions, feel free to ask.

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

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



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

Re: Making KDocTools independent of KArchive

[Kevin Ottens]

On Tuesday 24 September 2013 15:05:56 Aleix Pol wrote:
> On Tue, Sep 24, 2013 at 2:09 PM, Kevin Ottens  wrote:
> > On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote:
> > > Are you sure that's an improvement?
> > 
> > Well, as highlighted we have a dependency issue there, so it's either:
> >  1) no docbook in tier 1 and tier 2 frameworks;
> >  2) we use a different docbook to manpage tool for tier 1 and tier 2
> > 
> > frameworks.
> > 
> > Pick your poison. But we can't keep said dependency issue.
> > 
> Maybe we can bundle the generated documentation?
> I think we're making it more of a problem than actually is... Maybe the
> problem here is considering kdoctools as a framework instead of a tool set.

That's indeed a solution. We could deal with those man pages in the same way 
than we deal with parsers using flex and yacc... I don't like that much as 
that forces us to commit the resulting file.

But maybe that's the proper way to make everyone happy in that case.

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

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



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

Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros

[Jeremy Whiting]

> On Sept. 23, 2013, 4:37 a.m., Kevin Ottens wrote:
> > I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least 
> > partly.
> 
> Jeremy Whiting wrote:
> well, qt5_wrap_ui wasn't around when this was created (as 
> kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look 
> into making it use qt5_wrap_ui.
> 
> Kevin Ottens wrote:
> Could you please look into it?
> 
> Chusslove Illich wrote:
> This is why I asked Jeremy in the other review, that motivated this one, 
> to
> commit using the plain qt5_wrap_ui, until I get to doing the proper thing
> for k18n_wrap_ui.
> 
> Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus 
> I
> would call it k18n_qt5_wrap_ui. If uic would have some additional command
> line options, k18n_wrap_ui would internally really be a wrapper for
> qt5_wrap_ui; but without these options, it may end up just copying the 
> code
> (little as there is) from qt5_wrap_ui and adding its own stuff atop.
> k18n_qt5_wrap_ui must also have its own macro options to support the new/
> modified ki18n functionality (namely setting the translation domain and
> activating the KUIT markup processing).
>

Ok, I'll leave this alone for now, and just #include  where 
we were depending on that being added to the ui_*.h files before.


- Jeremy


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


On Sept. 17, 2013, 1:56 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112785/
> ---
> 
> (Updated Sept. 17, 2013, 1:56 p.m.)
> 
> 
> Review request for KDE Frameworks and Alexander Neundorf.
> 
> 
> Description
> ---
> 
> It builds and installs, but doesn't seem to be usable from within kdelibs, 
> i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect 
> one more thing is needed to make it work from within kdelibs builds.
> 
> 
> Diffs
> -
> 
>   tier2/ki18n/CMakeLists.txt d0ed448 
>   tier2/ki18n/KI18nConfig.cmake.in 18b6e2f 
>   tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION 
>   tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112785/diff/
> 
> 
> Testing
> ---
> 
> Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

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

Re: Making KDocTools independent of KArchive

[Sune Vuorela]

> Maybe we can bundle the generated documentation?

Distributions in general don't want pregenerated .

/Sune

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

Re: [kde-promo] Terminology for Frameworks

[Carl Symons]

On Tuesday, September 24, 2013 10:09 (UTC) Jos Poortvliet wrote:
> Going through the article explaining Frameworks to the world*
> yesterday, I bumped into quite some inconsistent use of terms.
> 
> Right now, we mix up:
> modules
> components
> frameworks
> addons
> libraries

This article was developed using several previously published 
resources...blogposts, presentations, mailing list threads. These were written 
in different time frames, against a background of evolving understandings, for 
a variety of audiences.

The terms made sense within their respective contexts.

For people in the know, the distinctions are not a big deal. The multiple 
audiences intended for the article will not have a more-or-less automatic 
synonym-izer. So Jos and I went into some detail about what each of these 
terms would mean to various intended audiences.

The Frameworks 5 project looks one way to KDE developers. Other audiences such 
as technical journalists, Qt developers, managers of Qt-related projects and 
companies will have different views. This article will potentially reach many 
of these audiences.

Carl 


> 
> For example in the article, we mostly talked 'modules' intermingled
> with 'libraries', then suddenly started calling them addons and trow
> in some 'components'
> 
> As Kevin pointed out, library is certainly wrong: each
> framework/module CAN be multiple libraries (and even have binaries,
> runtime components).
> 
> After a discussion with Sebas and Carl, I now made the article talk
> about only 'Frameworks' and 'addons', the latter only in relationship
> to Qt, as in the KDE frameworks being a set of addons to Qt.
> 
> I added the following text to our Frameworks 5 communication plan:
> 
> To  prevent using too many interchangable and confusing terms, please
> try to stick to the following two: Frameworks and (Qt) addon. Use the
> term 'Framework' (capitalized) to refer to an individual, independent
> part of Frameworks 5 like KArchive or KIO. When explaining Frameworks,
> it is OK to explain that it is the result of an modularization of the
> older 'KDELIBS' and that one Framework offers one or more libraries
> and sometimes runtime components to (combined) perform a specific
> function.
> 
> See https://notes.kde.org/p/Frameworks5Communication
> 
> Feedback, as always, very much welcome.
> 
> Cheers,
> Jos
> 
> * http://dot.kde.org/2013/09/25/frameworks-5
> 


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

Terminology for Frameworks

[Jos Poortvliet]

Going through the article explaining Frameworks to the world*
yesterday, I bumped into quite some inconsistent use of terms.

Right now, we mix up:
modules
components
frameworks
addons
libraries

For example in the article, we mostly talked 'modules' intermingled
with 'libraries', then suddenly started calling them addons and trow
in some 'components'

As Kevin pointed out, library is certainly wrong: each
framework/module CAN be multiple libraries (and even have binaries,
runtime components).

After a discussion with Sebas and Carl, I now made the article talk
about only 'Frameworks' and 'addons', the latter only in relationship
to Qt, as in the KDE frameworks being a set of addons to Qt.

I added the following text to our Frameworks 5 communication plan:

To  prevent using too many interchangable and confusing terms, please
try to stick to the following two: Frameworks and (Qt) addon. Use the
term 'Framework' (capitalized) to refer to an individual, independent
part of Frameworks 5 like KArchive or KIO. When explaining Frameworks,
it is OK to explain that it is the result of an modularization of the
older 'KDELIBS' and that one Framework offers one or more libraries
and sometimes runtime components to (combined) perform a specific
function.

See https://notes.kde.org/p/Frameworks5Communication

Feedback, as always, very much welcome.

Cheers,
Jos

* http://dot.kde.org/2013/09/25/frameworks-5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 112880: Added KColorSchemeToken class.

[Denis Kuplyakov]

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

(Updated Sept. 24, 2013, 4:08 p.m.)


Review request for KDE Frameworks and kdelibs.


Changes
---

Fixed includes


Description
---

It is wrapper to access KColorScheme's methods from QML code.
Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them 
accessible from QML code.

As it will be accepted, QML-clone of KgPopupItem will be posted for review to 
libkdegames, as it uses it to access KDE's color theme.

More info:
* search for "KDE theme colors API for QML" thread at kdelibs and kdegames 
mailinglists *

NEED TO FIX:
I can't include it like #include  at KReversi's code, only 
"kcolorschemetoken.h". Maybe I've missed something?


Diffs (updated)
-

  includes/CMakeLists.txt cdf0143 
  includes/KColorSchemeToken PRE-CREATION 
  kdeui/CMakeLists.txt b439e04 
  kdeui/colors/kcolorscheme.h 17570fd 
  kdeui/colors/kcolorscheme.cpp a6650ac 
  kdeui/colors/kcolorschemetoken.h PRE-CREATION 
  kdeui/colors/kcolorschemetoken.cpp PRE-CREATION 

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


Testing
---

I've tested it with KReversi's deniskup/gsoc2013/newdesign branch.


Thanks,

Denis Kuplyakov

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

Re: QTimeZone merged for 5.2

[John Layt]

On 24 September 2013 12:11, Kevin Ottens  wrote:
>> OK, let's attempt to move KLocale, KDateTime and friends to kde4support now.
>> With some luck we'll be able to completely get rid of KDE4Attic before
>> release.
>
> Hmm, looking at that closer... indeed it looks like we can get rid of
> K*TimeZone in favor of QTimeZone. But what would you advise for porting away
> from KCalendarSystem and KLocalizedDate?
>
> Alternatives for those would be needed to move the date/time widgets currently
> stuck in KDE4Attic to a more proper framework.

Unfortunately QCalendarSystem was part of the QLocale changes that got
postponed to 5.3 :-\  In the lower tiers this shouldn't be an issue as
QDateTime or QLocale should be sufficient for their requirements.  If
you know of anything outside widgets that uses KCalendarSystem or
KLocalizedDate then I'll have a look.

For the widgets themselves, we had two main reasons for them: 1) The
Qt ones were rubbish, and 2) The Qt ones didn't support our calendar
systems  Once Qt gets QCalendarSystem then the Qt widgets will need to
support it, so I should have a good case for either fixing the
existing Qt widgets or adding new ones that actually work.  I've been
talking to the QML component guys and they will have a new calendar
component for 5.3 that they need QCalendarSystem for as well.  As they
stand, the KDE4 widgets are fairly tightly tied to KCalendarSystem and
KLocale, and if we keep them in KF5 then they would need porting to
QCalendarSystem and QLocale anyway, including a change of api for
apps.  We also want to drop some of our old date widgets that don't
work very well.  Given this all it may then make sense to move the
date widgets to KDE4Support along with the other date classes, as they
function as a whole.  Then if we cannot get decent widgets into Qt we
can create new widgets by porting our old ones to QCalendarSystem with
new names.  An alternative is to choose the date widgets we want to
keep and remove the KCalendarSupport from them for now, and restore it
when we get QCalendarSystem.

I'll do some analysis on the use of all the widgets and what ones are
worth keeping, and look at the Qt widgets to see if they're worth
switching to, if not before then at Qt Dev Days / Qt Contributors Day.

Cheers!

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

Review Request 112919: Prepare KParts for the move

[Aleix Pol Gonzalez]

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

Review request for KDE Frameworks.


Description
---

Moved all sources to src.
Installs a KPartsConfig.cmake file.
Documented dependencies.


Diffs
-

  kparts/CMakeLists.txt cae8539 
  kparts/KPartsConfig.cmake.in PRE-CREATION 
  kparts/browserextension.h  
  kparts/browserextension.cpp  
  kparts/browserinterface.h  
  kparts/browserinterface.cpp  
  kparts/browseropenorsavequestion.h  
  kparts/browseropenorsavequestion.cpp  
  kparts/browserrun.h  
  kparts/browserrun.cpp  
  kparts/browserrun_p.h  
  kparts/browserview.desktop  
  kparts/event.h  
  kparts/event.cpp  
  kparts/fileinfoextension.h  
  kparts/fileinfoextension.cpp  
  kparts/historyprovider.h  
  kparts/historyprovider.cpp  
  kparts/htmlextension.h  
  kparts/htmlextension.cpp  
  kparts/kpart.desktop  
  kparts/krop.desktop  
  kparts/krwp.desktop  
  kparts/listingextension.h  
  kparts/listingextension.cpp  
  kparts/mainwindow.h  
  kparts/mainwindow.cpp  
  kparts/part.h 3a8a56d 
  kparts/part.cpp  
  kparts/partmanager.h  
  kparts/partmanager.cpp  
  kparts/plugin.h  
  kparts/plugin.cpp  
  kparts/scriptableextension.h  
  kparts/scriptableextension.cpp  
  kparts/scriptableextension_p.h  
  kparts/src/CMakeLists.txt PRE-CREATION 
  kparts/statusbarextension.h  
  kparts/statusbarextension.cpp  
  kparts/textextension.h  
  kparts/textextension.cpp  
  staging/kde4support/src/CMakeLists.txt 5dc206d 

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


Testing
---

builds, tests pass.


Thanks,

Aleix Pol Gonzalez

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

Re: QTimeZone merged for 5.2

[Kevin Ottens]

On Tuesday 24 September 2013 19:03:21 John Layt wrote:
> I'll do some analysis on the use of all the widgets and what ones are
> worth keeping, and look at the Qt widgets to see if they're worth
> switching to, if not before then at Qt Dev Days / Qt Contributors Day.

OK, I'll ignore this part of KDE4Attic then and proceed with the rest. We 
really need to put this issue to a rest, it's been lingering for way too long. 
Really looking forward to your analysis!

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

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



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

Re: Templates for frameworks CMake files

[Alexander Neundorf]

On Tuesday 24 September 2013, Stephen Kelly wrote:
> Aurélien Gâteau wrote:
> > Hi,
> > 
> > I have been playing around with itemviews CMake files and put together
> > some templates for the top level CMakeLists.txt and *Config.cmake.in. You
> > can find them attached there. Any one against me adding those to the
> > repository?
> > 
> > Aurélien
> > CMakeLists.txt
> > 
> >   cmake_minimum_required(VERSION 2.8.11)
> 
> This template will be out of date whenever we require a new cmake.
> 
> >  project(FooBar)
> >  
> >  find_package(ECM 0.0.8 REQUIRED NO_MODULE)
> 
> The latest ECM is 0.0.9
> 
> >  set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
> >  
> >  set(REQUIRED_QT_VERSION "5.2.0")
> 
> ECM and Qt version bumps are not as much an issue as the cmake one. The ECM
> and Qt version deps are not as likely to change.
> 
> >  # Required Qt5 components to build this framework
> >  # For example:
> >  # find_package(Qt5 ${REQUIRED_QT_VERSION} REQUIRED NO_MODULE COMPONENTS
> >  # Widgets)
> 
> Simplify by putting NO_MODULE before REQUIRED and removing COMPONENTS:
> 
>  find_package(Qt5 ${REQUIRED_QT_VERSION} NO_MODULE REQUIRED Widgets)
> 
> >  if(NOT kdelibs_SOURCE_DIR)
> >  find_package(KF5 5.0.0 REQUIRED MODULE COMPONENTS CMake Compiler
> >  InstallDirs) # Required KF5 frameworks to build this framework
> 
> I still think this stuff is odd. We're building KF5, yet we need to find
> KF5 to do so.


If you have a better idea, feel free to change it.
Those files contain KDE-related stuff, the KDE compiler- and cmake settings 
and KDE install dirs.

There is no tier0 kde-cmake-modules repository, that was not wanted. Still, by 
finding (loading) FindKF5.cmake we load those settings, to avoid having a 
tier0 frameworks.

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

Re: Review Request 112797: Bring back KStringHandler::naturalCompare()

[Aleix Pol Gonzalez]

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

(Updated Sept. 24, 2013, 6:08 p.m.)


Review request for KDE Frameworks, Frank Reininghaus and Mark Gaiser.


Changes
---

Add deprecation note in the API documentation.


Description
---

Apparently there's people who still want to have it. Leave it in KCoreAddons 
for the moment, until we decide that it can be replaced for good by QCollator.


Diffs (updated)
-

  staging/kde4support/autotests/CMakeLists.txt 473bdba 
  staging/kde4support/autotests/naturalcomparetest.cpp PRE-CREATION 
  staging/kde4support/src/CMakeLists.txt 5dc206d 
  staging/kde4support/src/kdecore/kstringhandler_deprecated.h PRE-CREATION 
  staging/kde4support/src/kdecore/kstringhandler_deprecated.cpp PRE-CREATION 
  tier1/kcoreaddons/autotests/kstringhandlertest.cpp 93da351 
  tier1/kcoreaddons/src/lib/text/kstringhandler.h 442b97a 
  tier1/kcoreaddons/src/lib/text/kstringhandler.cpp ea3bbf5 

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


Testing
---

Builds, tests pass.


Thanks,

Aleix Pol Gonzalez

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

Re: Frameworks Overview

[Alexander Neundorf]

On Tuesday 24 September 2013, Ben Cooksley wrote:
> On Sep 24, 2013 7:33 AM, "Alexander Neundorf"  wrote:
> > On Monday 23 September 2013, Sebastian Kügler wrote:
> > > Hey,
> > > 
> > > On Monday, September 23, 2013 00:27:21 Cornelius Schumacher wrote:
> > > > On Thursday 19 September 2013 Sebastian Kügler wrote:
> > > > > http://community.kde.org/Frameworks/Overview
> > > > 
> > > > I have put the data on Inqlude (see http://inqlude.org/edge.html).
> > > 
> > > Thanks. One issue though, we're duplicating incomplete information that
> 
> is
> 
> > > in flux. (For example, I know of at least one framework that has been
> > > added to tier2 (I think) since last week. The information will need
> > > constant updating for a few more months. Having it in to places doesn't
> > > make that easier.
> > > 
> > > Can I update the info on inqlude.org somehow, so we can ditch the wiki
> > > version?
> > > 
> > > > It would be nice, if we could improve the presentation of the
> 
> different
> 
> > > > libraries along with the code. The goal of Inqlude is to make them
> 
> easily
> 
> > > > accessible not only to us, but also to Qt developers who don't
> > > > necessarily know anything about KDE or might have (more or less
> 
> founded)
> 
> > > > objections against using KDE libraries. To reach this we'll need to
> > > > present KF5 in a bit  more independent way, and make sure that each
> > > > library can stand on its own.
> > > 
> > > Technically, this is the current focus. We're splitting kdelibs.
> > > 
> > > As to communication, it probably needs a bit of boilerplate. (Which the
> > > bits I wrote don't contain purposefully.) Otherwise, you're right, we
> 
> need
> 
> > > to work on the presentation side here.
> > 
> > IMO, if projects.kde.org would have the wiki enabled, the project pages
> 
> there
> 
> > could be an easy way to have simple homepages for all the frameworks:
> > https://projects.kde.org/projects/kdesupport/attica
> 
> Due to maintenance and performance concerns, sysadmin would like to move
> away from Chiliproject.

Oh, really ?
What alternatives are you looking at ?
Personally I like redmine/chili a lot.

> Enabling the wiki would complicate this when a
> replacement is found.
> 
> It would also create competition with the main wikis.

I don't think so.
As Cornelius put it "To reach this we'll need to present KF5 in a bit 
more independent way, and make sure that each library can stand on its own."
IMO a kind of separate home page for each library is part of that.

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

Re: Review Request 112907: Move KEmoticons framework to tier3

[David Gil Oliva]

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

(Updated Sept. 24, 2013, 8:44 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Description
---

Move KEmoticons framework to tier3

Done:
-Adjust the CMakeLists.txt to the new location.
-Substitute kde_add_plugin to add_library.
-Substitute Qt5::Xml to Qt5Xml in target_link_libraries
-Substitute Qt5::Test to Qt5Test in target_link_libraries

TODO:
Modify API to make it more coherent


Diffs
-

  staging/CMakeLists.txt 5c52cbe 
  staging/kemoticons/CMakeLists.txt  
  staging/kemoticons/KEmoticonsConfig.cmake.in  
  staging/kemoticons/autotests/CMakeLists.txt b7e890c 
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-1.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-10.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-2.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-4.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-5.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-6.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-8.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/broken-9.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-1.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-1.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-2.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-2.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-3.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-3.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-4.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-4.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-5.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-5.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-6.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-6.output  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-7.input  
  staging/kemoticons/autotests/emoticon-parser-testcases/working-7.output  
  staging/kemoticons/autotests/kemoticontest.h  
  staging/kemoticons/autotests/kemoticontest.cpp  
  staging/kemoticons/src/CMakeLists.txt  
  staging/kemoticons/src/core/CMakeLists.txt  
  staging/kemoticons/src/core/kemoticons.h  
  staging/kemoticons/src/core/kemoticons.cpp  
  staging/kemoticons/src/core/kemoticonsTheme.desktop  
  staging/kemoticons/src/core/kemoticonsprovider.h  
  staging/kemoticons/src/core/kemoticonsprovider.cpp  
  staging/kemoticons/src/core/kemoticonstheme.h  
  staging/kemoticons/src/core/kemoticonstheme.cpp  
  staging/kemoticons/src/providers/CMakeLists.txt  
  staging/kemoticons/src/providers/adium/CMakeLists.txt c94c0be 
  staging/kemoticons/src/providers/adium/adium_emoticons.h  
  staging/kemoticons/src/providers/adium/adium_emoticons.cpp  
  staging/kemoticons/src/providers/adium/emoticonstheme_adium.desktop  
  staging/kemoticons/src/providers/kde/CMakeLists.txt e6d4243 
  staging/kemoticons/src/providers/kde/emoticonstheme_kde.desktop  
  staging/kemoticons/src/providers/kde/kde_emoticons.h  
  staging/kemoticons/src/providers/kde/kde_emoticons.cpp  
  staging/kemoticons/src/providers/pidgin/CMakeLists.txt  
  staging/kemoticons/src/providers/pidgin/emoticonstheme_pidgin.desktop  
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.h  
  staging/kemoticons/src/providers/pidgin/pidgin_emoticons.cpp  
  staging/kemoticons/src/providers/xmpp/CMakeLists.txt f034de0 
  staging/kemoticons/src/providers/xmpp/emoticonstheme_xmpp.desktop  
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.h  
  staging/kemoticons/src/providers/xmpp/xmpp_emoticons.cpp  
  staging/kemoticons/tests/CMakeLists.txt  
  staging/kemoticons/tests/main.cpp  
  tier3/CMakeLists.txt fb4de8f 

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


Testing
---

It compiles, tests pass.


Thanks,

David Gil Oliva

__

Review Request 112921: Adjust CMakeLists.txt files in KEmoticons (prior to splitting)

[David Gil Oliva]

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

Review request for KDE Frameworks.


Description
---

Adjust CMakeLists.txt files in KEmoticons (prior to splitting)

These changes permit moving the framework without any errors.


Diffs
-

  staging/kemoticons/autotests/CMakeLists.txt 
b7e890c19af2ba7febc7a45fc4a73daa25ea4f74 
  staging/kemoticons/src/providers/adium/CMakeLists.txt 
c94c0be669ed1b55bc6fd5fbe036d1e38228066c 
  staging/kemoticons/src/providers/kde/CMakeLists.txt 
e6d4243538e6f95db664efe0b8b162523a6b1179 
  staging/kemoticons/src/providers/xmpp/CMakeLists.txt 
f034de047847ffec50ac6a68977b01809010447d 

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


Testing
---

It builds. Tests pass. I tested moving the framework to tier3 without any 
compile erors.


Thanks,

David Gil Oliva

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

Re: Review Request 112921: Adjust CMakeLists.txt files in KEmoticons (prior to splitting)

[Aleix Pol Gonzalez]

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

Ship it!



staging/kemoticons/src/providers/xmpp/CMakeLists.txt


Make it REQUIRED?

find_package(Qt5Xml REQUIRED)


Looks good to me.

- Aleix Pol Gonzalez


On Sept. 24, 2013, 10:09 p.m., David Gil Oliva wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112921/
> ---
> 
> (Updated Sept. 24, 2013, 10:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Adjust CMakeLists.txt files in KEmoticons (prior to splitting)
> 
> These changes permit moving the framework without any errors.
> 
> 
> Diffs
> -
> 
>   staging/kemoticons/autotests/CMakeLists.txt 
> b7e890c19af2ba7febc7a45fc4a73daa25ea4f74 
>   staging/kemoticons/src/providers/adium/CMakeLists.txt 
> c94c0be669ed1b55bc6fd5fbe036d1e38228066c 
>   staging/kemoticons/src/providers/kde/CMakeLists.txt 
> e6d4243538e6f95db664efe0b8b162523a6b1179 
>   staging/kemoticons/src/providers/xmpp/CMakeLists.txt 
> f034de047847ffec50ac6a68977b01809010447d 
> 
> Diff: http://git.reviewboard.kde.org/r/112921/diff/
> 
> 
> Testing
> ---
> 
> It builds. Tests pass. I tested moving the framework to tier3 without any 
> compile erors.
> 
> 
> Thanks,
> 
> David Gil Oliva
> 
>

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

Re: Making KDocTools independent of KArchive

[Albert Astals Cid]

El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure:
> On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote:
> > El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va
> 
> escriure:
> > > On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote:
> > > > Maybe we can use a third-party docbook-to-manpage conversion tool. On
> > > > Linux
> > > > it would be easy to install, and on Windows it wouldn't be needed
> > > > ("what's
> > > > a manpage?"). And still leave it optional everywhere...
> > > 
> > > Thats a very good question. Maybe in that case kdoctools is indeed
> > > overkill. Someone would have to investigate if something else could be
> > > used though.
> > 
> > That's really weird, we have a solution that works, and you want to use
> > something else?
> > 
> > What does that gives us?
> > 
> > That stuff in kde now depends in two docbook-to-manpage conversion tools
> > instead of one?
> > 
> > Are you sure that's an improvement?
> 
> Well, as highlighted we have a dependency issue there, so it's either:
>  1) no docbook in tier 1 and tier 2 frameworks;
>  2) we use a different docbook to manpage tool for tier 1 and tier 2
> frameworks.

Why you guys don't treat e-c-m as a dependency for the tier system but treat 
kdoctools as one?

I mean they are both prerequisites for the other modules (and if you remove 
KArchive from kdoctools as the thread title suggests both are 'non-kde'), 
aren't they?

Cheers,
  Albert

> 
> Pick your poison. But we can't keep said dependency issue.
> 
> Regards.

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

Review Request 112923: Make leftMargin rightMargin virtual methods in KCategoryDrawer

[David Edmundson]

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

Review request for KDE Frameworks.


Description
---

Make leftMargin rightMargin virtual methods in KCategoryDrawer

Currently KCategoryDrawer operates on a setter/getter for margins
but setting the height and painting is all set by overriding methods

This makes everything consistent.

--

This was marked as a KDE5 TODO


Diffs
-

  KDE5PORTING.html 57ecf2e 
  tier1/itemviews/src/kcategorydrawer.h 3665457 
  tier1/itemviews/src/kcategorydrawer.cpp 0fb857e 

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


Testing
---


Thanks,

David Edmundson

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