Re: KCoreAddons forward headers
On Friday 27 December 2013 19:36:57 Aleix Pol wrote: Hi, Here's a patch adding CamelCase headers to KCoreAddons (attached). If we agree that it's the proper way of doing it, I'll proceed to do it on the rest of modules. Looks good to me. I like the fact that we can't forget to add forwarding headers like before - if we do, the lowercase header isn't installed either, so we'll notice faster :) I mean, a single operation is needed to install a new header, instead of two, one of which I always forgot. Hmm, does it really install the normal headers, too? I use it now in kate.git/ktexteditor/include/CMakelists.txt and need still to install the normal headers manually. 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
Frameworks Performance Question
-- - 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: Frameworks Performance Question
On Sun, Dec 29, 2013 at 08:07:38PM +0100, Christoph Cullmann wrote: if I play around with Kate on KF5, it laggs like hell the whole time. I tried to profile, but guess I am stuck a bit. How did you profile? I'd recommend using 'perf', it's pretty simple to use: - perf record ./kate - perf report Yeah, but it gives me just the same, that seemingly most time is spend in the reparseConfig stuff triggered inside the style ;) Which is somehow fishy for me, will try with other style and/or cleanup my config ;) 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: Frameworks Performance Question
On Sunday 29 December 2013 20:07:38 Christoph Cullmann wrote: Hi, if I play around with Kate on KF5, it laggs like hell the whole time. I tried to profile, but guess I am stuck a bit. #10 0x73fbeaa0 in KConfig::reparseConfiguration (this=0x688130) at /home/cullmann/local/kf5/src/frameworks/kconfig/src/core/kconfig.cpp:633 #11 0x7fffe5bad6b7 in KStyle::styleHint (this=0x658da0, hint=QStyle::SH_Widget_ShareActivation, option=0x0, widget=0x9f2050, returnData=0x0) at Yep, every call to styleHint() calls reparseConfiguration(), which is crazy. Yep, thought so that this is unwanted. For Kate on KF5 that means, it close to completely unusable, as any real redraw crawls away, would be nice to have this fixed before TP1, else it makes a bad impression about KF5 performance ;) 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: Frameworks Performance Question
On 12/30/2013 06:50 PM, David Faure wrote: On Monday 30 December 2013 17:20:23 Hugo Pereira Da Costa wrote: Indeed oxygen (@KDE4) was using: connect( KGlobalSettings::self(), SIGNAL(kdisplayPaletteChanged()), this, SLOT(globalPaletteChanged()) ); Interesting, so every style had to do this, rather than KStyle doing it centrally. No no: in KDE4, oxygen was not inheriting from KStyle but QCommonStyle. In KF5 it is inheriting again from the (much cleaned-up) KStyle class. So that I'm all for moving it (or any KF5 equivalent) to KStyle. (just not the way it is done now ;)) Shall we keep the same idea for KF5 or move it up to KStyle? I guess globalPaletteChanged() was in oxygen, but the reparsing done inside kglobalsettings made things work in kstyle too. yes. But should be avoided. I'll look into it a bot (but Alex might now better). In the meanwhile, I would just comment out the reparsing (which in turn would imply that configuration changes would only apply to newly started applciations, but I guess that's better than having unresponsive applications ...) Oppinions ? I think a quick revert would be nice, to get some usable state again ;) 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: What are the plans with CamelCase includes?
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 that's not it, it lowercases individual parts explicitely. In fact if we only use a camelcase header, the CMakeLists.txt code is even simpler because the INSTALL(DIRECTORY) line will install both kinds of headers. Which removes the need for the KCoreAddons_HEADERS variable altogether. See attached patch. Aleix, any objections? I'll script this over all modules, if not. I think the reasoning might have been: so that people can include kcoreaddons/krandom.h. But I'm not sure we even want to allow that. It breaks the whole idea that the install dir is transparent to the apps, the idea of compile-time errors (header not found) when not linking to the appropriate lib, and of course it will break when we move stuff around for kf6. Well, we can't physically prevent people from writing #include KCoreAddons/krandom.h or KCoreAddons/KRandom, but the fact that the first one looks weird will at least reduce the chances of people doing that :) 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? 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: What are the plans with CamelCase includes?
- 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. The answer is: yes, if we put both under the framework name. If the framework is called KTextEditor, then this would lead to include/KF5/KTextEditor/KTextEditor/View include/KF5/KTextEditor/ktexteditor/view.h The benefit of that is that when an app forgets to link to KTextEditor, [which adds include/KF5/KTextEditor to the include path] the includes won't work. With the current solution, they will still work, which is inconsistent with non-namespaced headers. I already set things up this way for KIO, which has both namespaced and non- namespaced headers. include/KF5/KIOCore/KIO/ListJob include/KF5/KIOCore/kio/listjob.h Note the difference between the framework name (KIOCore) and the namespace (KIO), so it looks like it makes more sense here than when writing KTextEditor/KTextEditor - but that's just because your framework name matches your namespace name :-) What do you think? Yeah, that sounds sane enough, even if in my case it would look duplicated ;) But the benefit of not found headers if wrong link flags is really nice! 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
KDE4Support Headers
Hi, KDE4Support installs still stuff like kmimetype.h in the KF5 directory, shall it not better install all its compat headers in some KDE4Support prefix to avoid that one can use them without using KF4::KDE4Support? 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: KF5 include problems on the build.kde.org?
Hi,
I am currently struggling to have the KF5 port of Okteta not only build
locally (what it does fine), but also on KDE's build server:
could anybody hint to me why on the build server the file KLocalizedString is
not found for include on building of the static lib kastencoretestio:
I have similar problems with kate on build.kde.org, here it builds, locally,
with a fresh usr/build/src dir,
there it fails unable to find KXMLGUIClient header.
http://build.kde.org/view/Unstable/job/kate_frameworks_qt5/90/console
From http://build.kde.org/job/okteta_master_qt5/8/console :
--- 8 ---
13:23:17
/srv/jenkins/workspace/okteta_master_qt5/libs/kasten/core/tests/testdocumentfileloadthread.cpp:28:28:
fatal error: KLocalizedString: No such file or directory
--- 8 ---
libs/kasten/core/tests/CMakeLists.txt has this:
--- 8 ---
set( kastencoretestio_LIB_SRCS
testdocumentfileloadthread.cpp
[...]
)
add_library( kastencoretestio STATIC ${kastencoretestio_LIB_SRCS} )
target_link_libraries( kastencoretestio LINK_PUBLIC Qt5::Core )
target_link_libraries( kastencoretestio LINK_PRIVATE KF5::I18n
KF5::CoreAddons
Qt5::Core )
--- 8 ---
Locally I see no problem with the problem, and the setup seems proper:
The file KLocalizedString is inside the KI18n include dir as expected, and
also the KDE4 variant is outside the used includes dirs.
$ ls /home/koder/System/kf5/include/KF5/KI18n
ki18n_export.h KLocalizedString klocalizedstring.h KuitMarkup
kuitmarkup.h
KuitSetup kuitsetup.h
$ find /usr/include/ -name KLocalizedString
/usr/include/KDE/KLocalizedString
$ VERBOSE=1 make
[ 0%] Building CXX object
libs/kasten/core/tests/CMakeFiles/kastencoretestio.dir/testdocumentfileloadthread.cpp.o
cd
/home/koder/Kode/kdegit/KDE/kdesdk/build.debug/okteta.kf5/libs/kasten/core/tests
/usr/bin/c++ -DKCOREADDONS_LIB -DQT_CORE_LIB -
DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_NO_CAST_FROM_ASCII -
DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_USE_QSTRINGBUILDER -
D_BSD_SOURCE -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -
std=c++0x -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-
subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -
DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -
Werror=return-type -fvisibility=hidden -fvisibility-inlines-hidden -Wall -
std=c++0x -fno-rtti -g3 -fno-inline -fPIC -
I/home/koder/Kode/kdegit/KDE/kdesdk/build.debug/okteta.kf5/libs/kasten/core/tests
-I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/tests -
I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/entity -
I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/document -
I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/io -
I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/io/filesystem
-I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/system -
I/home/koder/Kode/kdegit/KDE/kdesdk/build.debug/okteta.kf5/libs/kasten/core/tests/..
-I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/tests/../..
-
I/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/tests/.. -
isystem /home/koder/Kode/qt/qt5/qtbase/include -isystem
/home/koder/Kode/qt/qt5/qtbase/include/QtCore -isystem
/home/koder/Kode/qt/qt5/qtbase/mkspecs/linux-g++ -
I/home/koder/System/kf5/include/KF5/KI18n
-I/home/koder/System/kf5/include/KF5
-I/home/koder/System/kf5/include/KF5/KCoreAddons-o
CMakeFiles/kastencoretestio.dir/testdocumentfileloadthread.cpp.o -c
/home/koder/Kode/kdegit/KDE/kdesdk/okteta.kf5/libs/kasten/core/tests/testdocumentfileloadthread.cpp
It is especially strange because with other libs that also include
KLocalizedString there is no problem before in the same build. E.g.
oktetacore
has in core/CMakeLists.txt:
--- 8 ---
add_library( ${oktetacore_LIB} SHARED ${oktetacore_LIB_OBJS} )
target_link_libraries( ${oktetacore_LIB} LINK_PUBLIC Qt5::Core )
target_link_libraries( ${oktetacore_LIB} LINK_PRIVATE
KF5::I18n
KF5::KDE4Support
KF5::Codecs #needed for codecs
)
--- 8 ---
and you can see in the log
--- 8 ---
13:23:20 [ 24%] Built target oktetacore
--- 8 ---
What could be different on the buildserver? What is wrong in the
CMakeLists.txt perhaps?
And does Okteta (branch: kf5-port) build for you locally?
Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- 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
KTextEditor Frameworks question
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? 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. 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. 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
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
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
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
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.
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
KF5
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
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: Jenkins build became unstable: ktexteditor_master_qt5 #20
Hi, we will take a look to the the 1-2 GUI related tests stable, seems to have some timing issues :/ Greetings Christoph - Ursprüngliche Mail - See http://build.kde.org/job/ktexteditor_master_qt5/20/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- - 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: kate5 won't build with latest ktexteditor
Hi, build.kde.org says it builds, perhaps your ktexteditor.git is too old ;) Greetings Christoph - Ursprüngliche Mail - I have been unable to build kate5 for several days /var/git/kate5/addons/kate/project/kateprojectpluginview.cpp: In constructor 'KateProjectPluginView::KateProjectPluginView(KateProjectPlugin*, KTextEditor::MainWindow*)': /var/git/kate5/addons/kate/project/kateprojectpluginview.cpp:55:175: error: no matching function for call to 'KTextEditor::MainWindow::createToolView(KateProjectPlugin*, QLatin1String, KTextEditor::MainWindow::ToolViewPosition, QPixmap, QString)' m_toolView = m_mainWindow-createToolView (m_plugin, QLatin1String(kateproject), KTextEditor::MainWindow::Left, SmallIcon(QLatin1String(project-open)), i18n(Projects)); ^ /var/git/kate5/addons/kate/project/kateprojectpluginview.cpp:55:175: note: candidate is: In file included from /var/git/kate5/addons/kate/project/kateprojectplugin.h:28:0, from /var/git/kate5/addons/kate/project/kateprojectpluginview.h:24, from /var/git/kate5/addons/kate/project/kateprojectpluginview.cpp:21: /opt/qt5/include/KF5/KTextEditor/ktexteditor/mainwindow.h:218:14: note: QWidget* KTextEditor::MainWindow::createToolView(KTextEditor::ApplicationPlugin*, const QString, KTextEditor::MainWindow::ToolViewPosition, const QIcon, const QString) QWidget *createToolView(KTextEditor::ApplicationPlugin *plugin, const QString identifier, KTextEditor::MainWindow::ToolViewPosition pos, const QIcon icon, const QString text); ^ /opt/qt5/include/KF5/KTextEditor/ktexteditor/mainwindow.h:218:14: note: no known conversion for argument 1 from 'KateProjectPlugin*' to 'KTextEditor::ApplicationPlugin*' /var/git/kate5/addons/kate/project/kateprojectpluginview.cpp:56:191: error: no matching function for call to 'KTextEditor::MainWindow::createToolView(KateProjectPlugin*, QLatin1String, KTextEditor::MainWindow::ToolViewPosition, QPixmap, QString)' m_toolInfoView = m_mainWindow-createToolView (m_plugin, QLatin1String(kateprojectinfo), KTextEditor::MainWindow::Bottom, SmallIcon(QLatin1String(view-choose)), i18n(Current Project)); ^ and /var/git/kate5/kate/filetree/katefiletree.cpp: In member function 'void KateFileTree::slotPrintDocument()': /var/git/kate5/kate/filetree/katefiletree.cpp:569:8: error: 'class KTextEditor::Document' has no member named 'print' doc-print(); ^ I am using gcc-4.8.2 Am I missing an update to ktexteditor? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- - 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: Review Request 115197: Allow compiling KTextEditor on Windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115197/#review47934 --- ++ for platformsdefs, still no idea why we need winsock, thought, need to look at that. - Christoph Cullmann On Jan. 21, 2014, 10:21 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115197/ --- (Updated Jan. 21, 2014, 10:21 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Allow compiling KTextEditor on Windows Diffs - src/CMakeLists.txt 761ec5ce08035ce801997e207e4f3871dfa8bd21 src/syntax/katesyntaxdocument.cpp b92e07e367ecbef938f2fa184b5f92633aa4ce92 src/utils/templateinterface.cpp 74e965efd0cc98b69f839cd20b7af4bf219d797b Diff: https://git.reviewboard.kde.org/r/115197/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115197: Allow compiling KTextEditor on Windows
On Jan. 21, 2014, 10:24 p.m., Christoph Cullmann wrote: ++ for platformsdefs, still no idea why we need winsock, thought, need to look at that. Alexander Richardson wrote: gethostname is called, I am not familiar enough with the code to say whether that is necessary I see, will fix that, thanks for the hint. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115197/#review47934 --- On Jan. 21, 2014, 10:21 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115197/ --- (Updated Jan. 21, 2014, 10:21 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Allow compiling KTextEditor on Windows Diffs - src/CMakeLists.txt 761ec5ce08035ce801997e207e4f3871dfa8bd21 src/syntax/katesyntaxdocument.cpp b92e07e367ecbef938f2fa184b5f92633aa4ce92 src/utils/templateinterface.cpp 74e965efd0cc98b69f839cd20b7af4bf219d797b Diff: https://git.reviewboard.kde.org/r/115197/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review47962 --- Think that will make porting easier and avoids boiler plate code - Christoph Cullmann On Jan. 21, 2014, 11:36 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Jan. 21, 2014, 11:36 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp f24006b Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kate (frameworks) build failure
Hi,
in ktexteditor/document.h is:
// our main baseclass of the KTextEditor::Document
#include KParts/ReadWritePart
perhaps you need to cleanup your local include dirs ;)
Greetings
Christoph
- Ursprüngliche Mail -
Hello,
looks like building kate (frameworks branch) fails:
In file included from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/kwrite.h:25:0,
from /home/stefano/pkgbuild/kf5/kate-
git/src/kate/kwrite/main.cpp:21:
/opt/kf5/include/KF5/KTextEditor/ktexteditor/document.h:122:1: error:
expected
class-name before ‘{’ token
{
^
The problem seems to be that KTextEditor::Document derives from
KParts::ReadWritePart, but readwritepart.h (where KParts::ReadWritePart is
defined) is not pulled in by any header file. I think readwritepart.h should
be included somewhere.
Sorry if this is my fault.
Thanks,
Stefano
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- 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: Review Request 115262: Split Mainpage.dox up
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115262/#review48146 --- Ship it! Dominik our doxygen guy thinks its ok ;) - Christoph Cullmann On Jan. 23, 2014, 4:09 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115262/ --- (Updated Jan. 23, 2014, 4:09 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- This matches up with the new kapidox scripts. This module was more complex than the others, hence the RR. Split Mainpage.dox up The front page content goes in README.md. Other pages are now in separate files under docs/. It would be nice to convert some or all of the documentation pages to markdown, so they can be easily read without running them through doxygen first. Also includes the commit: Remove the lines about the following classes from apidox group defs doxygen actually puts the class list *above* the description, not below it. Diffs - Mainpage.dox 515d78af3e2babe155314b995f17955e6cacf65f README.md 82de5a260065959520f1558334d362d6ad16e167 docs/apidocs-groups.dox PRE-CREATION docs/coding-guidelines.dox PRE-CREATION docs/design.dox PRE-CREATION docs/howto.dox PRE-CREATION docs/porting.dox PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115262/diff/ Testing --- All the old pages are still accessible from the main page when generating the documentation. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failed in Jenkins: kde4support_master_qt5 #32
Hi, I think the problem is the -std=iso9899:1990 in our KDECompilerSettings.cmake, that causes at least this error on my machine locally. (openSUSE 13.1, gcc 4.8.1) Without that, the configure checks work correct and we have the right HAVE_* stuff set. Is there some known issue with that compiler or did build.kde.org change? That line wasn't touched since some months. Greetings Christoph - Ursprüngliche Mail - See http://build.kde.org/job/kde4support_master_qt5/32/changes Changes: [agateau] Move api doc images to docs/pics -- - 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: Build failed in Jenkins: kde4support_master_qt5 #32
On Fri, Jan 24, 2014 at 8:36 AM, Christoph Cullmann cullm...@absint.com wrote: Hi, I think the problem is the -std=iso9899:1990 in our KDECompilerSettings.cmake, that causes at least this error on my machine locally. (openSUSE 13.1, gcc 4.8.1) Without that, the configure checks work correct and we have the right HAVE_* stuff set. Is there some known issue with that compiler or did build.kde.org change? That line wasn't touched since some months. There has been no changes in regards to the compiler, etc. on build.kde.org in the past few weeks. The only thing that could have changed would be the version of CMake - as we follow the 'next' branch, so this could be a CMake regression. That would make sense, too. kjs has similar issues here (like an other guy reported already on frameworks-devel) 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: Build failed in Jenkins: kde4support_master_qt5 #32
I recreated my build directories and now I'm hitting it too. I guess it a matter of time that it spreads to the rest of who are building kde4support... I tried with cmake 2.8.12.1 and today's master. It seems to be this change: https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/8b055d7f229d6596cf15d045b85ec937f8e2abe8 Could it be, that now, as we use add_definitions in that file before the C/CXX FLAGS are set again, we loose these defines? 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: Review Request 115292: Do Configure Checks in the Correct Language
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115292/#review48216 --- Patch fixes the issue for me here, think perhaps the same is needed for kjs. - Christoph Cullmann On Jan. 24, 2014, 1:55 p.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115292/ --- (Updated Jan. 24, 2014, 1:55 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kde4support Description --- A recent change in ECM revealed an issue with ConfigureChecks.cmake, where the check_symbol_exist calls would use the C compiler (with CFLAGS) and the compilation would happen in C++ (with CXXFLAGS). This change ports all checks to CXX where possible. Diffs - src/ConfigureChecks.cmake 7c8951f Diff: https://git.reviewboard.kde.org/r/115292/diff/ Testing --- 1. Refreshed builds for ECM and KDE4Support, both building OK 2. $ grep HAVE_GETADDRINFO src/config-network.h #define HAVE_GETADDRINFO 1 Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failed in Jenkins: kde4support_master_qt5 #32
Hmm, see
https://git.reviewboard.kde.org/r/115292/
that fixes it for me ;)
- Ursprüngliche Mail -
On 24/01/14 13:30, Alex Merry wrote:
On 24/01/14 13:22, Christoph Cullmann wrote:
I recreated my build directories and now I'm hitting it too. I guess it a
matter of time that it spreads to the rest of who are building
kde4support...
I tried with cmake 2.8.12.1 and today's master.
It seems to be this change:
https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/8b055d7f229d6596cf15d045b85ec937f8e2abe8
Could it be, that now, as we use add_definitions in that file before the
C/CXX FLAGS are
set again, we loose these defines?
If it does, that's a bug in CMake, as we only ever append to
CMAKE_CXX_FLAGS.
Ah, found the issue. The problem *was* with that commit, but the issue
was that we no longer define _KDE4_PLATFORM_DEFINITIONS, and
kde4support/src/ConfigureChecks.cmake has, on line 20,
set(CMAKE_REQUIRED_DEFINITIONS ${_KDE4_PLATFORM_DEFINITIONS})
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- 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: Review Request 115293: Statusbar: double click on INSERT/OVERWRITE label toggles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115293/#review48231 --- Ship it! It is ok that way, perhaps I shall set an empty icon for the not handled case, will look at that after you pushed it. - Christoph Cullmann On Jan. 24, 2014, 4:06 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115293/ --- (Updated Jan. 24, 2014, 4:06 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- As discussed in the office. Additionally doubleclick on line/column label opens GoToLine Plus: statusbar: add whatsThis Diffs - src/view/katestatusbar.cpp 3a581ffd0b952d191cd0f8b004dcc6a0744a17ec src/view/katestatusbar.h 4c209c6484ef2ca2a1dc58cd453ec3b2ab572c0f .gitignore 2d96ba3156393aad5d1b03d9d8e17d267d84 Diff: https://git.reviewboard.kde.org/r/115293/diff/ Testing --- yes, including behaviour in vi mode Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115392: Fix compilation with clang
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115392/#review48574 --- Ship it! Ship It! - Christoph Cullmann On Jan. 29, 2014, 10:46 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115392/ --- (Updated Jan. 29, 2014, 10:46 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Fix compilation with clang Clang ignores the implicit conversion operators with const return type. Diffs - src/buffer/katetextrange.h fda415f71d3942c35169d33882d43df4a2baf27e src/include/ktexteditor/movingcursor.h 8783c390bfe4144b663eb234562ffa300fdc8e11 src/include/ktexteditor/movingrange.h 49200799dec08f07e5c1e7d01de6ef1d468a9a6b Diff: https://git.reviewboard.kde.org/r/115392/diff/ Testing --- compiles now with clang 3.3, didn't before Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: X11 usage in kdeinit/kinit.cpp
- Ursprüngliche Mail - wrapper.cpp assumes there is a DISPLAY env variable and even if not it's set to :0. Can't we detect that we're not on X11 simply from the fact that DISPLAY is not set? No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). Hi, wouldn't be then the assumption: if WAYLAND_DISPLAY is defined, use wayland, else use X11 work? Or would it make any sense to have that defined (in a normal user desktop) but still use X11 as default? 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: KF5 alpha2
On Wednesday 12 March 2014 12:21:36 Christoph Cullmann wrote: David Faure wrote: On Wednesday 05 March 2014 19:29:34 Michael Palimaka wrote: Hi, KTextEditor is listed as tier 3, but is missing from this (and previous) releases. It is not part of the KF 5.0 release, it targets 5.1. Hi, is there any reason for that? Would delay us from releasing some KF 5 port of Kate for common consumption after the KF 5.0 release. No idea, please ask the KTextEditor maintainers. Wait, that's you... I thought this was a request from you, because it wouldn't be ready for 5.0? I'm confused. What made me think so is that it's under 5.1 in the wiki page http://community.kde.org/Frameworks/Epics and that it still has many SIC changes TODO there. So I thought this was intentional. If it's not, let's fix that quickly. Hi, I think we can get all SIC incompatible changes done before 28th, I and Dominik went over most stuff last week to finalize the TODO and beside removing a bit more stuff from the public API no other large changes are on the TODO list for the 5.0 release. (will rework http://community.kde.org/Frameworks/Epics/KTextEditor, too) Seems I did just misunderstand for which release we are scheduled, sorry :/ Given we get all SIC stuff done until 28th, any other blocking issues like other changes required for 5.0? 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: Releasing Deprecated modules and Tier 4 Definition
Hello, Thanks for the feedback! Adding kde-promo in CC since it might have implications on future communication. On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote: Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) [...] 2) Release the deprecated content as a separate product [...] 3) Roll all the deprecated modules into KDE4Support [...] 4) Announce the deprecated modules will only be released three times [...] That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. So let's pick the following cocktail: 1, 2 and 4. That means we immediately move khtml and kde4support out of KDE Frameworks (to be widely advertised) and into a KDE Porting Aids product (to be advertised only to existing KDE developers). Ben, I think you're going to hate me for that, but we learn as we progress... That means we're moving ASAP khtml and kde4support repositories out of the frameworks group of the projects tree into a new portingaids group. We'll also announce at beta time the second product, and that we aim for making only three releases out of it, coordinated with KDE Frameworks releases as to give people time to port away from it. Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? Hi, perhaps I am wrong, but is not kross as good candidate to be added to this list, too? 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: KF5 alpha2
On Wednesday 12 March 2014 12:21:36 Christoph Cullmann wrote: David Faure wrote: On Wednesday 05 March 2014 19:29:34 Michael Palimaka wrote: Hi, KTextEditor is listed as tier 3, but is missing from this (and previous) releases. It is not part of the KF 5.0 release, it targets 5.1. Hi, is there any reason for that? Would delay us from releasing some KF 5 port of Kate for common consumption after the KF 5.0 release. No idea, please ask the KTextEditor maintainers. Wait, that's you... I thought this was a request from you, because it wouldn't be ready for 5.0? I'm confused. What made me think so is that it's under 5.1 in the wiki page http://community.kde.org/Frameworks/Epics and that it still has many SIC changes TODO there. So I thought this was intentional. If it's not, let's fix that quickly. Hi, most SIC stuff now done. Some small things remain and are either done until 28th or they will stay in that shape for KF 5.x, which would be ok, too. Removed some completely unrealistic items like split out the highlighting stuff, which is a long term goal and can be done SC/BC later. I would appreciate any hint on what is needed more to have ktexteditor in the KF 5.0 release as I think it would give applications like Kate/KDevelop/Kile/... the possibility to have KF 5.0 ports available. Kate/KWrite itself is really KF 5 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: Review Request 116994: Use KPluginLoader::findPlugin and QLibrary instead of KLibrary
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116994/#review53815 --- Ship it! Ship It! - Christoph Cullmann On March 23, 2014, 2:25 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116994/ --- (Updated March 23, 2014, 2:25 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Use KPluginLoader::findPlugin and QLibrary instead of KLibrary Diffs - src/utils/templateinterface.cpp 241f1a36c5d0c3b6b3cccb914513b28d7c60898a Diff: https://git.reviewboard.kde.org/r/116994/diff/ Testing --- Builds, installs. Cannot test the loading due to a lack of ported pimlibs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failed in Jenkins: ktexteditor_master_qt5 #335
See http://build.kde.org/job/ktexteditor_master_qt5/335/changes Changes: [cullmann] extendedattribute folded, default style == normal is default snip CMake Error at /srv/jenkins/install/linux/x86_64/g++/shared/general/cmake/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:65 (find_package): Could not find a configuration file for package KF5Notifications that is compatible with requested version 4.97.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/knotifications/inst/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake, version: 4.96.0 Call Stack (most recent call first): /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kparts/inst/lib64/cmake/KF5Parts/KF5PartsConfig.cmake:69 (find_dependency) CMakeLists.txt:41 (find_package) Hmm, somehow that is unrelated to my code work, or? I didn't touch the CMake find parts :/ 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: Build failed in Jenkins: ktexteditor_master_qt5 #335
On 25/03/14 19:52, Christoph Cullmann wrote: CMake Error at /srv/jenkins/install/linux/x86_64/g++/shared/general/cmake/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:65 (find_package): Could not find a configuration file for package KF5Notifications that is compatible with requested version 4.97.0. The following configuration files were considered but not accepted: /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/knotifications/inst/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake, version: 4.96.0 Call Stack (most recent call first): /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kparts/inst/lib64/cmake/KF5Parts/KF5PartsConfig.cmake:69 (find_dependency) CMakeLists.txt:41 (find_package) Hmm, somehow that is unrelated to my code work, or? I didn't touch the CMake find parts :/ Occasionally, Jenkins manages to grab a really old version of a repo when building on a slave that hasn't had an update in the meantime. I'm not sure why (it might be related to anongit). This happened to KNotifications, then things that depended on it broke. ;) Somehow, looking at some errors on build.kde.org I am happy I use a homebrew buildfarm at work ;) Thanks for rebuild trigger! Looks my changes are OK, don't want to mess stuff up that short before the SIC freeze during my last minute fixes. 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: Build failed in Jenkins: ktexteditor_master_qt5 #335
Occasionally, Jenkins manages to grab a really old version of a repo when building on a slave that hasn't had an update in the meantime. I'm not sure why (it might be related to anongit). This happened to KNotifications, then things that depended on it broke. ;) Somehow, looking at some errors on build.kde.org I am happy I use a homebrew buildfarm at work ;) Thanks for rebuild trigger! Looks my changes are OK, don't want to mess stuff up that short before the SIC freeze during my last minute fixes. Speaking of... can you resolve the ktexteditor entry at http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/KDE4_References ? It probably just needs a documentation update. Alex Done I don't really understand the KTextEditor: kde4 is mentioned in a changelog comment, as I no longer find a changelog file ;) 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: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)
On Tue, Apr 1, 2014 at 9:23 PM, Dominik Haumann dhaum...@kde.org wrote: On Monday, March 31, 2014 23:24:09 Albert Astals Cid wrote: El Dilluns, 31 de març de 2014, a les 22:34:21, Dominik Haumann va escriure: On Monday 31 March 2014 17:27:33 Ben Cooksley wrote: On Mon, Mar 31, 2014 at 5:38 AM, Gregor Mi codeminis...@publicstatic.de Ok. Any idea about the qtenginio Could not read from remote repository problem? Do I need special access rights? Or is it possible that the qtenginio repo is offline? This is because the upstream Qt developers have added yet another module to Qt, which wasn't included in our mirror of Qt. Our mirror has now been adjusted to include this new mirror. This is a process which has to be done each time they add a new module. For those wondering why, we maintain a mirror of Qt on the anongit network to ensure that it is always available - at least in the past people have had issues accessing the Gitorious repositories. Hi Ben, then thanks again for fixing it (again). Question though: Could this error be caught earlier, maybe automated? Honestly we should stop suggesting people to build their own Qt and just use 5.2 distro packages. Heh, that would be the most trivial and a working solution. I've no idea if this will actually end up the case, but won't KF 5.1 end up depending on Qt 5.3? ie. this problem is going to come up again once KF 5.0 is released. Looking at the qt list, it might be, that they reconsider to merge all gits into one again which will make tracking easy once again after 5.3. 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: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)
I've no idea if this will actually end up the case, but won't KF 5.1 end up depending on Qt 5.3? ie. this problem is going to come up again once KF 5.0 is released. Looking at the qt list, it might be, that they reconsider to merge all gits into one again which will make tracking easy once again after 5.3. Ignore me, I hate april fools .P 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: Review Request 117695: change where dynamic replace tabs is performed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117695/#review58172 --- Ship it! I think that is a better way to handle it than the old code was :) insertText should not modify the text more than needed. - Christoph Cullmann On May 3, 2014, 12:57 a.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117695/ --- (Updated May 3, 2014, 12:57 a.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- This makes typeChars handle replacing tabs by spaces, instead of insertText. The rationale is that insertText is often called programatically, and the caller should be able to rely on the text he requests to be inserted is actually inserted, and not changed on-the-fly. Examples for where the previous solution caused problems are KDevelop (the codegen) and kte-collaborative. I'm not sure what the code I removed was doing (heh). It looks like it is supposed to advance to the next indent level if the current indent level is odd, but that still works after removing it. The obvious user-visible change here is that tabs in pasted text will no longer be replaced. But since I always found this behaviour undesirable anyways, I did not bother to replicate it. I will instead wait for people to yell at me for removing it. ;) Diffs - autotests/src/katedocument_test.h cff61d0 autotests/src/katedocument_test.cpp f3eef18 src/document/katedocument.h 83cc031 src/document/katedocument.cpp 546d3e6 Diff: https://git.reviewboard.kde.org/r/117695/diff/ Testing --- Just some quick manual tests, it seems to still work as intended. Thanks, Sven Brauch ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118484: Move katepart into a kf5/parts subdir of plugin dir
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118484/#review59032 --- Ship it! If that is the way to do it in KF5, I am OK ;) Thanks for taking care! - Christoph Cullmann On June 2, 2014, 9:19 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118484/ --- (Updated June 2, 2014, 9:19 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Move katepart into a kf5/parts subdir of plugin dir This makes sure the file is properly versioned. Diffs - src/part/CMakeLists.txt b4d1fe9e4c60f5fbf30fb9315ea134faebcaec9c src/part/katepart.desktop fa760e9d1257c1d613d4fc59e7798202cde25fdd Diff: https://git.reviewboard.kde.org/r/118484/diff/ Testing --- kwrite still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KAction Warning
Hi, perhaps that is a stupid question, but last time I read up in the docs, they didn't help me: KatePart spits out a lot of: kate(15138)/(default) KXMLGUIFactoryPrivate::saveDefaultActionProperties: Shortcut for KAction smart_newline Insert Smart Newline set with QShortcut::setShortcut()! See KAction documentation. kate(15138)/(default) KXMLGUIFactoryPrivate::saveDefaultActionProperties: Shortcut for KAction tools_indent Indent set with QShortcut::setShortcut()! See KAction documentation. ... How to fix that? 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: Review Request 119377: Add highlighting commands
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/#review62738 --- Think that is a nice thingy for people working on the own HL. What would be nice before you add that: rename the file from katehighlightreload to katehighlightingcmds or so, as it contains more than just the reload, and later might get more. - Christoph Cullmann On July 20, 2014, 12:29 p.m., Christoph Rüßler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/ --- (Updated July 20, 2014, 12:29 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add the commands 'reload-highlighting' and 'edit-highlighting' to the developer console. This is a KF5 port of a review request I posted some weeks ago (https://git.reviewboard.kde.org/r/118616/). The highlighting definition for the highlighting currently in use gets opened when entering the command 'edit-highlighting', and the complete set of highlighting definition gets reloaded on entering 'reload-highlighting' (takes a second or two on my machine). I thought about a simple caching mechanism based on the mtime of the highlighting definitions, too, but it seems they only get loaded in KateSyntaxDocument::setIdentifier where there is no access to the respective KateHighlighting instance. Caching would require some kind of rewriting that code, then. If you think it’s worth it I could give it a try. Diffs - src/utils/kateglobal.cpp 27128529dde920dad92cc06e11f8a687a8880599 src/CMakeLists.txt 0862cff2c2f60c0fc89a9f6a2b427425ac18349c src/syntax/katehighlight.h 22d75b9e344d20f9dcbe1e9b94aebe169394c2db src/syntax/katehighlight.cpp b82354e5c1f41e9a843f4478332fe62f7cad95ea src/syntax/katehighlightreload.h PRE-CREATION src/syntax/katehighlightreload.cpp PRE-CREATION src/syntax/katesyntaxmanager.h 568154154149e7c649ec2c023c7e43d44ad07ea4 src/syntax/katesyntaxmanager.cpp ebc86f3835c5bf41e01ed9d0bf7f1f2bde65ca46 Diff: https://git.reviewboard.kde.org/r/119377/diff/ Testing --- Using the two new commands on my development machine yields the desired results. Thanks, Christoph Rüßler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119377: Add highlighting commands
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/#review62977 --- Ship it! Ship It! - Christoph Cullmann On July 23, 2014, 3:08 p.m., Christoph Rüßler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/ --- (Updated July 23, 2014, 3:08 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add the commands 'reload-highlighting' and 'edit-highlighting' to the developer console. This is a KF5 port of a review request I posted some weeks ago (https://git.reviewboard.kde.org/r/118616/). The highlighting definition for the highlighting currently in use gets opened when entering the command 'edit-highlighting', and the complete set of highlighting definition gets reloaded on entering 'reload-highlighting' (takes a second or two on my machine). I thought about a simple caching mechanism based on the mtime of the highlighting definitions, too, but it seems they only get loaded in KateSyntaxDocument::setIdentifier where there is no access to the respective KateHighlighting instance. Caching would require some kind of rewriting that code, then. If you think it’s worth it I could give it a try. Diffs - src/CMakeLists.txt 2ec52b25dddacdbedf16b908c36fd71f11a889ae src/syntax/katehighlight.h 5c34fb0c3747e72137484fa369a0804f87fb4c43 src/syntax/katehighlight.cpp 05b787cc9c16b2fa6c8ac82c7e809bb0ab8f5835 src/syntax/katehighlightingcmds.h PRE-CREATION src/syntax/katehighlightingcmds.cpp PRE-CREATION src/syntax/katesyntaxmanager.h 568154154149e7c649ec2c023c7e43d44ad07ea4 src/syntax/katesyntaxmanager.cpp ebc86f3835c5bf41e01ed9d0bf7f1f2bde65ca46 src/utils/kateglobal.cpp 5a1cc220e8800a0e4e9203432ea5ba5f72921c21 Diff: https://git.reviewboard.kde.org/r/119377/diff/ Testing --- Using the two new commands on my development machine yields the desired results. Thanks, Christoph Rüßler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Questions about KDE 4.14 and later + branches
Leaving KDE/4.14 the last kdelibs 4.x based branch and just killing master and switching it over to what is now in frameworks? That sounds wrong. I'd just merge frameworks to master and kill frameworks. Ok ;) I just did the merge frameworks = master and adjusted the build meta info (at least I hope). Do I need to do anything else in addition? for kate.git master is now KF5 based, last Qt4 variant will be 4.14. 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: KAction Warning
On Saturday 19 July 2014 23:57:15 Christoph Cullmann wrote: Hi, perhaps that is a stupid question, but last time I read up in the docs, they didn't help me: KatePart spits out a lot of: kate(15138)/(default) KXMLGUIFactoryPrivate::saveDefaultActionProperties: Shortcut for KAction smart_newline Insert Smart Newline set with QShortcut::setShortcut()! See KAction documentation. kate(15138)/(default) KXMLGUIFactoryPrivate::saveDefaultActionProperties: Shortcut for KAction tools_indent Indent set with QShortcut::setShortcut()! See KAction documentation. ... How to fix that? Warning improved in http://commits.kde.org/kxmlgui/11cb423c0de0090ea398efa5d1bccd2a39e97987 - use KAction::setDefaultShortcut(s) Thanks, will fix the wrong usages ;) 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: KAction Warning
Hi,
for me it looks like KStandardAction itself triggers a lot of these warnings.
I thought about adding a workaround like the already existing:
if (pAction parent parent-inherits(KActionCollection)) {
QMetaObject::invokeMethod(parent, addAction, Q_ARG(QString,
pAction-objectName()), Q_ARG(QAction *, pAction));
}
just with setShortcut(s), but that won't work for the cases with parent 0.
Any idea?
Greetings
Christoph
- Ursprüngliche Mail -
On Saturday 19 July 2014 23:57:15 Christoph Cullmann wrote:
Hi,
perhaps that is a stupid question, but last time I read up in the docs,
they
didn't help me:
KatePart spits out a lot of:
kate(15138)/(default) KXMLGUIFactoryPrivate::saveDefaultActionProperties:
Shortcut for KAction smart_newline Insert Smart Newline set with
QShortcut::setShortcut()! See KAction documentation. kate(15138)/(default)
KXMLGUIFactoryPrivate::saveDefaultActionProperties: Shortcut for KAction
tools_indent Indent set with QShortcut::setShortcut()! See KAction
documentation. ...
How to fix that?
Warning improved in
http://commits.kde.org/kxmlgui/11cb423c0de0090ea398efa5d1bccd2a39e97987
- use KAction::setDefaultShortcut(s)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on 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: Review Request 120062: KActionCollection::setDefaultShortcuts now makes the shortcut active too.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120062/#review65826 --- Looks like good idea. - Christoph Cullmann On Sept. 5, 2014, 8:39 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120062/ --- (Updated Sept. 5, 2014, 8:39 a.m.) Review request for KDE Frameworks, Christoph Cullmann, Kevin Ottens, Friedrich W. H. Kossebau, and Laurent Montel. Repository: kxmlgui Description --- This simplifies app development, which otherwise needs to write everything twice, like this: m_actFullScreen-setShortcut(Qt::Key_F11) collection-setDefaultShortcut(m_actFullScreen, Qt::Key_F11); Diffs - autotests/kactioncollectiontest.cpp 9047b32b3909371b42a9b26c79c5a58376a84783 src/kactioncollection.h 5dbc3c2ddd8f93af9874454d735ad2a237bf4afa src/kactioncollection.cpp 6c7af0ffeb7e874ea0bce8096abde5c7df41f2e5 Diff: https://git.reviewboard.kde.org/r/120062/diff/ Testing --- kactioncollectiontest now skips calling setShortcut if it's the same as the default, and still passes. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- (Updated Sept. 7, 2014, 8:44 a.m.) Review request for KDE Frameworks and David Faure. Changes --- Missed the showMenu action. Perhaps the same should be done for the setShortcuts call in the AutomaticAction constructor, but now at least kate/kwrite stdactions are really clean of warnings it seems. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs (updated) - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- (Updated Sept. 7, 2014, 11:33 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Diffs - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing --- Tested with Kate, removed the super verbose Added File... output for any opened file. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- (Updated Sept. 7, 2014, 1:29 p.m.) Review request for KDE Frameworks and David Faure. Summary (updated) - Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods Repository: kcoreaddons Description (updated) --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Guard available methods with same trick, will allow use in non-debug build of that output. Diffs (updated) - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing (updated) --- Tested with Kate, removed the super verbose Added File... output for any opened file. Available methods are gone in output, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- (Updated Sept. 8, 2014, 8:22 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Guard available methods with same trick, will allow use in non-debug build of that output. Diffs - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing --- Tested with Kate, removed the super verbose Added File... output for any opened file. Available methods are gone in output, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120099: RFC: UI-Files inside resources instead of filesystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120196: Find-Module to detect libgit2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindGIT2.rst PRE-CREATION find-modules/FindGIT2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
On Sept. 15, 2014, 3:15 p.m., Aleix Pol Gonzalez wrote: Shouldn't it be called FindLibGit2? Git2 and LibGit2 seem different things to me. I can rename it, but then it is inconsistent with most other FindXXX.cmake's, as they skip the lib prefix. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/#review66567 --- On Sept. 14, 2014, 10:19 a.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 14, 2014, 10:19 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindGIT2.rst PRE-CREATION find-modules/FindGIT2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
On Sept. 15, 2014, 3:15 p.m., Aleix Pol Gonzalez wrote: Shouldn't it be called FindLibGit2? Git2 and LibGit2 seem different things to me. Christoph Cullmann wrote: I can rename it, but then it is inconsistent with most other FindXXX.cmake's, as they skip the lib prefix. Aleix Pol Gonzalez wrote: I'm unsure it's inconsistent. The project is actually called libgit2, because it's a library that does git things: https://libgit2.github.com/ As an example, here's archlinux: https://www.archlinux.org/packages/extra/i686/git/ https://www.archlinux.org/packages/community/x86_64/libgit2/ And in general, archlinux doesn't prefix the lib for frameworks anyway: https://www.archlinux.org/packages/extra/x86_64/kcoreaddons/ Does that make sense? :) Ok, that seems to be reasonable, will change that, if Alex is ok with that, too ;=) Other remarks? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/#review66567 --- On Sept. 14, 2014, 10:19 a.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 14, 2014, 10:19 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindGIT2.rst PRE-CREATION find-modules/FindGIT2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
On Sept. 15, 2014, 3:15 p.m., Aleix Pol Gonzalez wrote: Shouldn't it be called FindLibGit2? Git2 and LibGit2 seem different things to me. Christoph Cullmann wrote: I can rename it, but then it is inconsistent with most other FindXXX.cmake's, as they skip the lib prefix. Aleix Pol Gonzalez wrote: I'm unsure it's inconsistent. The project is actually called libgit2, because it's a library that does git things: https://libgit2.github.com/ As an example, here's archlinux: https://www.archlinux.org/packages/extra/i686/git/ https://www.archlinux.org/packages/community/x86_64/libgit2/ And in general, archlinux doesn't prefix the lib for frameworks anyway: https://www.archlinux.org/packages/extra/x86_64/kcoreaddons/ Does that make sense? :) Christoph Cullmann wrote: Ok, that seems to be reasonable, will change that, if Alex is ok with that, too ;=) Other remarks? Btw., that rename would imply that the vars are LIBGIT2_... and the Target would be LibGit2::LibGit2, or? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/#review66567 --- On Sept. 14, 2014, 10:19 a.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 14, 2014, 10:19 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindGIT2.rst PRE-CREATION find-modules/FindGIT2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 15, 2014, 6:30 p.m.) Review request for KDE Frameworks and Alex Merry. Changes --- Rename to FindLibGit2 Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs (updated) - docs/find-module/FindLibGit2.rst PRE-CREATION find-modules/FindLibGit2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
On Sept. 15, 2014, 3:15 p.m., Aleix Pol Gonzalez wrote: Shouldn't it be called FindLibGit2? Git2 and LibGit2 seem different things to me. Christoph Cullmann wrote: I can rename it, but then it is inconsistent with most other FindXXX.cmake's, as they skip the lib prefix. Aleix Pol Gonzalez wrote: I'm unsure it's inconsistent. The project is actually called libgit2, because it's a library that does git things: https://libgit2.github.com/ As an example, here's archlinux: https://www.archlinux.org/packages/extra/i686/git/ https://www.archlinux.org/packages/community/x86_64/libgit2/ And in general, archlinux doesn't prefix the lib for frameworks anyway: https://www.archlinux.org/packages/extra/x86_64/kcoreaddons/ Does that make sense? :) Christoph Cullmann wrote: Ok, that seems to be reasonable, will change that, if Alex is ok with that, too ;=) Other remarks? Christoph Cullmann wrote: Btw., that rename would imply that the vars are LIBGIT2_... and the Target would be LibGit2::LibGit2, or? Aleix Pol Gonzalez wrote: Yes, +1 to that. Renamed, its ok? Need to retest it again, but in principle should work. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/#review66567 --- On Sept. 15, 2014, 6:30 p.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 15, 2014, 6:30 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindLibGit2.rst PRE-CREATION find-modules/FindLibGit2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 15, 2014, 6:56 p.m.) Review request for KDE Frameworks and Alex Merry. Changes --- Fixed stuff in comments ;) Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs (updated) - docs/find-module/FindLibGit2.rst PRE-CREATION find-modules/FindLibGit2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120196: Find-Module to detect libgit2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120196/ --- (Updated Sept. 15, 2014, 7:11 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Alex Merry. Repository: extra-cmake-modules Description --- Add a find module that allows to detect libgit2. Will be used by KTextEditor Kate. Will remove the copy in KTextEditor after this is merged. Diffs - docs/find-module/FindLibGit2.rst PRE-CREATION find-modules/FindLibGit2.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120196/diff/ Testing --- Tested with KTextEditor, version detection is here important, as libgit2 did change API a lot, seems to work on Linux, hope it works on Windows, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: changelog for KF 5.3
Here's what I wrote from the changes in git (the CHANGELOG keyword isn't used enough yet...) Please tell me about anything I missed. I am especially unsure about KTextEditor (so many changes!), KService (I guess a better description of the KPluginInfo changes could be useful) and plasma-framework (I didn't even try for that one). Hi, yeah, sorry :/ need to get used to CHANGELOG :/ Most stuff in KTextEditor is bugfixing, anyways, hope 5.3 will have lot less bugs than we had before :-) 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: Review Request 120099: RFC: UI-Files inside resources instead of filesystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- (Updated Oct. 5, 2014, 5:32 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120099: RFC: UI-Files inside resources instead of filesystem
On Oct. 5, 2014, 5:58 p.m., Christoph Feck wrote: Sorry for chiming in late, just noticed the commit. Any reason why the resource is checked first, not last? If the programmer decides to use the resource, the locateAll effectively turns into a locateNone. Not really friendly to administrators. Actually that is a big benefit in my eyes, if you ship software with compiled in resources, you don't want people mingling around with them, IMHO. E.g. in ktexteditor I could use this and be sure that no actions or stuff is missing only because some fixed ui file got placed in the right location. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/#review67966 --- On Oct. 5, 2014, 5:32 p.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- (Updated Oct. 5, 2014, 5:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120099: RFC: UI-Files inside resources instead of filesystem
On Oct. 5, 2014, 5:58 p.m., Christoph Feck wrote: Sorry for chiming in late, just noticed the commit. Any reason why the resource is checked first, not last? If the programmer decides to use the resource, the locateAll effectively turns into a locateNone. Not really friendly to administrators. Christoph Cullmann wrote: Actually that is a big benefit in my eyes, if you ship software with compiled in resources, you don't want people mingling around with them, IMHO. E.g. in ktexteditor I could use this and be sure that no actions or stuff is missing only because some fixed ui file got placed in the right location. Albert Astals Cid wrote: I agree with Christoph Feck, we should not disable such an important feature as locateAll, if you don't want locateAll don't use it, but don't break it with strange rules as LocateAll won't do locate all if your xmlgui is in your .rc file instead of the filesystem. ? I don't get that point, I don't break locateAll, the patch just changes the default lookup of setXMLFile, if the application/library author decides to put the ui file in a resource. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/#review67966 --- On Oct. 5, 2014, 5:32 p.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- (Updated Oct. 5, 2014, 5:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120099: RFC: UI-Files inside resources instead of filesystem
On Oct. 5, 2014, 5:58 p.m., Christoph Feck wrote: Sorry for chiming in late, just noticed the commit. Any reason why the resource is checked first, not last? If the programmer decides to use the resource, the locateAll effectively turns into a locateNone. Not really friendly to administrators. Christoph Cullmann wrote: Actually that is a big benefit in my eyes, if you ship software with compiled in resources, you don't want people mingling around with them, IMHO. E.g. in ktexteditor I could use this and be sure that no actions or stuff is missing only because some fixed ui file got placed in the right location. Albert Astals Cid wrote: I agree with Christoph Feck, we should not disable such an important feature as locateAll, if you don't want locateAll don't use it, but don't break it with strange rules as LocateAll won't do locate all if your xmlgui is in your .rc file instead of the filesystem. Christoph Cullmann wrote: ? I don't get that point, I don't break locateAll, the patch just changes the default lookup of setXMLFile, if the application/library author decides to put the ui file in a resource. Albert Astals Cid wrote: It does break setXMLFile behaviour, the code has a locateAll but now we're checking for the rc file before, so setXMLFile behaves differently on depending how you install/package your application. That's unexpected and i would say undesired, and even if it is desired, it is undocumented. Albert Astals Cid wrote: And it also probably breaks all kind of editing of toolbar by the user. That is true, you would need to call setLocalXMLFile, in addition, thats true :( I agree that this needs to be either fixed or documented, still I don't see the problem with the fact that the application/library author can enforce that the resource file is used. But as two people think it is an issue, I should fix it the way you say. Should I reverse the direction of the lookup then, to have it behind the current kxmlgui5/ but in front of the deprecated locations that warn? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/#review67966 --- On Oct. 5, 2014, 5:32 p.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- (Updated Oct. 5, 2014, 5:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120099: RFC: UI-Files inside resources instead of filesystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120099/ --- (Updated Oct. 7, 2014, 8:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kxmlgui Description --- Instead of installing them in the kxmlgui5 share prefix, install them in a kxmlgui5 prefix in resources. That will allow to test stuff without installing it first, as the resources will be found anyway. Still the I can edit it and have a copy in my writable datadir should work. Question is: is it possible with one kxmlgui prefix for the resource or is it better to swap that around like componentname/kxmlgui5/..? Diffs - src/kxmlguiclient.cpp e8170ad src/kxmlguifactory.cpp c4ad97b Diff: https://git.reviewboard.kde.org/r/120099/diff/ Testing --- Compiles if I package ui file in kate into resource, works. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Supporting MSVC2010 in ktexteditor framework
2014-11-05 9:58 GMT+02:00 Martin Graesslin mgraess...@kde.org: On Wednesday 05 November 2014 08:53:42 Mirko Boehm wrote: Hi, On 05 Nov 2014, at 04:33, Nicolás Alvarez nicolas.alva...@gmail.com wrote: So, I hereby propose making an exception and bumping the minimum compiler version *for ktexteditor only* to MSVC2012. Opinions? I propose to bump the required compiler versions across the board to compilers that fully 100% implement C++11. It is 2014 and C++14 is finalised. And we are a Free Software project and none of our compilers have any problems with that. I support this. I'm currently facing the problem that at some point we might want kwayland to become a framework to be able to be used in kwindowsystem. But the compiler requirements would not allow it, although it doesn't make any sense for the case of kwayland (nobody is going to use that on Windows). So in stead of adding one exception after the other, just go the full way and raise the requirement. The fact that we don't have a CI to test it just shows even more that we need to raise the minimum requirement. +1, we came to this conclusion when we discussed this issue at Randa (in the KDE SDK group), C++11 rules out MSVC 2010 and there is really no reason to keep backward compatibility. Hi, I think all frameworks should require the same level of C++ features, therefore either we patch ktexteditor to the same level back (which is no big issue I think, beside the unit tests, but thats fixable) or we raise the bar for all frameworks. 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: Review Request 120760: Fix bug #340212: incorrect soft-tabs alignment after beginning-of-line
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120760/#review70293 --- Ship it! I think the changes makes sense and the code looks ok. Perhaps you could add a comment to the eventuallyReplaceTabs function explaining what it does. Would make it later easier to understand. Perhaps even with some ref to bug . But it had no comment before, so that is no stopper and not your fault ;) - Christoph Cullmann On Nov. 12, 2014, 7:06 p.m., Michael Hansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120760/ --- (Updated Nov. 12, 2014, 7:06 p.m.) Review request for Kate, KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Fix for incorrect soft-tabs alignment after beginning-of-line, by taking the current cursor position into account when expanding tabs to spaces. This also now uses the indentation width rather than the tab width, as I see Tab Width as being the actual width of the \t character, and Indentation width as being the next alignment position for virtual indentation. This more closely matches other editors (e.g. vim) which have similar indentation control. Diffs - src/document/katedocument.h cc43d6ab033c3d5bcf5b90a18ef9c2dc78b220cf src/document/katedocument.cpp edcf7a430412d30ca2ed210465690bc8e2c42d5b Diff: https://git.reviewboard.kde.org/r/120760/diff/ Testing --- Typed the testcase in bug 340212 with various indent/tab width settings. Only Soft Tab mode is affected by this change. With Indent 4/Tab 4: int x; string y; boolz; With Indent 4/Tab 8: int x; string y; boolz; With Indent 8/Tab 8 (single [tab] on the first line): int x; string y; boolz; Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121160: Add libgit2 compile-time check for threads support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121160/#review70541 --- Ship it! Ship It! - Christoph Cullmann On Nov. 17, 2014, 8:11 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121160/ --- (Updated Nov. 17, 2014, 8:11 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add libgit2 compile-time check for threads support Diffs - CMakeLists.txt 5cace5fead7c80ede9fa82643426ab5a5e5a4035 src/test_libgit2_threads.c PRE-CREATION src/utils/kateglobal.cpp 6e3362802c213c914430a4775ab15e3515729474 Diff: https://git.reviewboard.kde.org/r/121160/diff/ Testing --- Should fix the CI failure. Compiles fine for me (with threads support) Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121263: Prevent API abuse of calling setters on temporary objects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/#review70996 --- I actually would prefer no such hack in the public headers. If that is just to make porting easier, you can use that locally as a patch until the kdevplatform code is cleaned up. - Christoph Cullmann On Nov. 27, 2014, 1:15 a.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/ --- (Updated Nov. 27, 2014, 1:15 a.m.) Review request for KDE Frameworks, Christoph Cullmann, Dominik Haumann, and Kevin Funk. Repository: ktexteditor Description --- In KDevelop we currently hit this often since our old class previously returned a reference for the start/end getters of range and cursor. With the help of C++11 ref qualifiers, we can detect that and let the compiler give the user an error message: error: cannot initialize object parameter of type 'KTextEditor::Cursor' with an expression of type 'KTextEditor::Cursor' documentRange().start().setColumn(42); ^~~ Yes, the error message is pretty bad. But better than nothing? We could also mark the overloads of these functions as explictily deleted, which would slightly improve the error message... Diffs - src/include/CMakeLists.txt 94b8e79e2f2b273ec344a963ba6ac81ec5a481c6 src/include/ktexteditor/cursor.h 4ebe38fc1bffb2dad02150884fd225fe3ca9e193 src/include/ktexteditor/global.h PRE-CREATION src/include/ktexteditor/range.h 1a2fc5b200c70364c3d99223e43a2ad6179055de Diff: https://git.reviewboard.kde.org/r/121263/diff/ Testing --- with the fixes to kdev's codebase, all of ktexteditor, kate and kdev* builds fine. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121263: Prevent API abuse of calling setters on temporary objects.
On Nov. 27, 2014, 7:29 a.m., Christoph Cullmann wrote: I actually would prefer no such hack in the public headers. If that is just to make porting easier, you can use that locally as a patch until the kdevplatform code is cleaned up. Milian Wolff wrote: I still don't get why you think this is a hack, or why it would be bad to have it in public headers. Any consumer of your API could shoot yourself in the foot... I must rephrase: I think, without any guard define, this is not even source compatible (even if the use might be in most cases an error). And with a guard define, this is a hack, as you need to turn it on, which most people won't do at all. It might have been a good idea to add to the API in KF 5.0, but as we missed that, its now too late, or? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/#review70996 --- On Nov. 27, 2014, 1:15 a.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/ --- (Updated Nov. 27, 2014, 1:15 a.m.) Review request for KDE Frameworks, Christoph Cullmann, Dominik Haumann, and Kevin Funk. Repository: ktexteditor Description --- In KDevelop we currently hit this often since our old class previously returned a reference for the start/end getters of range and cursor. With the help of C++11 ref qualifiers, we can detect that and let the compiler give the user an error message: error: cannot initialize object parameter of type 'KTextEditor::Cursor' with an expression of type 'KTextEditor::Cursor' documentRange().start().setColumn(42); ^~~ Yes, the error message is pretty bad. But better than nothing? We could also mark the overloads of these functions as explictily deleted, which would slightly improve the error message... Diffs - src/include/CMakeLists.txt 94b8e79e2f2b273ec344a963ba6ac81ec5a481c6 src/include/ktexteditor/cursor.h 4ebe38fc1bffb2dad02150884fd225fe3ca9e193 src/include/ktexteditor/global.h PRE-CREATION src/include/ktexteditor/range.h 1a2fc5b200c70364c3d99223e43a2ad6179055de Diff: https://git.reviewboard.kde.org/r/121263/diff/ Testing --- with the fixes to kdev's codebase, all of ktexteditor, kate and kdev* builds fine. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121263: Prevent API abuse of calling setters on temporary objects.
On Nov. 27, 2014, 7:29 a.m., Christoph Cullmann wrote: I actually would prefer no such hack in the public headers. If that is just to make porting easier, you can use that locally as a patch until the kdevplatform code is cleaned up. Milian Wolff wrote: I still don't get why you think this is a hack, or why it would be bad to have it in public headers. Any consumer of your API could shoot yourself in the foot... Christoph Cullmann wrote: I must rephrase: I think, without any guard define, this is not even source compatible (even if the use might be in most cases an error). And with a guard define, this is a hack, as you need to turn it on, which most people won't do at all. It might have been a good idea to add to the API in KF 5.0, but as we missed that, its now too late, or? Dominik Haumann wrote: @Milian: is it correct, that this is/was only an issue in KDevelop? As said, as that change is SIC and only on per define, which nobody will find anyway on their first try, I don't like to include that in the official headers. If I am mistaken and this is source and binary compatible, please reopen. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/#review70996 --- On Feb. 8, 2015, 2:42 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/ --- (Updated Feb. 8, 2015, 2:42 p.m.) Review request for KDE Frameworks, Christoph Cullmann, Dominik Haumann, and Kevin Funk. Repository: ktexteditor Description --- In KDevelop we currently hit this often since our old class previously returned a reference for the start/end getters of range and cursor. With the help of C++11 ref qualifiers, we can detect that and let the compiler give the user an error message: error: cannot initialize object parameter of type 'KTextEditor::Cursor' with an expression of type 'KTextEditor::Cursor' documentRange().start().setColumn(42); ^~~ Yes, the error message is pretty bad. But better than nothing? We could also mark the overloads of these functions as explictily deleted, which would slightly improve the error message... Diffs - src/include/CMakeLists.txt 94b8e79e2f2b273ec344a963ba6ac81ec5a481c6 src/include/ktexteditor/cursor.h 4ebe38fc1bffb2dad02150884fd225fe3ca9e193 src/include/ktexteditor/global.h PRE-CREATION src/include/ktexteditor/range.h 1a2fc5b200c70364c3d99223e43a2ad6179055de Diff: https://git.reviewboard.kde.org/r/121263/diff/ Testing --- with the fixes to kdev's codebase, all of ktexteditor, kate and kdev* builds fine. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: konsole fails to build on branch master
On Tuesday 06 January 2015 21:43:03 Marko Käning wrote: CMake Error at src/CMakeLists.txt:178 (install): install TARGETS given no LIBRARY DESTINATION for shared library target konsoleprivate. Again, please stop this spamming. Group the mails, they _all_ show the same error. And it's b/c INSTALL_TARGETS_DEFAULT_ARGS is empty on your machine, for some reason. Go figure out why before sending every compile error you encounter to all lists please. I think the problem is that it should be KF5_INSTALL_TARGETS_DEFAULT_ARGS, the prefix is missing in many cmake files. 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: OSX/CI: konsole fails to build on branch master
On Tuesday 06 January 2015 22:14:06 Marko Käning wrote: Hi Christoph, On 06 Jan 2015, at 22:10 , Christoph Cullmann cullm...@absint.com wrote: I think the problem is that it should be KF5_INSTALL_TARGETS_DEFAULT_ARGS, the prefix is missing in many cmake files. yep, now I do remember one of your commits from a few days back… So this is the same issue found in many projects then! This would mean, that it DOES make sense to report these issues?! It of course makes sense to report them, but not with one mail per project. They all have the same issue after all... Just patch all occurences and avoid sending mails for that, I did only patch the frameworks that I did try to build on the Mac. 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: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: Hi Christoph, I’ve found that these projects do not make use of KF5_INSTALL_TARGETS_DEFAULT_ARGS at the moment: - systemsettings - muon - rocs - libkdegames - kiten - cantor - kolourpaint - libkmahjongg See for details below in order of appearance. I figure this is only the beginning of it and more projects might turn up in the future. Is KF5_INSTALL_TARGETS_DEFAULT_ARGS even correct for non-frameworks projects? KF5_INSTALL_TARGETS_DEFAULT_ARGS's INCLUDES location points to $SOMETHING/KF5. KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems more appropriate. @Alex, please elaborate. Yeah, for non-framework repos, I am not sure of that, true. Greetings Christoph Thanks for taking care of these. Regards, Marko P.S.: I’ve tested locally to prepend KF5_” to INSTALL_TARGETS_DEFAULT_ARGS for project systemsettings only, which worked fine and made the project install successfully again here on my OSX/CI system. P.P.S.: I realised by now that there are no changes on the production branch, which probably means that there was some change in ECM or wherever provoking these issues... --- systemsettings: CMake Error at core/CMakeLists.txt:37 (install): install TARGETS given no LIBRARY DESTINATION for shared library target systemsettingsview”. --- muon: CMake Error at libmuon/notifiers/CMakeLists.txt:7 (install): install TARGETS given no LIBRARY DESTINATION for shared library target MuonNotifiers. CMake Error at libmuon/CMakeLists.txt:63 (install): install TARGETS given no LIBRARY DESTINATION for shared library target muonprivate”. --- rocs: CMake Error at libgraphtheory/CMakeLists.txt:106 (install): install TARGETS given no LIBRARY DESTINATION for shared library target rocsgraphtheory”. --- libkdegames: CMake Error at CMakeLists.txt:163 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KDEGames. CMake Error at CMakeLists.txt:222 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KDEGamesPrivate”. --- kiten: CMake Error at lib/CMakeLists.txt:37 (install): install TARGETS given no LIBRARY DESTINATION for shared library target kiten. --- cantor: CMake Error at src/lib/CMakeLists.txt:75 (install): install TARGETS given no LIBRARY DESTINATION for shared library target cantorlibs”. CMake Error at src/CMakeLists.txt:25 (install): install TARGETS given no LIBRARY DESTINATION for shared library target cantor_config. --- kolourpaint: CMake Error at CMakeLists.txt:579 (install): install TARGETS given no LIBRARY DESTINATION for shared library target kolourpaint_lgpl. --- libkmahjongg: CMake Error at CMakeLists.txt:64 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KMahjongglib. CMake Error at CMakeLists.txt:67 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KMahjongglib. --- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Kevin Funk | kf...@kde.org | http://kfunk.org -- - 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: Review Request 122498: Register with dbus to wake up KRun, and unregister then
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122498/#review76057 --- Ship it! I am still no sure, if that is the best way to go, but if it works around the current nasty bug, please commit and close the bug! Thanks for taking care of the patch. - Christoph Cullmann On Feb. 9, 2015, 11:04 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122498/ --- (Updated Feb. 9, 2015, 11:04 a.m.) Review request for Kate and KDE Frameworks. Repository: kate Description --- This is the patch from bug 339094. As it seemes there's no response/activity to that, I just put it here for proper review (and will commit on behalf of Liu Zhe obviously) as this is really annoying bug. Following is the description by Liu: Documentation of KToolInvocation (called by KRun when click a file in dolphin) said Multi means Always start a new service, wait until the service has registered with D-Bus. But when the second text file is opened, kate just starts a QApplication and waits, without registering with DBus. In KDE 4, the second instance of kate launchs an empty KApplication to do this job, but the author said it's too bad to register a service. Maybe we can register to make KService happy and unregister at once. Another problem is that the kate icon will jump quite a few seconds after clicking the second file. I thought the reason was KStartupInfo::appStarted() not called as it requires Q_WS_X11 macro, which is not defined in Qt 5. But the bug still exists after I fixed this. Diffs - CMakeLists.txt 408f502 config.h.cmake d15b78e kate/src/kateapp.cpp 4c26f33 kate/src/main.cpp 8852754 Diff: https://git.reviewboard.kde.org/r/122498/diff/ Testing --- Hrvoje confirmed in the bug report that this indeed fixes the issue. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
Hi,
I see why KDE_INSTALL_TARGETS_DEFAULT_ARGS and INSTALL_TARGETS_DEFAULT_ARGS
fail on Mac,
typo:
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS ${INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS ${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
endif(APPLE)
should be
# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS ${KDE_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS ${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
BUNDLE DESTINATION
${BUNDLE_INSTALL_DIR} )
endif(APPLE)
will patch that ;=)
- Ursprüngliche Mail -
Hi Alex,
Hi Ben,
Happy New Year, for a start! :)
On 07 Jan 2015, at 19:48 , Alex Merry alex.me...@kde.org wrote:
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote:
P.P.S.: I realised by now that there are no changes on the production
branch, which probably means that there was some change in ECM or wherever
provoking these issues...
I'm somewhat puzzled, as INSTALL_TARGET_DEFAULT_ARGS should still be set
(to
the same value as KDE_INSTALL_TARGET_DEFAULT_ARGS) unless you have set
KDE_INSTALL_DIRS_NO_DEPRECATED to some TRUE-ish value. If not, that's a
bug.
Hmmm...
Well, off-list I already had contacted Ben because of this issue. See this:
Begin forwarded message:
On 07 Jan 2015, at 09:12 , David Faure fa...@kde.org wrote:
KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which
seems more appropriate.
I think you're fully correct.
Thus I tried KDE_INSTALL_TARGETS_DEFAULT_ARGS for the non-KF5
“systemsettings”
project but it lead to the same error as the original
INSTALL_TARGETS_DEFAULT_ARGS
variable in my initial post.
Is this perhaps specific to the CI system?
So, I really wonder what’s going on here, as it doesn’t hit all projects!
kstars fails,
but marble - for instance - still builds fine without the need to mess with
these vars!
I can't find KDE_INSTALL_DIRS_NO_DEPRECATED in CMakeCache.txt of kstars at
all, so I assume
that it is not set.
Does this mean it IS a bug for kstars and all the other projects after
all?
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- 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: Review Request 123075: do not require X11 on Mac OS X
On March 20, 2015, 7:07 a.m., Martin Gräßlin wrote: as in other similar requests: -2 from my side Martin Gräßlin wrote: To extend: I think the way is wrong. If it now builds on MacOS the required is wrong. It should be an optional find_package properly ifdefed. Christoph Cullmann wrote: Actually, you don't want that it is optional as you really don't want that it ever is found on MacOS. If you install an XQuartz for legacy apps, it will be found, and you will have a completly mess as result ;=) Martin Gräßlin wrote: Christoph, that argument is wrong. The same would be the case with Windows and any other platform which optionally offers X11 (this includes Linux!). CMake can handle the situation quite well to disable an unwanted build dependency. If a user installs XLib headers (which is not the same as just installing XQuartz) we should expect the user to disable the cmake build option. That means that nobody will get a senseful build on Mac, if he doesn't disable that optional dependency. Thats the opposite of a normal optional dependency, that leads to missing features if not found but not complete mess if found. I tried to compile frameworks stuff on Mac, and IMHO, really, that makes it close to unusable, that you need to tweak each cmake call just to have something usable, if you have too much stuff installed. I never had to do that on Linux/Other Unices. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review9 --- On March 19, 2015, 10:59 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/ --- (Updated March 19, 2015, 10:59 p.m.) Review request for KDE Frameworks and Michael Palimaka. Repository: kdesu Description --- do not require X11 on Mac OS X Diffs - CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 Diff: https://git.reviewboard.kde.org/r/123075/diff/ Testing --- Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123075: do not require X11 on Mac OS X
On March 20, 2015, 7:07 a.m., Martin Gräßlin wrote: as in other similar requests: -2 from my side Martin Gräßlin wrote: To extend: I think the way is wrong. If it now builds on MacOS the required is wrong. It should be an optional find_package properly ifdefed. Actually, you don't want that it is optional as you really don't want that it ever is found on MacOS. If you install an XQuartz for legacy apps, it will be found, and you will have a completly mess as result ;=) - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review9 --- On March 19, 2015, 10:59 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/ --- (Updated March 19, 2015, 10:59 p.m.) Review request for KDE Frameworks and Michael Palimaka. Repository: kdesu Description --- do not require X11 on Mac OS X Diffs - CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 Diff: https://git.reviewboard.kde.org/r/123075/diff/ Testing --- Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123075: do not require X11 on Mac OS X
On March 20, 2015, 7:07 a.m., Martin Gräßlin wrote: as in other similar requests: -2 from my side Martin Gräßlin wrote: To extend: I think the way is wrong. If it now builds on MacOS the required is wrong. It should be an optional find_package properly ifdefed. Christoph Cullmann wrote: Actually, you don't want that it is optional as you really don't want that it ever is found on MacOS. If you install an XQuartz for legacy apps, it will be found, and you will have a completly mess as result ;=) Martin Gräßlin wrote: Christoph, that argument is wrong. The same would be the case with Windows and any other platform which optionally offers X11 (this includes Linux!). CMake can handle the situation quite well to disable an unwanted build dependency. If a user installs XLib headers (which is not the same as just installing XQuartz) we should expect the user to disable the cmake build option. Christoph Cullmann wrote: That means that nobody will get a senseful build on Mac, if he doesn't disable that optional dependency. Thats the opposite of a normal optional dependency, that leads to missing features if not found but not complete mess if found. I tried to compile frameworks stuff on Mac, and IMHO, really, that makes it close to unusable, that you need to tweak each cmake call just to have something usable, if you have too much stuff installed. I never had to do that on Linux/Other Unices. Martin Gräßlin wrote: That means that nobody will get a senseful build on Mac What since when is XLib as a build dependency available by default on OS X? Christoph Cullmann wrote: Actually, if you work with Frameworks there, you will install something over MacPorts or Homebrew, and yes, you will have XQuartz installed, to run some legacy apps and there is really no user understandable way to install XQuartz without its devel headers, the .dmg will just install everything, I was suprised myself that I have X devel headers just by installing an X-Server. My first workaround was just to deinstall XQuartz, later I started to tweak CMake options or do exactly the same fixes as above. And yes, I think, per default, without any magic options, frameworks should just build to a usable state. And I see 0 reason to ever have even an optional with x11 build of an frameworks application. But I might be wrong. Therefore I don't vote here or say ship it, just wanted to state my concerns ;=) Martin Gräßlin wrote: my concern is that we make our CMakeLists.txt way more complex (it's not the only framework which recently saw such a proposed change) and work around broken systems in our CMakeLists. That's something I do not want to see - if the downstream packaging sucks, it needs to be fixed there. We would tell the same to every Linux distribution. I do not want to see such OS specific changes go in as X11 is not OS specific - all operating systems we support in KDE can provide X11 and on all OS there are alternative windowing systems. What I don't want to see is something like: if (NOT APPLE AND NOT WINDOWS AND NOT LINUX_ANDROID AND NOT LINUX_UBUNTU_PHONE AND NOT LINUX_SAILFISH AND NOT LINUX_WEBOS AND NOT ... if we start with one platform, where do we end? Is adding the check for Apple OK and Windows not? We could wrap the X11 search in a own module that will not do anything on Apple, to avoid the if stuff. On the other side, even with the if, it still avoids that we have some combinations feasible in the frameworks, that we need will not test anyway, e.g. apple + X11. That avoids complexity, too. Actually I would be OK do have the same for WIN, too, yeah, still better than a code path that you can configure in, that actually will not work. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review9 --- On March 19, 2015, 10:59 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/ --- (Updated March 19, 2015, 10:59 p.m.) Review request for KDE Frameworks and Michael Palimaka. Repository: kdesu Description --- do not require X11 on Mac OS X Diffs - CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 Diff: https://git.reviewboard.kde.org/r/123075/diff/ Testing --- Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123075: do not require X11 on Mac OS X
On March 20, 2015, 7:07 a.m., Martin Gräßlin wrote: as in other similar requests: -2 from my side Martin Gräßlin wrote: To extend: I think the way is wrong. If it now builds on MacOS the required is wrong. It should be an optional find_package properly ifdefed. Christoph Cullmann wrote: Actually, you don't want that it is optional as you really don't want that it ever is found on MacOS. If you install an XQuartz for legacy apps, it will be found, and you will have a completly mess as result ;=) Martin Gräßlin wrote: Christoph, that argument is wrong. The same would be the case with Windows and any other platform which optionally offers X11 (this includes Linux!). CMake can handle the situation quite well to disable an unwanted build dependency. If a user installs XLib headers (which is not the same as just installing XQuartz) we should expect the user to disable the cmake build option. Christoph Cullmann wrote: That means that nobody will get a senseful build on Mac, if he doesn't disable that optional dependency. Thats the opposite of a normal optional dependency, that leads to missing features if not found but not complete mess if found. I tried to compile frameworks stuff on Mac, and IMHO, really, that makes it close to unusable, that you need to tweak each cmake call just to have something usable, if you have too much stuff installed. I never had to do that on Linux/Other Unices. Martin Gräßlin wrote: That means that nobody will get a senseful build on Mac What since when is XLib as a build dependency available by default on OS X? Actually, if you work with Frameworks there, you will install something over MacPorts or Homebrew, and yes, you will have XQuartz installed, to run some legacy apps and there is really no user understandable way to install XQuartz without its devel headers, the .dmg will just install everything, I was suprised myself that I have X devel headers just by installing an X-Server. My first workaround was just to deinstall XQuartz, later I started to tweak CMake options or do exactly the same fixes as above. And yes, I think, per default, without any magic options, frameworks should just build to a usable state. And I see 0 reason to ever have even an optional with x11 build of an frameworks application. But I might be wrong. Therefore I don't vote here or say ship it, just wanted to state my concerns ;=) - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review9 --- On March 19, 2015, 10:59 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/ --- (Updated March 19, 2015, 10:59 p.m.) Review request for KDE Frameworks and Michael Palimaka. Repository: kdesu Description --- do not require X11 on Mac OS X Diffs - CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 Diff: https://git.reviewboard.kde.org/r/123075/diff/ Testing --- Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122875: Fix KIconEngine::paint to handle different devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77222 --- Hi, this fixes the pixelation issues in the Kate document list (thought the project plugin tree view is still pixelated, guess need to take a look at the Kate code for that myself ;=) - Christoph Cullmann On March 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated March 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123677: Bring back use of KEncodingFileDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123677/#review80080 --- Ship it! Ship It! - Christoph Cullmann On May 7, 2015, 8:45 p.m., David Rosca wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123677/ --- (Updated May 7, 2015, 8:45 p.m.) Review request for Kate and KDE Frameworks. Bugs: 343255 https://bugs.kde.org/show_bug.cgi?id=343255 Repository: ktexteditor Description --- This reverts commits 6e57274917f146ac233f50fcb902e8f2569bbbd2 (document/katedocument.cpp) and 4ef4063a34314480287540a0a4f58127bd6523f2 (link to KIOFileWidgets). It does use native file dialogs now (not sure if it didn't at the time of that commit). And mainly this fixes regression from KDE4, it is now possible to change encoding of files again. Diffs - src/CMakeLists.txt 70c4d89 src/document/katedocument.cpp 4f66a47 Diff: https://git.reviewboard.kde.org/r/123677/diff/ Testing --- Save file dialogs are working fine and saving to different encoding works too. Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
Ok, they are not that obvious too me. Wouldn't it be possible to add something like maintainerManagesVersionOnItsOn=false to a file in all the frameworks (isn't there already a file in each frameworks for stuff like platforms, etc.?) and modify the release-scripts (David or anybody who knows these scripts) once so that these scripts check this variable. So if it's set to false and most current maintainer seem to prefer not to do version bumps on their own the release scripts would bump the version number and do all the stuff as they do now. If the variable was set to true these scripts wouldn't bump the version numbers and just use the version numbers as set by the maintainer? Or is this just naive thinking from my side that it's that easy? It would mean the end to the product frameworks we provide today. We would no longer release 60 addon libraries to Qt, but well maybe one month 20, the next one 40 and every one would have a different number of frameworks included. The versioning would be a complete mess: each framework having a different version number, some doing bug fix releases, some don't. What would it mean if I have KIO in 5.10 and KWindowSystem in 5.10? Is that from the same month or did KIO skip May and KWindowSystem the June release? Bug investigation would become close to impossible, just imagine asking the user to provide each of the versions of all dependencies of e.g. plasmashell. What is the message we give to the outside concerning release process and versioning? The best I can get from that is we have no clue what we are doing. And users are currently already complaining that there is no KDE anymore, but that there are now three different version numbers for frameworks, plasma and applications. If we go with each framework a different number they have a point if they say that one cannot follow that. Hi, as ktexteditor framework and kate maintainer, I think, too, that if we start to go that way, we will end in the version hell. ATM it is easy to track: Ok, I have a bug for KTextEditor 5.9, that means all frameworks used are at least 5.9, too. Its already hard enough to track for bugs on the application side: Ok, I have Kate from Applications 15.04 and it uses KF 5.9 ;=) That was much easier in the I have KDE 4.1.2 times, where all things were more or less fixed in their version and one number is all you need ;=) 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: How to port KGlobalSettings::fixedFont et. al?
Hi, http://doc.qt.io/qt-5/qfontdatabase.html#SystemFont-enum QFont QFontDatabase::systemFont(SystemFont type) or? - Ursprüngliche Mail - Hey all, as the subject says - how should KGlobalSettings::fixedFont and the like be ported? QFont(monospace)? Thanks -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- - 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: Review Request 124133: Add dedicated Version tab to KAboutApplicationDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124133/#review81596 --- +1 for the additional information. Btw., is there any way we would get that info submitted for bugs, too? (which is a different thingy, I know, just came to mind) - Christoph Cullmann On June 20, 2015, 4:30 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124133/ --- (Updated June 20, 2015, 4:30 a.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- This replaces the version information of the version and frameworks and moves it into a dedicated tab. In this tab the information is extended by the Qt version (which is equally relevant as e.g. the frameworks version) in both runtime and compile time. Also windowing system is added. This will become a useful information for KWin developers starting in Plasma 5.4 when users start to test things out and we need to know whether the window they experience the problem with is running on wayland or xwayland. Diffs - src/kaboutapplicationdialog.cpp 5eeea7711aa4f95a9cd4191d68ad330ef795caea Diff: https://git.reviewboard.kde.org/r/124133/diff/ Testing --- File Attachments New wayland, new X11, old X11 https://git.reviewboard.kde.org/media/uploaded/files/2015/06/20/b76ba6ae-b01c-4c6a-9248-29d39c652d83__snapshot_J11265.png Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [ktexteditor] src/utils: only output warnings and above per default
Hi, ok, will fix the #if and will remove that if the cmake solution is there ;=) Greetings Christoph - Ursprüngliche Mail - On Tuesday 28 July 2015 07:54:54 Christoph Cullmann wrote: -Q_LOGGING_CATEGORY(LOG_PART, katepart) +Q_LOGGING_CATEGORY(LOG_PART, katepart, QtWarningMsg) This should be in a #if QT_VERSION QT_VERSION_CHECK(5,4,0) block, because it was missing in 5.3 (which we still support). My plan is the following: I asked Alex Merry to add a cmake macro to generate this debug._ph/debug.cpp pair of files, where we can add the #if above. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on 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: Review Request 124505: Add API to use QIcon for KMultiTabBar to avoid problems with wrong sized QPixmaps on HiDPI screens
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124505/ --- (Updated July 30, 2015, 2:18 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Edmundson. Changes --- Submitted with commit df8b48c6c910540b1fe3f3a45392fe0286145e8e by Christoph Cullmann to branch master. Repository: kwidgetsaddons Description --- New API with QIcon parameters, deprecate the public API for QPixmap Diffs - src/kmultitabbar.h 11005a9 src/kmultitabbar.cpp c289354 src/kmultitabbar_p.h 958c9b8 Diff: https://git.reviewboard.kde.org/r/124505/diff/ Testing --- Tested with Kate, seems to work OK ;=) The functions reuse the others, the constructors are duplicated. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124584: Introduce categorized debug output
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124584/ --- Review request for KDE Frameworks and Martin Klapetek. Repository: knotifications Description --- Introduce the use of qCDebug Diffs - src/CMakeLists.txt 13390f1 src/debug_p.h PRE-CREATION src/debug_p.cpp PRE-CREATION src/knotificationmanager.cpp 38bbc89 src/knotificationrestrictions.cpp 26acab6 src/knotifyconfig.cpp 2c8d33d src/kpassivepopup.cpp 60552b8 src/kstatusnotifieritem.cpp 8001050 src/kstatusnotifieritemdbus_p.cpp a9015c6 src/notifybyaudio.cpp 0fafdc7 src/notifybyexecute.cpp cde53e6 src/notifybylogfile.cpp ca3faf9 src/notifybypopup.cpp 932712d src/notifybytaskbar.cpp bbdf19d src/notifybytts.cpp ee73118 Diff: https://git.reviewboard.kde.org/r/124584/diff/ Testing --- Compiled and run Kate/KWrite, no longer spam on the console like (at least not if not turned on again via config): kwrite(11559)/(default) KNotificationManager::notify: Calling notify on Sound kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::StoppedState kwrite(11559)/(default) KNotificationManager::notify: Calling notify on Taskbar kwrite(11559)/(default) NotifyByTaskbar::notify: 0 75497555 kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::StoppedState to Phonon::LoadingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::StoppedState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::StoppedState to Phonon::LoadingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::BufferingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::BufferingState to Phonon::PlayingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::PlayingState to Phonon::BufferingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::BufferingState to Phonon::PlayingState kwrite(11559)/(default) KNotificationManager::close: Closing notification 1 kwrite(11559)/(default) NotifyByPopupPrivate::closeGalagoNotification: not found dbus id to close 1 kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::PlayingState to Phonon::StoppedState Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 36 - Still Unstable!
Hi, I reverted my change about the make warning default minimum for output, still it is unstable now :/ (for knewstuff my revert fixed it again, will take a look why knewstuff anyway changed the test results after such an change :/ Greetings Christoph - Ursprüngliche Mail - GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/36/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sun, 02 Aug 2015 11:09:30 + Build duration: 4 min 27 sec CHANGE SET Revision 4bab6a170283d2605a0dee276a0212e495100647 by cullmann: (Revert quot;less verbose categorized logging, move to ecm module laterquot;) change: edit src/core/kiocoredebug.cpp change: edit src/kiod/kiod_main.cpp JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 45 test(s), Skipped: 0 test(s), Total: 46 test(s)Failed: TestSuite.kiofilewidgets-kfileplacesmodeltest COBERTURA RESULTS Cobertura Coverage Report PACKAGES 20/20 (100%)FILES 249/327 (76%)CLASSES 249/327 (76%)LINE 23668/49654 (48%)CONDITIONAL 12590/19390 (65%) By packages autotests FILES 59/59 (100%)CLASSES 59/59 (100%)LINE 6614/7118 (93%)CONDITIONAL 3410/6273 (54%) autotests.http FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 (100%)CONDITIONAL 166/272 (61%) autotests.kcookiejar FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 60/90 (67%) src.core FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7264/13961 (52%)CONDITIONAL 3780/5267 (72%) src.core.kssl FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 3/6 (50%) src.filewidgets FILES 19/36 (53%)CLASSES 19/36 (53%)LINE 1831/7571 (24%)CONDITIONAL 693/1087 (64%) src.ioslaves.file FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 423/836 (51%)CONDITIONAL 309/454 (68%) src.ioslaves.http FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3793 (20%)CONDITIONAL 547/678 (81%) src.ioslaves.http.kcookiejar FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 600/756 (79%) src.ioslaves.trash FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 679/1124 (60%)CONDITIONAL 352/487 (72%) src.ioslaves.trash.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 431/818 (53%) src.kioslave FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 5/10 (50%) src.kntlm FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 306/386 (79%)CONDITIONAL 87/110 (79%) src.kpasswdserver FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 387/601 (64%)CONDITIONAL 283/414 (68%) src.kpasswdserver.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 275/279 (99%)CONDITIONAL 139/246 (57%) src.urifilters.fixhost FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 42/52 (81%) src.urifilters.ikws FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 238/741 (32%)CONDITIONAL 141/188 (75%) src.urifilters.localdomain FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 14/18 (78%) src.urifilters.shorturi FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 225/255 (88%)CONDITIONAL 292/358 (82%) src.widgets FILES 28/60 (47%)CLASSES 28/60 (47%)LINE 2587/10562 (24%)CONDITIONAL 1236/1806 (68%) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- - 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: Review Request 124584: Introduce categorized debug output
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124584/ --- (Updated Aug. 2, 2015, 3:18 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Klapetek. Changes --- Submitted with commit 74eb68be1b7b6f83f861a952907b4410e1cff2ce by Christoph Cullmann to branch master. Repository: knotifications Description --- Introduce the use of qCDebug Diffs - src/CMakeLists.txt 13390f1 src/debug_p.h PRE-CREATION src/debug_p.cpp PRE-CREATION src/knotificationmanager.cpp 38bbc89 src/knotificationrestrictions.cpp 26acab6 src/knotifyconfig.cpp 2c8d33d src/kpassivepopup.cpp 60552b8 src/kstatusnotifieritem.cpp 8001050 src/kstatusnotifieritemdbus_p.cpp a9015c6 src/notifybyaudio.cpp 0fafdc7 src/notifybyexecute.cpp cde53e6 src/notifybylogfile.cpp ca3faf9 src/notifybypopup.cpp 932712d src/notifybytaskbar.cpp bbdf19d src/notifybytts.cpp ee73118 Diff: https://git.reviewboard.kde.org/r/124584/diff/ Testing --- Compiled and run Kate/KWrite, no longer spam on the console like (at least not if not turned on again via config): kwrite(11559)/(default) KNotificationManager::notify: Calling notify on Sound kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::StoppedState kwrite(11559)/(default) KNotificationManager::notify: Calling notify on Taskbar kwrite(11559)/(default) NotifyByTaskbar::notify: 0 75497555 kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::StoppedState to Phonon::LoadingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::StoppedState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::StoppedState to Phonon::LoadingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::LoadingState to Phonon::BufferingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::BufferingState to Phonon::PlayingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::PlayingState to Phonon::BufferingState kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::BufferingState to Phonon::PlayingState kwrite(11559)/(default) KNotificationManager::close: Closing notification 1 kwrite(11559)/(default) NotifyByPopupPrivate::closeGalagoNotification: not found dbus id to close 1 kwrite(11559)/(default) NotifyByAudio::stateChanged: Changing audio state from Phonon::PlayingState to Phonon::StoppedState Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
