On Thursday 16 January 2014 17:57:51 Friedrich W. H. Kossebau wrote: > Am Mittwoch, 15. Januar 2014, 12:14:59 schrieb David Faure: > > On Wednesday 15 January 2014 11:01:55 Friedrich W. H. Kossebau wrote: > > > Guess you already started to tackle that? :) Or should I give it a try > > > tonight? > > > > Go ahead :) > > Some questions while I go ahead: > > 1. How should own headers be included, what is preferred? > #include <kparts/part.h> > or > #include "part.h" > > And both the same in the public headers and in the normal sources? Myself I > also use the second version, but I found a mixture in use, so wonder if one > is preferred/recommended in the frameworks.
They should both work just the same, I can't see how/when either one would break. I think my preference would be "part.h" in part.cpp (makes it easy for krazy to check the rule "include your own header first"), and <kparts/part.h> in header files -- so that if anyone copies that to their own app, it'll work. > 2. How to do KDE4-compatibility for moved header content? > > E.g. in event.h for KDE4-compatibility the declarations which have been > moved to their own headers would need to be pulled in again, at least for > builds using KDE4Support > Is that done by having includes in the normal file, guarded by a flag, like > > // KDE4 compat > #if KDE4COMPATIBLE > #include <kparts/guiactivateevent.h> > #include <kparts/partactivateevent.h> > #include <kparts/partselectevent.h> > #endif I don't think we need a #if. The headers installed by kde4support become unavailable as soon as you stop linking kde4support. So app who want to be "clean from compat stuff" will eventually have to stop using such compat headers, in order to reach the goal "does not link to kde4support anymore". -- 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
