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
