Re: KTextEditor Frameworks question
On Wednesday 08 January 2014 23:00:02 Alex Merry wrote: On 08/01/14 22:24, Kevin Ottens wrote: I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_con sistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Done. Hm? I don't see any change to the section? 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: KTextEditor Frameworks question
On 09/01/14 13:11, Kevin Ottens wrote: On Wednesday 08 January 2014 23:00:02 Alex Merry wrote: On 08/01/14 22:24, Kevin Ottens wrote: I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_con sistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Done. Hm? I don't see any change to the section? Ah, it turns out that's because I got confused and added it to http://community.kde.org/Frameworks/CreationGuidelines. I've now also added it to the Policies page. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 20:48:39 David Faure wrote: The checklist for new frameworks can be extracted from http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation which gives: * make new repo using script (done, in your case) * run astyle-kdelibs (requires some patching, so I can do it if you want) * adjust kde-build-metadata * get the job set up on build.kde.org (Ben or Aurélien) * ensure green ;) * add to bugs.kde.org (d_ed: how?) * add to reviewboard.kde.org (sysadmin request I suppose) Any wiki page where I add this list? Maybe it should go at the end of the list from definition of done in http://community.kde.org/Frameworks/Epics/Splitting_kdelibs ? Following this discussion I added the following page: http://community.kde.org/Frameworks/CreationGuidelines I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_consistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Seems to me that this is the only useful thing left from that wiki page, which we can otherwise delete, no? I'd keep it for reference, but yes it's more archives at that point. 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: KTextEditor Frameworks question
On 08/01/14 22:24, Kevin Ottens wrote: I also modified a bit one of the policies: http://community.kde.org/Frameworks/Policies#Frameworks_buildsystem_is_consistent (was saying installation rules but it's really more about style of the buildsystem, we might want to reference aurélien's template there if someone feels like adding that). Done. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 07:12:40 Christoph Cullmann wrote: I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? Hmm, the framework-template did not indicate that, but yeah, you are right, e.g. KCoreAddons has everywhere KCoreAddons as identifier beside for the .cmake stuff and the library name, there it is KF5CoreAddons. Is changing that to KF5TextEditor the right way to fix the issue then Yes, and please fix the template while you're at it :-) Will give it a try in the evening ;) Just a question: ATM setup.sh gets just the name + dest, e.g. I told it the name KTextEditor Should the heuristic be: If there is a K in front, remove it and do stuff like KFooBar leads to KF5FooBar, else keep the complete FooBar name and do KF5FooBar. 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
Re: KTextEditor Frameworks question
On Tue, Jan 7, 2014 at 9:37 AM, Christoph Cullmann cullm...@absint.comwrote: Should the heuristic be: If there is a K in front, remove it and do stuff like KFooBar leads to KF5FooBar, else keep the complete FooBar name and do KF5FooBar. Yes, pretty much that. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
Hi, I just tried to fix the naming issues. Does that try here look better http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git If yes, I would ask sysadmin to move to framworks, if that is ok and remove the stuff in frameworks branch of kate.git. Greetings Christoph - Ursprüngliche Mail - On Tuesday 07 January 2014 07:12:40 Christoph Cullmann wrote: I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? Hmm, the framework-template did not indicate that, but yeah, you are right, e.g. KCoreAddons has everywhere KCoreAddons as identifier beside for the .cmake stuff and the library name, there it is KF5CoreAddons. Is changing that to KF5TextEditor the right way to fix the issue then Yes, and please fix the template while you're at it :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- - 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
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 19:57:56 Christoph Cullmann wrote:
Hi,
I just tried to fix the naming issues.
Does that try here look better
http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git
I see a ${FooBar_HEADERS} in src/CMakeLists.txt which is used but not set,
should be removed.
src/include/CMakeList.txt is the one calling ecm_generate_headers, but in a
strange way: it sets KTEXTEDITOR_PUBLIC_HEADERS which was already set,
so it overwrites it.
You can remove the whole list of lowercase headers, ecm_generate_headers
generates it for you from the uppercase ones.
And then just install with the contents of that variable. *after* the call to
ecm_generate_headers, not before ;)
add_library (KF5TextEditor ${ktexteditor_LIB_SRCS}
${KTEXTEDITOR_PUBLIC_HEADERS})
Why pass headers to add_library?
target_link_libraries(KF5TextEditor LINK_PUBLIC KF5::Parts
LINK_PRIVATE KF5::I18n
Qt5::Script
KF5::Archive
KF5::GuiAddons
KF5::I18n
KF5::IconThemes
KF5::ItemViews
KF5::KCMUtils
KF5::KIOFileWidgets
KF5::Notifications
KF5::Parts
KF5::PrintUtils
KF5::SonnetCore)
Are you sure that all of these should be private? The ones that provide
classes that appear in the public API should be under LINK_PUBLIC.
set( katepart_PART_UI
)
unused, remove.
I tested the grafting, works fine.
--
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: KTextEditor Frameworks question
On Tuesday 07 January 2014 19:57:56 Christoph Cullmann wrote:
Hi,
I just tried to fix the naming issues.
Does that try here look better
http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git
I see a ${FooBar_HEADERS} in src/CMakeLists.txt which is used but not set,
should be removed.
Right ;)
src/include/CMakeList.txt is the one calling ecm_generate_headers, but in a
strange way: it sets KTEXTEDITOR_PUBLIC_HEADERS which was already set,
so it overwrites it.
You can remove the whole list of lowercase headers, ecm_generate_headers
generates it for you from the uppercase ones.
And then just install with the contents of that variable. *after* the call to
ecm_generate_headers, not before ;)
Yeah, I guess I was confused here, much easier.
add_library (KF5TextEditor ${ktexteditor_LIB_SRCS}
${KTEXTEDITOR_PUBLIC_HEADERS})
Why pass headers to add_library?
Just for automoc, without that, I get stuff like:
Linking CXX shared library libKF5TextEditor.so
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::scrollColumns(int)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:522:
undefined reference to
`KTextEditor::View::horizontalScrollPositionChanged(KTextEditor::View*)'
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::scrollPos(KTextEditor::Cursor, bool, bool)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:489:
undefined reference to
`KTextEditor::View::verticalScrollPositionChanged(KTextEditor::View*,
KTextEditor::Cursor const)'
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::updateCursor(KTextEditor::Cursor const, bool, bool, bool)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:1942:
undefined reference to
`KTextEditor::View::cursorPositionChanged(KTextEditor::View*,
KTextEditor::Cursor const)'
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::editEnd(int, int, bool)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:3449:
undefined reference to `KTextEditor::View::selectionChanged(KTextEditor::View*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::updateDocName()':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:3712:
undefined reference to
`KTextEditor::Document::documentNameChanged(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::slotCompleted()':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:4935:
undefined reference to
`KTextEditor::Document::documentSavedOrUploaded(KTextEditor::Document*, bool)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::createView(QWidget*, KTextEditor::MainWindow*)':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:290:
undefined reference to
`KTextEditor::Document::viewCreated(KTextEditor::Document*, KTextEditor::View*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::~KateDocument()':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:237:
undefined reference to
`KTextEditor::Document::aboutToClose(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::~KateDocument()':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:237:
undefined reference to
`KTextEditor::Document::aboutToClose(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::setModified(bool)':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:2515:
undefined reference to
`KTextEditor::Document::modifiedChanged(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::setReadWrite(bool)':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:2501:
undefined reference to
`KTextEditor::Document::readWriteChanged(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::editEnd()':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:844:
undefined reference to
`KTextEditor::Document::textChanged(KTextEditor::Document*)'
CMakeFiles/KF5TextEditor.dir/document/katedocument.cpp.o: In function
`KateDocument::editInsertText(int, int, QString const)':
/home/cullmann/local/kf5/src/ktexteditor/src/document/katedocument.cpp:1024:
undefined reference to
`KTextEditor::Document::textInserted(KTextEditor::Document*, KTextEditor::Range
const)'
target_link_libraries(KF5TextEditor LINK_PUBLIC KF5::Parts
LINK_PRIVATE KF5::I18n
Qt5::Script
KF5::Archive
KF5::GuiAddons
KF5::I18n
Re: KTextEditor Frameworks question
add_library (KF5TextEditor ${ktexteditor_LIB_SRCS}
${KTEXTEDITOR_PUBLIC_HEADERS})
Why pass headers to add_library?
Just for automoc, without that, I get stuff like:
Linking CXX shared library libKF5TextEditor.so
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::scrollColumns(int)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:522:
undefined reference to
`KTextEditor::View::horizontalScrollPositionChanged(KTextEditor::View*)'
Hmm. I think this comes from the .h and the .cpp files not being in the same
dir. Automoc doesn't like it, and I don't like it very much either ;)
It makes navigation from .h to .cpp harder, depending on the IDE/tools used.
Why not bring them together?
The old reason for include/ktexteditor/*.h (being able to include
ktexteditor/file.h from the cpp files) no longer applies,
ecm_generate_headers takes care of generating local lowercase forwarding
headers when used with PREFIX as you do.
Is it ok then to request moving or are there other constraints, too?
Seems fine to me, go ahead.
The checklist for new frameworks can be extracted from
http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
which gives:
* make new repo using script (done, in your case)
* run astyle-kdelibs (requires some patching, so I can do it if you want)
* adjust kde-build-metadata
* get the job set up on build.kde.org (Ben or Aurélien)
* ensure green ;)
* add to bugs.kde.org (d_ed: how?)
* add to reviewboard.kde.org (sysadmin request I suppose)
Any wiki page where I add this list? Maybe it should go at the end of the list
from definition of done in
http://community.kde.org/Frameworks/Epics/Splitting_kdelibs ?
Seems to me that this is the only useful thing left from that wiki page, which
we can otherwise delete, no?
I guess I shall add all required frameworks to the
KF5TextEditorConfig.cmake.in, too, or?
Yes.
--
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: KTextEditor Frameworks question
add_library (KF5TextEditor ${ktexteditor_LIB_SRCS}
${KTEXTEDITOR_PUBLIC_HEADERS})
Why pass headers to add_library?
Just for automoc, without that, I get stuff like:
Linking CXX shared library libKF5TextEditor.so
CMakeFiles/KF5TextEditor.dir/view/kateviewinternal.cpp.o: In function
`KateViewInternal::scrollColumns(int)':
/home/cullmann/local/kf5/src/ktexteditor/src/view/kateviewinternal.cpp:522:
undefined reference to
`KTextEditor::View::horizontalScrollPositionChanged(KTextEditor::View*)'
Hmm. I think this comes from the .h and the .cpp files not being in the same
dir. Automoc doesn't like it, and I don't like it very much either ;)
It makes navigation from .h to .cpp harder, depending on the IDE/tools used.
Why not bring them together?
The old reason for include/ktexteditor/*.h (being able to include
ktexteditor/file.h from the cpp files) no longer applies,
ecm_generate_headers takes care of generating local lowercase forwarding
headers when used with PREFIX as you do.
Hmm, yeah, thats true, can take a try at that after the other stuff is settled.
Is it ok then to request moving or are there other constraints, too?
Seems fine to me, go ahead.
The checklist for new frameworks can be extracted from
http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
which gives:
* make new repo using script (done, in your case)
;)
* run astyle-kdelibs (requires some patching, so I can do it if you want)
Sure, that would be nice.
* adjust kde-build-metadata
I guess I can give that a try.
KTextEditor looks like tier4?
Should I add a yaml file toplevel, too, containing that?
* get the job set up on build.kde.org (Ben or Aurélien)
* ensure green ;)
* add to bugs.kde.org (d_ed: how?)
* add to reviewboard.kde.org (sysadmin request I suppose)
I guess I can request that more or less as sysadmin ticket together with repo
move?
Any wiki page where I add this list? Maybe it should go at the end of the
list
from definition of done in
http://community.kde.org/Frameworks/Epics/Splitting_kdelibs ?
Seems to me that this is the only useful thing left from that wiki page,
which
we can otherwise delete, no?
I guess I shall add all required frameworks to the
KF5TextEditorConfig.cmake.in, too, or?
Yes.
Ok, will do so.
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
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 20:55:19 Christoph Cullmann wrote: * run astyle-kdelibs (requires some patching, so I can do it if you want) Sure, that would be nice. OK. Can you give a quick look at http://www.davidfaure.fr/2014/ktexteditor-astyled.diff and give me a green light? No need to check every line - just need an OK for the big switch from 2 to 4 spaces and especially checking if it's ok to reindent test files for autotests... (see the very first one in the diff) Yeah, 2 = 4, all right, wanted that anyway since long. Only the autotests/input stuff should be best left untouched. That is no source in that case only input for tests, and yeah, I guess they won't like that. * adjust kde-build-metadata I guess I can give that a try. KTextEditor looks like tier4? No, tier3. It's a lib that provides API, not an integration plugin. Hmm, but it installs a kpart, too, is that still ok? Should I add a yaml file toplevel, too, containing that? Yes. Ok * get the job set up on build.kde.org (Ben or Aurélien) * ensure green ;) * add to bugs.kde.org (d_ed: how?) * add to reviewboard.kde.org (sysadmin request I suppose) I guess I can request that more or less as sysadmin ticket together with repo move? I guess too. Ok, will do so after kde-build-metadata + yaml file is done (and your stuff is there) Thanks 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
Re: KTextEditor Frameworks question
On Tuesday 07 January 2014 21:12:39 Christoph Cullmann wrote: Yeah, 2 = 4, all right, wanted that anyway since long. Only the autotests/input stuff should be best left untouched. That is no source in that case only input for tests, and yeah, I guess they won't like that. OK, reverted that subdir, and committed. It's a lib that provides API, not an integration plugin. Hmm, but it installs a kpart, too, is that still ok? Sure. This doesn't change the basic rule: Provide non-deprecated API - tier1/2/3. -- 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: KTextEditor Frameworks question
Am Dienstag, 7. Januar 2014, 19:57:56 schrieb Christoph Cullmann: Hi, I just tried to fix the naming issues. Does that try here look better http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git If yes, I would ask sysadmin to move to framworks, if that is ok and remove the stuff in frameworks branch of kate.git. Greetings Christoph - Ursprüngliche Mail - (snip) Something's still wrong in case I'm not mistaken: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/cmake/KF5TextEditor/KF5TextEditorTargets.cmake 49:add_library(KF5::KF5TextEditor SHARED IMPORTED) he KF5 suffix should be dropped, no? I'd fix myself but atm I don't know where that magic line is generated from. Cheers -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
Am Dienstag, 7. Januar 2014, 21:20:40 schrieb Kevin Funk:
Am Dienstag, 7. Januar 2014, 19:57:56 schrieb Christoph Cullmann:
Hi,
I just tried to fix the naming issues.
Does that try here look better
http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git
If yes, I would ask sysadmin to move to framworks, if that is ok and
remove
the stuff in frameworks branch of kate.git.
Greetings
Christoph
- Ursprüngliche Mail -
(snip)
Something's still wrong in case I'm not mistaken:
/home/krf/devel/install/kf5/lib/x86_64-linux-
gnu/cmake/KF5TextEditor/KF5TextEditorTargets.cmake
49:add_library(KF5::KF5TextEditor SHARED IMPORTED)
he KF5 suffix should be dropped, no?
I'd fix myself but atm I don't know where that magic line is generated from.
Cheers
Ah. Something like that should fix it:
set_target_properties(KF5ItemViews PROPERTIES
VERSION ${KITEMVIEWS_VERSION_STRING}
SOVERSION ${KITEMVIEWS_SOVERSION}
EXPORT_NAME ItemViews)
'EXPORT_NAME' seems important.
Greets
--
Kevin Funk
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
Fixed :P - Ursprüngliche Mail - Am Dienstag, 7. Januar 2014, 19:57:56 schrieb Christoph Cullmann: Hi, I just tried to fix the naming issues. Does that try here look better http://quickgit.kde.org/?p=scratch%2Fcullmann%2Fktexteditor.git If yes, I would ask sysadmin to move to framworks, if that is ok and remove the stuff in frameworks branch of kate.git. Greetings Christoph - Ursprüngliche Mail - (snip) Something's still wrong in case I'm not mistaken: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/cmake/KF5TextEditor/KF5TextEditorTargets.cmake 49:add_library(KF5::KF5TextEditor SHARED IMPORTED) he KF5 suffix should be dropped, no? I'd fix myself but atm I don't know where that magic line is generated from. Cheers -- Kevin Funk -- - 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
Re: KTextEditor Frameworks question
On Monday 06 January 2014 08:36:14 Christoph Cullmann wrote: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? Yes, you can just try it, see the instructions in that initial commit :-) -- 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: KTextEditor Frameworks question
I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. 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
Re: KTextEditor Frameworks question
Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann: I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tue, Jan 7, 2014 at 3:03 AM, Kevin Funk k...@gmx.de wrote: Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann: I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Yes, it makes sense. When I created those we didn't do it like that in KF5 yet, this changed over time. Feel free to change it :). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: On Saturday 04 January 2014 19:18:56 Christoph Cullmann wrote: Hi, I cleanup the frameworks branch in kate.git to only have libktexteditor lib and the KTextEditor/ktexteditor includes to be installed as public API. Now, for 5.x, if others port over, like KDevelop, is it a good idea to keep the ktexteditor parts in kate.git, together with the applications, or shall that be split again into a khtml like framework? We want to make separate releases of the 3 major products: frameworks, apps and workspace. So libs that are used by workspace and apps, should be in frameworks. For libs that are only used by apps I guess they can either be in apps or in frameworks. So IMHO the question is: is there a chance the KDE workspace will need it? Of course the other question is: do you want to make it available as a framework for non-KDE developers to use in Qt applications? If the answer is yes to either of these questions, then you need to split it out into a framework. I am not sure if workspace apps will require it, but I doubt it, given an plain text editor is nothing the average application needs, guess only stuff like KDevelop/Kile/... will depend on it. I think it gets used in workspace. Try KRunner and enter desktop console. Though I don't know what it uses in the implementation and that code is not yet ported. Cheers Martin 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: KTextEditor Frameworks question
On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: On Saturday 04 January 2014 19:18:56 Christoph Cullmann wrote: Hi, I cleanup the frameworks branch in kate.git to only have libktexteditor lib and the KTextEditor/ktexteditor includes to be installed as public API. Now, for 5.x, if others port over, like KDevelop, is it a good idea to keep the ktexteditor parts in kate.git, together with the applications, or shall that be split again into a khtml like framework? We want to make separate releases of the 3 major products: frameworks, apps and workspace. So libs that are used by workspace and apps, should be in frameworks. For libs that are only used by apps I guess they can either be in apps or in frameworks. So IMHO the question is: is there a chance the KDE workspace will need it? Of course the other question is: do you want to make it available as a framework for non-KDE developers to use in Qt applications? If the answer is yes to either of these questions, then you need to split it out into a framework. I am not sure if workspace apps will require it, but I doubt it, given an plain text editor is nothing the average application needs, guess only stuff like KDevelop/Kile/... will depend on it. I think it gets used in workspace. Try KRunner and enter desktop console. Though I don't know what it uses in the implementation and that code is not yet ported. I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) 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
Re: KTextEditor Frameworks question
On Saturday 04 January 2014 19:18:56 Christoph Cullmann wrote: Hi, I cleanup the frameworks branch in kate.git to only have libktexteditor lib and the KTextEditor/ktexteditor includes to be installed as public API. Now, for 5.x, if others port over, like KDevelop, is it a good idea to keep the ktexteditor parts in kate.git, together with the applications, or shall that be split again into a khtml like framework? We want to make separate releases of the 3 major products: frameworks, apps and workspace. So libs that are used by workspace and apps, should be in frameworks. For libs that are only used by apps I guess they can either be in apps or in frameworks. So IMHO the question is: is there a chance the KDE workspace will need it? Of course the other question is: do you want to make it available as a framework for non-KDE developers to use in Qt applications? If the answer is yes to either of these questions, then you need to split it out into a framework. I am not sure if workspace apps will require it, but I doubt it, given an plain text editor is nothing the average application needs, guess only stuff like KDevelop/Kile/... will depend on it. To make the KTextEditor stuff available to a broader developer base would on the other side be nice. What would be required to have the ktexteditor stuff be frameworks ready? 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
Re: KTextEditor Frameworks question
On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: What would be required to have the ktexteditor stuff be frameworks ready? Using all the cmake stuff from other frameworks ;) I just updated and moved the framework template we had in kdelibs to kdeexamples/framework-template. You can use this to generate the entire directory structure if you want. -- 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: KTextEditor Frameworks question
On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: What would be required to have the ktexteditor stuff be frameworks ready? Using all the cmake stuff from other frameworks ;) I just updated and moved the framework template we had in kdelibs to kdeexamples/framework-template. You can use this to generate the entire directory structure if you want. Ok, that shall be not really a problem, given I have already the autotests in the right dir and only ktexteditor = src is needed. Given I have no tests ;) Still, what would be the appropriate way to split the kate.git without loosing the history. Or is the idea for such that it just starts from day zero and history is just in kate.git? 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
Re: KTextEditor Frameworks question
On Saturday 04 January 2014 22:40:13 Christoph Cullmann wrote: On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: What would be required to have the ktexteditor stuff be frameworks ready? Using all the cmake stuff from other frameworks ;) I just updated and moved the framework template we had in kdelibs to kdeexamples/framework-template. You can use this to generate the entire directory structure if you want. Ok, that shall be not really a problem, given I have already the autotests in the right dir and only ktexteditor = src is needed. This is about the contents of the CMakeLists.txt files too. You should port to ecm_generate_headers if you don't use it yet (you can use my script for that, kde-dev-scripts/kf5/install_forwarding_headers.pl) and compare the cmake stuff with e.g. kcoreaddons or the template. Still, what would be the appropriate way to split the kate.git without loosing the history. Do it just like we did for kdelibs: new repo, old history available via grafting. See kde-dev-scripts/frameworks/split_out_frameworks.sh (change the for loop, obviously - you don't need a loop at all, if you have only one repo to split out). Maybe don't even run the script, just run the commands one by one, to adapt them to your directory structure. Once you have the clean new repo, you'll need to talk to sysadmin for uploading it. -- 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: KTextEditor Frameworks question
On Saturday 04 January 2014 22:40:13 Christoph Cullmann wrote: On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: What would be required to have the ktexteditor stuff be frameworks ready? Using all the cmake stuff from other frameworks ;) I just updated and moved the framework template we had in kdelibs to kdeexamples/framework-template. You can use this to generate the entire directory structure if you want. Ok, that shall be not really a problem, given I have already the autotests in the right dir and only ktexteditor = src is needed. This is about the contents of the CMakeLists.txt files too. You should port to ecm_generate_headers if you don't use it yet (you can use my script for that, kde-dev-scripts/kf5/install_forwarding_headers.pl) and compare the cmake stuff with e.g. kcoreaddons or the template. Yeah, I did notice, we already have stolen most of that tricks in kate.git, including the use of ecm_generate_headers, its only hidden a bit more deep inside the ktexteditor/include structure. Still, what would be the appropriate way to split the kate.git without loosing the history. Do it just like we did for kdelibs: new repo, old history available via grafting. See kde-dev-scripts/frameworks/split_out_frameworks.sh (change the for loop, obviously - you don't need a loop at all, if you have only one repo to split out). Maybe don't even run the script, just run the commands one by one, to adapt them to your directory structure. Once you have the clean new repo, you'll need to talk to sysadmin for uploading it. I see, must then take a look at that ;) Greetings Thanks for all the hints 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
