Forward includes
Hi, I realized recently that we have a weird setup for those CamelCased includes that now we keep in kdelibs/includes, so I was guessing that probably we want to split them and move them into each directory. Also we should decide if we want to keep them in KDE/ or in a KModule/ directory and point to it from the Config.cmake files. What do you guys think? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Forward includes
Hi, I've been going through the kde4support forward includes, since I wanted to start making the modules I decided we'd better make sure all of them are working properly. After some research, I found that I don't have these available, can somebody please tell me if I'm missing some dependency or if these are indeed not available [1]? If there's no problem with this, I'll proceed to change these for a warning that they're not available anymore (see attachment). Cheers! Aleix PS: Happy holidays! [1] KAuth/ActionWatcher KCalendarSystemFactory KConfigINIBackEnd KCrashBookmarkImporter KCrashBookmarkImporterImpl KDateTable KDateValidator KDBusServiceStarter KDNSSD/Configuration KFileSharePropsPlugin KFileTreeBranch KFileTreeView KIdentityProxyModel KIMProxy KIO/Connection KIO/SessionData KIO/Task KMimeTypeResolver KNS/Author KNS/Category KNS/Engine KNS/Installation KNS/KTranslatable KParts/DockMainWindow3 KPixmapRegionSelectorDialog KSMIMECrypto KSystemEventFilter KTimeZoneWidget KUnitTest/Runner KUnitTest/SlotTester KUnitTest/Tester KUnitTest/TestResults ThreadWeaver/JobCollection ThreadWeaver/JobSequence ThreadWeaver/WeaverObserver diff --git a/src/includes/KAuth/ActionWatcher b/src/includes/KAuth/ActionWatcher index 36a503d..e868dfc 100644 --- a/src/includes/KAuth/ActionWatcher +++ b/src/includes/KAuth/ActionWatcher @@ -1 +1 @@ -#include "../../kauthactionwatcher.h" +#warning "This file is not available anymore" diff --git a/src/includes/KCalendarSystemFactory b/src/includes/KCalendarSystemFactory index 3ab6d1d..e868dfc 100644 --- a/src/includes/KCalendarSystemFactory +++ b/src/includes/KCalendarSystemFactory @@ -1 +1 @@ -#include "../kcalendarsystemfactory.h" +#warning "This file is not available anymore" diff --git a/src/includes/KConfigINIBackEnd b/src/includes/KConfigINIBackEnd index 5e607af..e868dfc 100644 --- a/src/includes/KConfigINIBackEnd +++ b/src/includes/KConfigINIBackEnd @@ -1 +1 @@ -#include "../kconfigini.h" +#warning "This file is not available anymore" diff --git a/src/includes/KCrashBookmarkImporter b/src/includes/KCrashBookmarkImporter index 1128400..e868dfc 100644 --- a/src/includes/KCrashBookmarkImporter +++ b/src/includes/KCrashBookmarkImporter @@ -1 +1 @@ -#include "../kbookmarkimporter_crash.h" +#warning "This file is not available anymore" diff --git a/src/includes/KCrashBookmarkImporterImpl b/src/includes/KCrashBookmarkImporterImpl index 1128400..e868dfc 100644 --- a/src/includes/KCrashBookmarkImporterImpl +++ b/src/includes/KCrashBookmarkImporterImpl @@ -1 +1 @@ -#include "../kbookmarkimporter_crash.h" +#warning "This file is not available anymore" diff --git a/src/includes/KDBusServiceStarter b/src/includes/KDBusServiceStarter index 7eb6fa6..e868dfc 100644 --- a/src/includes/KDBusServiceStarter +++ b/src/includes/KDBusServiceStarter @@ -1 +1 @@ -#include "../kdbusservicestarter.h" +#warning "This file is not available anymore" diff --git a/src/includes/KDNSSD/Configuration b/src/includes/KDNSSD/Configuration index c568305..e868dfc 100644 --- a/src/includes/KDNSSD/Configuration +++ b/src/includes/KDNSSD/Configuration @@ -1 +1 @@ -#include "../../kdnssd/settings.h" +#warning "This file is not available anymore" diff --git a/src/includes/KDateTable b/src/includes/KDateTable index 08c8315..e868dfc 100644 --- a/src/includes/KDateTable +++ b/src/includes/KDateTable @@ -1 +1 @@ -#include "../kdatetable.h" +#warning "This file is not available anymore" diff --git a/src/includes/KDateValidator b/src/includes/KDateValidator index 08c8315..e868dfc 100644 --- a/src/includes/KDateValidator +++ b/src/includes/KDateValidator @@ -1 +1 @@ -#include "../kdatetable.h" +#warning "This file is not available anymore" diff --git a/src/includes/KFileSharePropsPlugin b/src/includes/KFileSharePropsPlugin index aefd8d2..e868dfc 100644 --- a/src/includes/KFileSharePropsPlugin +++ b/src/includes/KFileSharePropsPlugin @@ -1 +1 @@ -#include "../kfilesharedialog.h" +#warning "This file is not available anymore" diff --git a/src/includes/KFileTreeBranch b/src/includes/KFileTreeBranch index dda7372..e868dfc 100644 --- a/src/includes/KFileTreeBranch +++ b/src/includes/KFileTreeBranch @@ -1 +1 @@ -#include "../kfiletreebranch.h" +#warning "This file is not available anymore" diff --git a/src/includes/KFileTreeView b/src/includes/KFileTreeView index a3bb394..e868dfc 100644 --- a/src/includes/KFileTreeView +++ b/src/includes/KFileTreeView @@ -1 +1 @@ -#include "../kfiletreeview.h" +#warning "This file is not available anymore" diff --git a/src/includes/KIMProxy b/src/includes/KIMProxy index f092060..e868dfc 100644 --- a/src/includes/KIMProxy +++ b/src/includes/KIMProxy @@ -1 +1 @@ -#include "../kimproxy.h" +#warning "This fi
Re: Forward includes
Hello, On Friday 18 October 2013 20:24:00 Aleix Pol wrote: > I realized recently that we have a weird setup for those CamelCased > includes that now we keep in kdelibs/includes, so I was guessing that > probably we want to split them and move them into each directory. I think we want those installed as is by kde4support, because they're here for existing code to still compile (we got KDE/foo includes in our codebase). > Also we should decide if we want to keep them in KDE/ or in a KModule/ > directory and point to it from the Config.cmake files. IIRC the last time this topic was discussed I think we were leaning toward a KF5/Module/ directory. And yes the Config.cmake files should point to it IMO. > What do you guys think? The above is pretty much it on my side, but I'd like to add something: We should get those forwarding includes generated to not have to maintain them by hand anymore. Since we had to do some header generation in some of the frameworks to get them to comply with the standard directory layout, it looks like something we could get cmake to do. 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
Re: Forward includes
> The above is pretty much it on my side, but I'd like to add something: > We should get those forwarding includes generated to not have to maintain Lets bring this topic back from the dead. I don't have a real preference between include/Module, include/KDE/Module and include/KF5/Module. Main benefit of include/KF5/Module is the fact that the users will be able to have different non-ABI/API-compatible versions of KF installed at the same time, if this is needed at all. As for pointing the cmake configs to that path, it might be tricky to achieve in all libraries. Namely those that rely on namespaces instead of prefixing the names of classes with K or KSomething. For example, while #include can work without collisions, it can not for libraries like Solid (classes named Camera, Video, Button -> needs to be #include etc.) or KActivities (Controller, Info -> #include etc.) Cheers, Ivan -- The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana. -- Joe Armstrong ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Mon, Oct 21, 2013 at 11:39 AM, Kevin Ottens wrote: > Hello, > > On Friday 18 October 2013 20:24:00 Aleix Pol wrote: > > I realized recently that we have a weird setup for those CamelCased > > includes that now we keep in kdelibs/includes, so I was guessing that > > probably we want to split them and move them into each directory. > > I think we want those installed as is by kde4support, because they're here > for > existing code to still compile (we got KDE/foo includes in our codebase). > > > Also we should decide if we want to keep them in KDE/ or in a KModule/ > > directory and point to it from the Config.cmake files. > > IIRC the last time this topic was discussed I think we were leaning toward > a > KF5/Module/ directory. And yes the Config.cmake files should point to it > IMO. > > > What do you guys think? > > The above is pretty much it on my side, but I'd like to add something: > We should get those forwarding includes generated to not have to maintain > them > by hand anymore. Since we had to do some header generation in some of the > frameworks to get them to comply with the standard directory layout, it > looks > like something we could get cmake to do. > > 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 > Ok, works for me, consider it as an assigned task. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Tue, Oct 22, 2013 at 11:06 AM, Ivan Čukić wrote: > > > The above is pretty much it on my side, but I'd like to add something: > > We should get those forwarding includes generated to not have to maintain > > Lets bring this topic back from the dead. > > I don't have a real preference between include/Module, include/KDE/Module > and > include/KF5/Module. > > Main benefit of include/KF5/Module is the fact that the users will be able > to > have different non-ABI/API-compatible versions of KF installed at the same > time, if this is needed at all. > > As for pointing the cmake configs to that path, it might be tricky to > achieve > in all libraries. Namely those that rely on namespaces instead of prefixing > the names of classes with K or KSomething. > > For example, while #include can work without collisions, it can not > for > libraries like Solid (classes named Camera, Video, Button -> needs to be > #include etc.) or KActivities (Controller, Info -> > #include etc.) > > Cheers, > Ivan > > > -- > The problem with object-oriented languages is they’ve got all this > implicit environment that they carry around with them. You wanted > a banana but what you got was a gorilla holding the banana. > -- Joe Armstrong > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > I'll be sending a review soon, we can discuss it further over some code :). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Friday 27 December 2013 19:00:14 Aleix Pol wrote: > Hi, > I've been going through the kde4support forward includes, since I wanted to > start making the modules I decided we'd better make sure all of them are > working properly. > > After some research, I found that I don't have these available, can > somebody please tell me if I'm missing some dependency or if these are > indeed not available [1]? If there's no problem with this, I'll proceed to > change these for a warning that they're not available anymore (see > attachment). > > Cheers! > Aleix > > PS: Happy holidays! I have checked a few of them manually and indeed the real header files do not exists. The approach in the patch seems correct, we don't want to add a source incompatible change by removing them, but I'd change the message from: #warning "This file is not available anymore in KF5, please see http://community.kde.org/Frameworks/Porting_Notes " Or something in this fashion so it is more useful. Cheers. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Friday 27 December 2013 19:54:14 Àlex Fiestas wrote:
> On Friday 27 December 2013 19:00:14 Aleix Pol wrote:
> > Hi,
> > I've been going through the kde4support forward includes, since I wanted
> > to
> > start making the modules I decided we'd better make sure all of them are
> > working properly.
> >
> > After some research, I found that I don't have these available, can
> > somebody please tell me if I'm missing some dependency or if these are
> > indeed not available [1]? If there's no problem with this, I'll proceed to
> > change these for a warning that they're not available anymore (see
> > attachment).
>
> I have checked a few of them manually and indeed the real header files do
> not exists.
Yes, but for at least one of them it's a mistake:
I forgot to add the rule for installing kdbusservicestarter.h
Will fix asap.
The others look like stuff that got removed, or was made internal.
> The approach in the patch seems correct, we don't want to add a source
> incompatible change by removing them, but I'd change the message from:
>
> #warning "This file is not available anymore in KF5, please see
> http://community.kde.org/Frameworks/Porting_Notes
I think you should use #error instead.
#warning doesn't work with MSVC iirc (it uses #pragma message("..") instead).
Well, #pragma message() works with gcc, so you could use that everywhere if
you don't want to make it an error.
--
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
