On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote:
There the used namespace does not match the module name:
namespace is KNS3, the module name KNewStuff3.
That's not a problem, the KIOCore module uses namespace (and therefore prefix)
KIO.
I just saw this mail, after my reply
Am Montag, 13. Januar 2014, 09:40:57 schrieb David Faure:
On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote:
There the used namespace does not match the module name:
namespace is KNS3, the module name KNewStuff3.
That's not a problem, the KIOCore module uses namespace
On Monday 13 January 2014 17:50:25 Friedrich W. H. Kossebau wrote:
Those knewstuff3/file.h forwarding headers you are proposing, they would be
installed from KDE4Support, right? To [...]/include/KF5/knewstuff3, with
the pattern...
file entry.h contains: #include kns3/entry.h
Ah, good idea.
Am Donnerstag, 2. Januar 2014, 15:30:20 schrieb David Faure:
On Thursday 02 January 2014 14:06:47 Kevin Ottens wrote:
On Thursday 02 January 2014 12:25:47 David Faure wrote:
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the
On Thursday 02 January 2014 07:45:12 Kevin Ottens wrote:
On Thursday 02 January 2014 00:31:05 David Faure wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
This wasn't intended I guess. When the discussion about include files
occured the consensus was to have everything in a single directory (the
camel cased one).
OK I initially thought it was so the implementation of ecm_generate_headers
is
simpler (lowercase everything), but in fact
On Thursday 02 January 2014 11:42:57 Christoph Cullmann wrote:
This wasn't intended I guess. When the discussion about include files
occured the consensus was to have everything in a single directory (the
camel cased one).
OK I initially thought it was so the implementation of
- Ursprüngliche Mail -
Hmm,
just a question for the case, that we have a namespace, like KTextEditor.
At the moment we install (e.g. for KTextEditor::View):
KTextEditor/View
and
ktexteditor/view.h
Will that change still make that possible?
Ah, good point.
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the corresponding patch for ECM.
Tested on KParts too, with the addition of a PREFIX variable.
MODULE_NAME = KParts or KIOCore .. the include dir under KF5, always titlecase
PREFIX = KParts or KIO,
On Thursday 02 January 2014 12:25:47 David Faure wrote:
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the corresponding patch for ECM.
Tested on KParts too, with the addition of a PREFIX variable.
MODULE_NAME = KParts or KIOCore .. the
On Thu, Jan 2, 2014 at 12:31 AM, David Faure fa...@kde.org wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- 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
On Thursday 02 January 2014 14:06:47 Kevin Ottens wrote:
On Thursday 02 January 2014 12:25:47 David Faure wrote:
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the corresponding patch for ECM.
Tested on KParts too, with the addition
On Thursday 02 January 2014 12:25:47 David Faure wrote:
Awaiting for green light.
/me waves the green light.
Cheers.
--
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.
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- 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
On Thursday 02 January 2014 00:31:05 David Faure wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- 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
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?
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
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
Am Samstag, 28. Dezember 2013, 12:32:43 schrieb Kevin Ottens:
On Saturday 28 December 2013 11:55:56 David Faure wrote:
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from kdelibs would have to explicitely prefix
the
includes, e.g. be changed
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
Am Samstag, 28. Dezember 2013, 12:32:43 schrieb Kevin Ottens:
On Saturday 28 December 2013 11:55:56 David Faure wrote:
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from
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
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from kdelibs would have to explicitely prefix the
includes, e.g. be changed like
#include KLocalizedString - #include KI18n/KLocalizedString
Definitely don't want this.
See the QtGui/QLabel -
On Saturday 28 December 2013 11:55:56 David Faure wrote:
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from kdelibs would have to explicitely prefix the
includes, e.g. be changed like
#include KLocalizedString - #include KI18n/KLocalizedString
On 24/12/13 07:38, Friedrich W. H. Kossebau wrote:
Hi,
what are the plans with offering CamelCase includes in KF5 (e.g. #include
KLocale)? On a quick search could not find anything mentioned somewhere.
If I saw correctly, then currently CamelCase includes (for existing
classes) are only
On Tue, Dec 24, 2013 at 12:14 PM, Alex Merry k...@randomguy3.me.uk wrote:
On 24/12/13 07:38, Friedrich W. H. Kossebau wrote:
Hi,
what are the plans with offering CamelCase includes in KF5 (e.g. #include
KLocale)? On a quick search could not find anything mentioned
somewhere.
If I
Hello,
On Tue, Dec 24, 2013 at 5:59 PM, Aleix Pol aleix...@kde.org wrote:
I'll try to take some time after the 26th to do it. If somebody wants to do
it meanwhile, please do and I'll review it.
I have some spare time and want to do it.. If I want to check one
example for it.. the code in
26 matches
Mail list logo