modules for KF5 TP1 release
Below is the list of modules that I created for the TP1 release. Please check for errors and omissions. I did NOT include: strigi, phonon, libdbusmenu-qt, kactivities, kde-runtime. Should any of these be included? extra-cmake-modules master attica master frameworkintegrationmaster kapidoxmaster karchivemaster kauthmaster kbookmarksmaster kcmutilsmaster kcodecsmaster kcompletionmaster kconfigmaster kconfigwidgetsmaster kcoreaddonsmaster kcrashmaster kdbusaddonsmaster kde4supportmaster kdeclarativemaster kdedmaster kdesignerpluginmaster kdesumaster kdewebkitmaster kdnssd-frameworkmaster kdoctoolsmaster kemoticonsmaster kf5umbrellamaster kfileaudiopreviewmaster kglobalaccelmaster kguiaddonsmaster khtmlmaster ki18nmaster kiconthemesmaster kidletimemaster kimageformatsmaster kinitmaster kiomaster kitemmodelsmaster kitemviewsmaster kjobwidgetsmaster kjsmaster kjsembedmaster kmediaplayermaster knewstuffmaster knotificationsmaster knotifyconfigmaster kpartsmaster kplottingmaster kprintutilsmaster kptymaster krossmaster kservicemaster ktextwidgetsmaster kunitconversionmaster kwallet-frameworkmaster kwidgetsaddonsmaster kwindowsystemmaster kxmlguimaster solidmaster sonnetmaster threadweavermaster -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Issues porting KGeography to KF5
On Tuesday 31 December 2013 00:52:59 David Gil Oliva wrote: Hi! I'm porting KGeography to KF5, and I found some issues. *KConfigDialog::setHelp()* KConfigDialog* dialog = new KConfigDialog(this, settings, kgeographySettings::self()); dialog-setHelp(configuration, kgeography); It gives me the following error: /home/david/devel/kgeography/src/kgeography.cpp:170:13: error: ‘class KConfigDialog’ has no member named ‘setHelp’ make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2 make: *** [all] Error 2 What should I subtitute it for? Or should I drop it? Kévin? Is the help button missing in your port of KPageDialog to QDialogButtonBox? *KApplication::setTopWidget()* Should I drop it? Is there anything I can substitute it for? I looked into this one, and documented the answer: diff --git a/src/kdeui/kapplication.h b/src/kdeui/kapplication.h index af026e8..474ec8c 100644 --- a/src/kdeui/kapplication.h +++ b/src/kdeui/kapplication.h @@ -208,7 +208,11 @@ public: * @param topWidget A top widget of the application. * * @see icon(), caption() - **/ + * @deprecated since 5.0. This was doing two things: 1) setting the window title to + * include the appname; Qt now takes care of that on platforms where this is wanted. + * 2) setting the window startup ID, which Qt should take care of in the future. + * - simply remove this call. + */ void setTopWidget(QWidget *topWidget); -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks Performance Question
On 12/30/2013 06:50 PM, David Faure wrote: On Monday 30 December 2013 17:20:23 Hugo Pereira Da Costa wrote: Indeed oxygen (@KDE4) was using: connect( KGlobalSettings::self(), SIGNAL(kdisplayPaletteChanged()), this, SLOT(globalPaletteChanged()) ); Interesting, so every style had to do this, rather than KStyle doing it centrally. No no: in KDE4, oxygen was not inheriting from KStyle but QCommonStyle. In KF5 it is inheriting again from the (much cleaned-up) KStyle class. So that I'm all for moving it (or any KF5 equivalent) to KStyle. (just not the way it is done now ;)) Shall we keep the same idea for KF5 or move it up to KStyle? I guess globalPaletteChanged() was in oxygen, but the reparsing done inside kglobalsettings made things work in kstyle too. yes. But should be avoided. I'll look into it a bot (but Alex might now better). In the meanwhile, I would just comment out the reparsing (which in turn would imply that configuration changes would only apply to newly started applciations, but I guess that's better than having unresponsive applications ...) Oppinions ? I think a quick revert would be nice, to get some usable state again ;) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
build.kde.org email notifications
Hello, Now that all the frameworks are green on build.kde.org, I just enabled email notifications to k-f-d in all 57 jobs. Beware the brown paper bag! :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
right?
No,
include/KF5/ki18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
(lowercase ki18n in the first line).
See make install in kcoreaddons now:
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
If the header files of a framework are not prefixed, then they should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
Aleix, is there a final version of that RFC in a wiki page maybe, so we can
all make sure we refer to the same spec for this?
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear to
me, hence my request for a final spec.
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments
given that all headers are already contained in subdirs? IMHO that should
be left to be defined by the packager/installer. For what reason would we
want to enforce that?
For co-installability in /usr/include.
Will there be any files outside of the $MODULENAME/ subdirs?
I don't think so.
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
I don't like them very much. They make compilation slower, and allow people to
be lazy instead of doing the right thing
In quick test programs they are fine, but they are quickly abused in real
code...
Well, I won't veto them (consistency is good), but I certainly won't spend
time on them.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tue, Dec 31, 2013 at 12:50 PM, David Faure fa...@kde.org wrote:
On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones
were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
right?
No,
include/KF5/ki18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
(lowercase ki18n in the first line).
See make install in kcoreaddons now:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
If the header files of a framework are not prefixed, then they should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
Aleix, is there a final version of that RFC in a wiki page maybe, so we can
all make sure we refer to the same spec for this?
Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE - {ModuleName}.
I don't know about any page on the wiki about headers structure. We really
need this.
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear
to
me, hence my request for a final spec.
The RFC thread is more about whether include/.../KCoreAddons
and include/.../kcoreaddons should be by default in the include paths or
not.
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments
given that all headers are already contained in subdirs? IMHO that should
be left to be defined by the packager/installer. For what reason would we
want to enforce that?
For co-installability in /usr/include.
I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.
Will there be any files outside of the $MODULENAME/ subdirs?
I don't think so.
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
I don't like them very much. They make compilation slower, and allow
people to
be lazy instead of doing the right thing
In quick test programs they are fine, but they are quickly abused in real
code...
Well, I won't veto them (consistency is good), but I certainly won't spend
time on them.
AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes Almost 2014
Hello everyone, This is the minutes of the last meeting of 2013. As usual it has been held on #kde-devel at 4pm Paris time. Were present: apol and myself. Announcement: * TP1 is almost ready, forwarding headers work missing * apol has been working on the header generation for KCoreAddons, KGuiAddons and KWidgetsAddons; * he'll cover KArchive and ThreadWeaver next which are blocking TP1; * ervin has been acting behind the scene to get things rolling for TP1; * feels like being a kind of manager, not doing terribly much on the technical front; And that's it for today! Don't party too hard tonight, see you in 2014! Regards. -- Kévin Ottens, http://ervin.ipsquad.net 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: KF5 Update Meeting Minutes Almost 2014
On Tuesday 31 December 2013 16:17:20 Kevin Ottens wrote: Hello everyone, This is the minutes of the last meeting of 2013. As usual it has been held on #kde-devel at 4pm Paris time. Were present: apol and myself. Sorry, missed it by 30 minutes. Announcement: * TP1 is almost ready, forwarding headers work missing * apol has been working on the header generation for KCoreAddons, KGuiAddons and KWidgetsAddons; * he'll cover KArchive and ThreadWeaver next which are blocking TP1; Can we distribute the work, to get this done faster? I'll take KDBusAddons and KService, let's say. It would be good if someone with more knowledge of the consensus for installed headers would take care of kio and kparts, i.e. the prefixed cases. Aleix or Aurélien, can you maybe start with putting up the spec in the wiki? Or do we still have things to discuss? I didn't fully follow that discussion, so I'm not sure if it's all solved or not (see the questions from Friedrich Kossebau). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks Performance Question
On Monday, December 30, 2013 12:54:20 Christoph Cullmann wrote: On Sunday 29 December 2013 20:07:38 Christoph Cullmann wrote: #10 0x73fbeaa0 in KConfig::reparseConfiguration (this=0x688130) at /home/cullmann/local/kf5/src/frameworks/kconfig/src/core/kconfig.cpp:633 #11 0x7fffe5bad6b7 in KStyle::styleHint (this=0x658da0, hint=QStyle::SH_Widget_ShareActivation, option=0x0, widget=0x9f2050, returnData=0x0) at Yep, every call to styleHint() calls reparseConfiguration(), which is crazy. Yep, thought so that this is unwanted. For Kate on KF5 that means, it close to completely unusable, as any real redraw crawls away, would be nice to have this fixed before TP1, else it makes a bad impression about KF5 performance TP1 is only about threadweaver and karchive, Oxygen, or even KConfig aren't part of it. -- 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
Re: What are the plans with CamelCase includes?
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE - {ModuleName}.
Ah, for old-style #include KDE/KIcon?
Let's just script that away and make it #include KIcon.
We don't need a KDE prefix, we already have a KF5 prefix at install time.
This is the QtGui/QLabel thing again. Prefixes in the #include line create
future trouble when the prefix isn't related to the C++ class/namespace but
just arbitrary.
I don't know about any page on the wiki about headers structure. We really
need this.
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear
to
me, hence my request for a final spec.
The RFC thread is more about whether include/.../KCoreAddons
and include/.../kcoreaddons should be by default in the include paths or
not.
Well, that much is clear, the answer is yes, we want #include kjob.h and
#include KJob, no prefix in the #include line.
But ... going back to the question of where we should install kparts
headers... I'm pretty sure you and Aurélien (and others, possibly) had come up
with a final solution, didn't you?
I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.
Yes.
Q: Add a convenience Module/Module file?
AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.
Exactly: that's what they're good for, but in an opensource environment you
can't know what people are going to be using as setup for compiling (unlike a
more controlled internal-to-one-commercial-company setup), so we can't rely on
people having precompiled headers support.
However, with that argument, we could be providing all-in-one headers for the
benefit of commercial companies who can be sure they use precompiled
headers... Oh well, let's postpone this, it's more urgent to install the stuff
in the first place.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes Almost 2014
On Tuesday 31 December 2013 16:29:19 David Faure wrote: Can we distribute the work, to get this done faster? I'll take KDBusAddons and KService, let's say. I'm putting together a script to automate most of it. Current version: http://www.davidfaure.fr/2013/install_headers.sh http://www.davidfaure.fr/2013/install_headers.pl -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
