KF5 Update Meeting Minutes 2013-w31

[Alexander Neundorf]

On Tuesday 30 July 2013, Kevin Ottens wrote:
> Hello everyone,
> 
> This is the minutes of the Week 31 KF5 meeting. As usual it has been held
> on #kde-devel at 4pm Paris time.
> 
> Were present: afiestas, agateau, apol, ben2367, d_ed, dfaure, mck182,
> mgraesslin, miroslav, sebas, steveire, teo, wojtask9 and myself.
> 
> Announcements:
>  * Please everyone run the whole kdelibs test suite before pushing, your
> changes might have side-effects at places you wouldn't expect.
> 
> Topics discussed:
>  * afiestas should be done tomorrow for the styleHint change, so hopefully
> soon in Qt;
>  * then he plans to focus on other QPA related tasks;
>  * agateau has been working on the context menu fixes for QLineEdit and
> QTextEdit;
>  * then he plans to focus on QSessionManager giving a hand to the existing
> effort;
>  * apol merged his changes to use QFontsDatabase instead of
> KGlobalSettings; * he is now looking into moving
> KStringHandler::naturalCompare to Qt; * sebas has his KPluginFactory
> patches in review;
>  * ben2367 is still looking in unifying our cmake files regarding variables
> vs direct use of targets;

Current conclusion (not yet merged into cmake, but will hopefully make it for 
2.8.12): use ${PackageName_LIBRARY_TARGETS}.
Once the support for this is in cmake, cmake will guarantee that the contents 
of this variable all refer to existing targets, and that each of these targets 
has the INTERFACE_INCLUDE_DIRECTORIES property set, so that for the reader of 
a CMakeLists.txt a call like
target_link_libraries(foo ${KCoreAddons_LIBRARY_TARGETS} )
will guarantee that this thing contains targets, and that these targets come 
attached with the include dirs, so that no include_directories() call is 
necessary for KCoreAddons, in this example.
No framework sets this variable yet.
So from my side I don't see a need to hurry with this.

I'll have time again to work in this in roughly 3 weeks.

>  * he's also working on the forwarding headers generation;
>  * and last but not least he's making progress on a script to plot the
> frameworks dependencies;

Dependencies to external packages or between the libraries within kdelibs ?
I guess you did have a look at cmake --graphviz=<filename> <buildir> ?
If you use cmake git master, the options for modifying the output should now 
even be documented.

>  * d_ed is working on a patch for having QKeySequence defaults tied to our
> configuration;
>  * dfaure started to use some of the QUrl changes in kdelibs;
>  * he's also working on QCommandLineParser;
>  * mck182 is looking into the overlay support in QIcon;
>  * he's also working on putting the cups features in QPrintDialog;
>  * mgraesslin did some fixes as needed for kwin;
>  * miroslav is preparing another bigger API change in threadweaver;
>  * wojtask9 is looking into cleaning up our use of LINK_PRIVATE vs
> LINK_PUBLIC in our cmake files;
>  * he's also working on the kmodifierkeyinfo port to xcb;
>  * I'm still working on emptying kdecore, and almost there;
>  * help is welcome for porting away from kde_file.h.
> 
> Action items still open:
>  * [sandsmark] Finish the work on KPtyProcess
>  * [steveire] Write a "CMake for frameworks" guideline in the wiki

I was about to start with that.
I think it may make sense to have 3 separate sections:
* using KDE frameworks libraries for 3rd party developers (i.e. Qt project 
which want to make use of one or another library)
* using KDE frameworks for KDE software ("full blown" KDE applications)
* using cmake withint KDE frameworks

Alex