Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)
On Sun, 30 Aug 2015, Dmitry Kazakov wrote: Hi, Friedrich! I have several points against total reformatting of everything. 1) We are planning to alpha-release LevelOfDetail and Animation functionality soon for users to test. And we cannot base this version on Frameworks, because the latter one has no decent tablet support on Linux (Qt5 makes the line look jittery and we have no decision yet how to fix that). So we cannot merge it in atm. You _have_ to. You can't go on building the animation branch against 2.9 and expect to be able to merge it to master later on. There will be too many changes, not just whitespace cleanups. It's a pity that tablet support isn't fixed yet, but that's not a reason not to move feature development to the master/kf5/qt5 branch. We'll have to make sure tablet support is good again anyway. 2) I am personally against of automated whitespace reformatting, because it pollutes history of files without any use. Includes, slots, forward declarations reformattings are ok. Whitespace no. There is a lot of use in whitespace cleanup: it makes the code consistent and readable. 3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will break my workflow. You have to expect me to spent at least 2 working days on readjusting my workflow. I'm ok with it, though I would prefer to spend this time on something more useful for Krita. Well, we can do two things, after we've split up the repositories: rename everything to camelcase, or everything to underscores. As for me, Qt Creator makes it much easier to work with files that have the same names as the class themselves. Boudewijn ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,NoOpenGL,gcc - Build # 3 - Failure!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoOpenGL,compiler=gcc/3/ Project: PLATFORM=Linux,Variation=NoOpenGL,compiler=gcc Date of build: Sun, 30 Aug 2015 08:05:41 + Build duration: 4 min 17 sec CHANGE SET Revision 5d95fbfd2716c086e1dd469a1e32a424c9d3c38b by scripty: (SVN_SILENT made messages (.desktop file)) change: edit krita/plugins/filters/normalize/kritanormalize.desktop change: edit krita/plugins/extensions/metadataeditor/kritametadataeditor.desktop change: edit krita/plugins/paintops/tangentnormal/kritatangentnormalpaintop.desktop Revision e1b8cd4f9d5edff36202c27bbc388173d67245e2 by yurchor: (Fix some minor typos) change: edit krita/ui/widgets/kis_advanced_color_space_selector.cc Revision 7ce69dd9785076190da4912401f2e6e7a4813c29 by yurchor: (Fix minor typos) change: edit krita/ui/widgets/kis_advanced_color_space_selector.cc Revision 749144921424dfefedbcbdb2b84f9df07bf63eb3 by dimula73: (Fix Fill with ... (Opacity) actions) change: edit krita/krita.action change: edit krita/ui/actions/kis_selection_action_factories.cpp change: edit krita/ui/kis_selection_manager.cc Revision 4bfca65cc0f5820696aeebd758bfb9966c1e21a9 by boud: (BUG:345285 Correctly install the xcf import plugin on Windows) change: edit krita/plugins/formats/xcf/CMakeLists.txt Revision e178a006969e698bb99696bd38a3179e990c167e by boud: (BUG:351664 Disable the layerbox if there#039;s no open image) change: edit krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp Revision 1ed2670d1b12aa7a5d69b59c6a18affa13e83766 by dimula73: (Fix crash due to calling a virtual method from c-tor of KisToolPaint) change: edit krita/ui/tool/kis_tool_paint.h Revision 8d385bae6993335014b8aa26290034c99f50260b by animtim: (update icons in transform tool options) change: add krita/pics/tool_transform/light_krita_tool_transform_recursive.png change: delete krita/plugins/tools/tool_transform2/krita_tool_transform_recursive.png change: add krita/pics/tool_transform/dark_krita_tool_transform_recursive.png change: edit krita/pics/CMakeLists.txt change: edit krita/plugins/tools/tool_transform2/CMakeLists.txt change: edit krita/plugins/tools/tool_transform2/kis_tool_transform_config_widget.cpp Revision 7fdddb31f4f57baac907c5a8504759b669eb7949 by animtim: (fix trashcan icon again) change: edit krita/pics/layerbox/light_deletelayer.png change: edit krita/pics/layerbox/dark_deletelayer.png Revision 8bbc5b6f28f39f2cdf7cfab9c150b71ab4d568a7 by boud: (Update the display profile after changing the settings) change: edit krita/ui/KisViewManager.cpp change: edit krita/ui/kis_canvas_resource_provider.h change: edit krita/ui/canvas/kis_canvas2.cpp change: edit krita/ui/dialogs/kis_dlg_preferences.cc change: edit krita/ui/kis_canvas_resource_provider.cpp change: edit krita/ui/KisMainWindow.cpp change: edit krita/ui/kis_config.h Revision bc94a66aa94200ad46a109a6dbc043243417190a by boud: (CCBUG:351488 Update the display profile when moving screens) change: edit krita/ui/KisMainWindow.h change: edit krita/ui/canvas/kis_canvas2.cpp change: edit krita/ui/KisMainWindow.cpp change: edit krita/ui/canvas/kis_canvas2.h change: edit krita/ui/KisView.cpp Revision fd81f7ee9582e30a9ba56e2fa80458f751c29038 by boud: (Remove disabling of system profile checkbox) change: edit krita/ui/dialogs/kis_dlg_preferences.cc Revision 994794d7f3b8737c9ebb87a921ec924be4e9d4af by boud: (CCBUG:351488 Do not share textures when that#039;s not possible) change: edit krita/ui/opengl/kis_opengl_image_textures.cpp Revision fc1d20403021e1f5558251d8367b94abf4861f7c by griffinvalley: (Make cs-convert UI attempt to automatically determine when to uncheck) change: edit krita/plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.cc change: edit krita/plugins/extensions/colorspaceconversion/wdgconvertcolorspace.ui Revision 52bec600293934309c5f39cb5b5d838cc9eea4e2 by boud: (Fix loading the system-set monitorprofile) change: edit krita/ui/kis_config.cc change: edit krita/ui/dialogs/kis_dlg_preferences.cc Revision 72cc4f981d25832c59eac1e2afddb46cc00a75f9 by boud: (Prepare some extra debug...) change: edit krita/libcolor/kis_color_manager_linux.cpp Revision a1a225e34356668b5a70fe482c983ec5abb30135 by griffinvalley: (Fix phongbumpmap filter UI#039;s new checkbox to be dual state) change: edit krita/plugins/filters/phongbumpmap/kis_phong_bumpmap_config_widget.h change: edit krita/plugins/filters/phongbumpmap/kis_phong_bumpmap_config_widget.cpp change: edit krita/plugins/filters/phongbumpmap/wdgphongbumpmap.ui Revision d39ab049784e50a9128154122b5a7dc00c090576 by griffinvalley: (Update brushes with optimised versions.) change: edit krita/data/paintoppresets/Ink_gpen_10.kpp change: edit krita/data/paintoppresets/Bristles_hairy.kpp change: edit krita/data/paintoppresets/Block_bristles.kpp change: edit
Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)
3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will break my workflow. You have to expect me to spent at least 2 working days on readjusting my workflow. I'm ok with it, though I would prefer to spend this time on something more useful for Krita. Well, we can do two things, after we've split up the repositories: rename everything to camelcase, or everything to underscores. As for me, Qt Creator makes it much easier to work with files that have the same names as the class themselves. I'd advise against using case filenames, or at least be very attentive not to depend on filename differences that are in case only. This *will* lead to problems on MS Windows and Mac OS X. R ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9.7
I'm laid up with food poisoning right now, but we've already got a start of a changelog, so that'll be possible. On Sun, 30 Aug 2015, Jaroslaw Staniek wrote: Thanks, @Maintainers Before end of Monday please send me changelogs for the release announcement. Thanks. On 26 August 2015 at 10:22, Cyrille Berger cber...@cberger.net wrote: On 2015-08-25 14:10, Jaroslaw Staniek wrote: So I am assuming this as OK. @Cyrille are you available? This is rather a deadline for me to push a fix for defective 2.9.5/6 Kexi. Hopefully. -- Cyrille Berger Skott -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)
We're not going to do that. No FooBar.cpp and foobar.cpp files, just FooBar.cpp. On 30 August 2015 at 12:44, René J.V. rjvber...@gmail.com wrote: 3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will break my workflow. You have to expect me to spent at least 2 working days on readjusting my workflow. I'm ok with it, though I would prefer to spend this time on something more useful for Krita. Well, we can do two things, after we've split up the repositories: rename everything to camelcase, or everything to underscores. As for me, Qt Creator makes it much easier to work with files that have the same names as the class themselves. I'd advise against using case filenames, or at least be very attentive not to depend on filename differences that are in case only. This *will* lead to problems on MS Windows and Mac OS X. R ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)
On 30 August 2015 at 10:29, Boudewijn Rempt b...@valdyas.org wrote: On Sun, 30 Aug 2015, Dmitry Kazakov wrote: Hi, Friedrich! I have several points against total reformatting of everything. 1) We are planning to alpha-release LevelOfDetail and Animation functionality soon for users to test. And we cannot base this version on Frameworks, because the latter one has no decent tablet support on Linux (Qt5 makes the line look jittery and we have no decision yet how to fix that). So we cannot merge it in atm. You _have_ to. You can't go on building the animation branch against 2.9 and expect to be able to merge it to master later on. There will be too many changes, not just whitespace cleanups. It's a pity that tablet support isn't fixed yet, but that's not a reason not to move feature development to the master/kf5/qt5 branch. We'll have to make sure tablet support is good again anyway. 2) I am personally against of automated whitespace reformatting, because it pollutes history of files without any use. Includes, slots, forward declarations reformattings are ok. Whitespace no. There is a lot of use in whitespace cleanup: it makes the code consistent and readable. Yes, we discussed that a bit a while ago. Initially I was critical too. But whitespace changes can be ignored when generating diff _and_ blame (the -w option). Anyone can add this flag in git options for diff/blame. I'd do so. I'd like to note that we don't have a proven formatting tool for now for all C++ elements. astyle got broken, and clang formatter can be better but we need an expert. Missing things may be minor but we can't make the result worse in problematic areas than the original. Not even KF5 has a formatting tool, last I checked. 3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will break my workflow. You have to expect me to spent at least 2 working days on readjusting my workflow. I'm ok with it, though I would prefer to spend this time on something more useful for Krita. Well, we can do two things, after we've split up the repositories: rename everything to camelcase, or everything to underscores. As for me, Qt Creator makes it much easier to work with files that have the same names as the class themselves. + We're in Qt/KF5-centric world where CamelCase is used. Boudewijn ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
How about a blog entry and sending the info to more kde mailing lists? On Sunday, 30 August 2015, Friedrich W. H. Kossebau kosse...@kde.org wrote: Hi, noone has shown up with interest to keep Braindump Calligra Active alive and care for porting them to Qt5 KF5. So before we start with further porting refactoring again after the freeze on master is melted, I would propose to remove both now in master and add them as some other entries to OBSOLETE.txt Additionally I will also remove the FILTER_MPXJ_IMPORT for Plan (for importing MS Project files), as it is broken and noone has come around for all the time to fix it. So last chance for anyone to jump in and take over any of them! I will remove all on Tuesday, September 2nd otherwise. Cheers Friedrich ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Why I love(d) Krita to be part of Calligra (was: Re: After 2.9.7)
Long mail :-) Sven already said a lot of what I wanted to say. The thing is, with KOffice 2.0, we actually got further along the road to making fine-grained composite document possible. We got further than Apple, IBM or Microsoft with projects like Taligent, Opendocs or OLE. Sure, we made architectural mistakes, but to very large extent, the result works. With Calligra Gemini you can already combine hand-written annotations with your document, for instance. There are just two gotchas: the first is that for all of that, Krita's specific strengths aren't needed, but on the other hand, a lot of ballast. There are at least two image filter implementations in Calligra next to Krita's, and those are more suited for compound documents, for instance. The other is that the users aren't there. It was a grand vision, and one that's really attractive to software developers, but users care about one thing: getting the job done asap, so they can quit the word processor and go back to doing their real work. And they're right. That's another difference between Krita and office applications. Office applications, unless you happen to be a novelist, support doing work, are not tools to do the actual work. You use krita to produce the deliverable you send to a customer, you use Words to create the accompanying invoice. And that might just be the reason, not just for all the problems finding contributors to the office software, but even for finding motivation and time to actually make the projects big and well known. Even now, even this year, reviews of Linux office software will say of Calligra, promising, interesting, might become something with work, which is exactly what they said in 2005. Finally, Calligra has been a success, has been used in half a dozen mobile products, with hundreds of thousands of users, but to continue being a success we need someone as crazy about Calligra as Michael Meeks is crazy about Libre Office. Boudewijn Who still feels really bad :-( ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 123943: Port KoDocumentEntry::name() and mimeTypes() to KF5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123943/#review84605 --- Hi Peter, thanks for your patch. Sorry, seems everyone missed to notice it so far. Possibly because we were concentrated to look at phabricator.kde.org which Calligra was testing out as pilot contributor. Next time please make more noise if noone reacts in a week :) E.g. by adding a ping to the review request. The TODOs that your patch fixes have already been fixed with similar code. So may I please ask you to close this review request as discarded (only the author seems to be able to do it). - Friedrich W. H. Kossebau On May 30, 2015, 10:23 a.m., Peter Simonsson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123943/ --- (Updated May 30, 2015, 10:23 a.m.) Review request for Calligra. Repository: calligra Description --- Getting the data from QPluginLoader::metaData() which contains the entries from the desktop file. Diffs - libs/main/KoDocumentEntry.cpp f24a7ef Diff: https://git.reviewboard.kde.org/r/123943/diff/ Testing --- Verified name() output the Name entry value from the desktop file and mimeTypes() the MimeType entry value. Thanks, Peter Simonsson ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,All,gcc - Build # 3 - Failure!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/3/ Project: PLATFORM=Linux,Variation=All,compiler=gcc Date of build: Sun, 30 Aug 2015 08:05:41 + Build duration: 4 min 40 sec CHANGE SET Revision 5d95fbfd2716c086e1dd469a1e32a424c9d3c38b by scripty: (SVN_SILENT made messages (.desktop file)) change: edit krita/plugins/paintops/tangentnormal/kritatangentnormalpaintop.desktop change: edit krita/plugins/filters/normalize/kritanormalize.desktop change: edit krita/plugins/extensions/metadataeditor/kritametadataeditor.desktop Revision e1b8cd4f9d5edff36202c27bbc388173d67245e2 by yurchor: (Fix some minor typos) change: edit krita/ui/widgets/kis_advanced_color_space_selector.cc Revision 7ce69dd9785076190da4912401f2e6e7a4813c29 by yurchor: (Fix minor typos) change: edit krita/ui/widgets/kis_advanced_color_space_selector.cc Revision 749144921424dfefedbcbdb2b84f9df07bf63eb3 by dimula73: (Fix Fill with ... (Opacity) actions) change: edit krita/ui/kis_selection_manager.cc change: edit krita/ui/actions/kis_selection_action_factories.cpp change: edit krita/krita.action Revision 4bfca65cc0f5820696aeebd758bfb9966c1e21a9 by boud: (BUG:345285 Correctly install the xcf import plugin on Windows) change: edit krita/plugins/formats/xcf/CMakeLists.txt Revision e178a006969e698bb99696bd38a3179e990c167e by boud: (BUG:351664 Disable the layerbox if there#039;s no open image) change: edit krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp Revision 1ed2670d1b12aa7a5d69b59c6a18affa13e83766 by dimula73: (Fix crash due to calling a virtual method from c-tor of KisToolPaint) change: edit krita/ui/tool/kis_tool_paint.h Revision 8d385bae6993335014b8aa26290034c99f50260b by animtim: (update icons in transform tool options) change: add krita/pics/tool_transform/light_krita_tool_transform_recursive.png change: edit krita/plugins/tools/tool_transform2/kis_tool_transform_config_widget.cpp change: edit krita/plugins/tools/tool_transform2/CMakeLists.txt change: add krita/pics/tool_transform/dark_krita_tool_transform_recursive.png change: delete krita/plugins/tools/tool_transform2/krita_tool_transform_recursive.png change: edit krita/pics/CMakeLists.txt Revision 7fdddb31f4f57baac907c5a8504759b669eb7949 by animtim: (fix trashcan icon again) change: edit krita/pics/layerbox/light_deletelayer.png change: edit krita/pics/layerbox/dark_deletelayer.png Revision 8bbc5b6f28f39f2cdf7cfab9c150b71ab4d568a7 by boud: (Update the display profile after changing the settings) change: edit krita/ui/kis_config.h change: edit krita/ui/kis_canvas_resource_provider.cpp change: edit krita/ui/dialogs/kis_dlg_preferences.cc change: edit krita/ui/canvas/kis_canvas2.cpp change: edit krita/ui/KisViewManager.cpp change: edit krita/ui/kis_canvas_resource_provider.h change: edit krita/ui/KisMainWindow.cpp Revision bc94a66aa94200ad46a109a6dbc043243417190a by boud: (CCBUG:351488 Update the display profile when moving screens) change: edit krita/ui/canvas/kis_canvas2.h change: edit krita/ui/KisView.cpp change: edit krita/ui/KisMainWindow.cpp change: edit krita/ui/KisMainWindow.h change: edit krita/ui/canvas/kis_canvas2.cpp Revision fd81f7ee9582e30a9ba56e2fa80458f751c29038 by boud: (Remove disabling of system profile checkbox) change: edit krita/ui/dialogs/kis_dlg_preferences.cc Revision 994794d7f3b8737c9ebb87a921ec924be4e9d4af by boud: (CCBUG:351488 Do not share textures when that#039;s not possible) change: edit krita/ui/opengl/kis_opengl_image_textures.cpp Revision fc1d20403021e1f5558251d8367b94abf4861f7c by griffinvalley: (Make cs-convert UI attempt to automatically determine when to uncheck) change: edit krita/plugins/extensions/colorspaceconversion/wdgconvertcolorspace.ui change: edit krita/plugins/extensions/colorspaceconversion/dlg_colorspaceconversion.cc Revision 52bec600293934309c5f39cb5b5d838cc9eea4e2 by boud: (Fix loading the system-set monitorprofile) change: edit krita/ui/dialogs/kis_dlg_preferences.cc change: edit krita/ui/kis_config.cc Revision 72cc4f981d25832c59eac1e2afddb46cc00a75f9 by boud: (Prepare some extra debug...) change: edit krita/libcolor/kis_color_manager_linux.cpp Revision a1a225e34356668b5a70fe482c983ec5abb30135 by griffinvalley: (Fix phongbumpmap filter UI#039;s new checkbox to be dual state) change: edit krita/plugins/filters/phongbumpmap/wdgphongbumpmap.ui change: edit krita/plugins/filters/phongbumpmap/kis_phong_bumpmap_config_widget.h change: edit krita/plugins/filters/phongbumpmap/kis_phong_bumpmap_config_widget.cpp Revision d39ab049784e50a9128154122b5a7dc00c090576 by griffinvalley: (Update brushes with optimised versions.) change: edit krita/data/paintoppresets/Ink_brush_25.kpp change: edit krita/data/paintoppresets/Basic_wet.kpp change: edit krita/data/paintoppresets/Block_basic.kpp change: edit
Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
Hi, noone has shown up with interest to keep Braindump Calligra Active alive and care for porting them to Qt5 KF5. So before we start with further porting refactoring again after the freeze on master is melted, I would propose to remove both now in master and add them as some other entries to OBSOLETE.txt Additionally I will also remove the FILTER_MPXJ_IMPORT for Plan (for importing MS Project files), as it is broken and noone has come around for all the time to fix it. So last chance for anyone to jump in and take over any of them! I will remove all on Tuesday, September 2nd otherwise. Cheers Friedrich ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 123985: Port sheets' configure dialog to KF5
On June 2, 2015, 7:50 p.m., Tomas Mecir wrote: After testing, yeah, the plugin stuff doesn't work, please either port that as well to the new API, or keep it commented out for now. Otherwise looks good. Thanks! Yes, problem with KPluginSelector and new Calligra plugins being incompatible tracked at https://phabricator.kde.org/T448. The port of the buttons to Qt5 as done in this patch has been solved meanwhile by other commits. So this review request might need to be discarded now. Peter, can you please do that? Thanks for your effort. Hopefully your next patch will then make it into the repo :) - Friedrich W. H. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123985/#review81091 --- On June 2, 2015, 4:08 p.m., Peter Simonsson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123985/ --- (Updated June 2, 2015, 4:08 p.m.) Review request for Calligra. Repository: calligra Description --- Fix buttons and signals. ?eenable the plugin selector. Diffs - CMakeLists.txt a4e3f24 sheets/CMakeLists.txt c7567c4 sheets/part/dialogs/PreferenceDialog.h 543bf45 sheets/part/dialogs/PreferenceDialog.cpp 8b044a8 Diff: https://git.reviewboard.kde.org/r/123985/diff/ Testing --- Thanks, Peter Simonsson ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 124630: Use DATA_INSTALL_DIR instead of INSTALL_PREFIX/share
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124630/#review84609 --- Hi Heiko. Please turn this into a bug to track this problem and close this review request, until there is a new patch this can be reviewed. That will help us tracking review requests which actually can be reviewed :) - Friedrich W. H. Kossebau On Aug. 5, 2015, 6:36 p.m., Heiko Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124630/ --- (Updated Aug. 5, 2015, 6:36 p.m.) Review request for Calligra. Repository: calligra Description --- Allowing to configure the install location, which is helpful with a multiarch layout, where prefix might be something like /usr/arch but arch independent data should be installed to /usr/share/... Diffs - active/CMakeLists.txt 8fa0c6f1c04220f9178d0be1ea27b5c1428cd4d2 krita/data/profiles/CMakeLists.txt a2a997b30aa159a36369e3825a1c8962597f07c4 krita/data/profiles/elles-icc-profiles/CMakeLists.txt f252e164e506f40780523a4a0b1b545257b64801 Diff: https://git.reviewboard.kde.org/r/124630/diff/ Testing --- Checked that the affected files get installed into the desired location. Thanks, Heiko Becker ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
Am Sonntag, 30. August 2015, 20:42:42 schrieb Jaroslaw Staniek: How about a blog entry and sending the info to more kde mailing lists? Which would be a good idea. We should have even done that at the beginning of the port. And then see if someone shows up in all the weeks till now. /me jumps into time machine... *puff*smell of onions*piff* /me returns Et voila; https://frinring.wordpress.com/2015/04/17/like-braindump-adopt-it-for-the-qt5kf5-port/ https://mail.kde.org/pipermail/calligra-devel/2015-April/013668.html Hm, seems noone showed up in all the weeks till now. WRT Calligra Active, PlasmaActive with the old architecture is dead. No idea what architecture there is with PlasmaMobile, if there already is one. But I assume anything Calligra Plasma Mobile should rather get a fresh restart. And as much as I almost would use Braindump myself, with no developers caring for it it is just a millstone for those trying to drive the Calligra libs forward. So moving it out of the working branch seems the obvious solution. Cheers Friedrich ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,NoOpenGL,gcc - Build # 4 - Still Failing!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoOpenGL,compiler=gcc/4/ Project: PLATFORM=Linux,Variation=NoOpenGL,compiler=gcc Date of build: Sun, 30 Aug 2015 21:08:13 + Build duration: 2 min 7 sec CHANGE SET No changes ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
On Sun, 30 Aug 2015, Jaroslaw Staniek wrote: How about a blog entry and sending the info to more kde mailing lists? What would that achieve? Blogging about karbon going unmaintained has had zero result. Worse... We have a patch for Braindump: https://git.reviewboard.kde.org/r/123554/ But no-one to apply it. There are other KF5 patches on reviewboard, too: https://git.reviewboard.kde.org/r/123985/ https://git.reviewboard.kde.org/r/123943/ Boudewijn ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
On 30 August 2015 at 20:53, Boudewijn Rempt b...@valdyas.org wrote: On Sun, 30 Aug 2015, Jaroslaw Staniek wrote: How about a blog entry and sending the info to more kde mailing lists? What would that achieve? Blogging about karbon going unmaintained has had zero result. Worse... We have a patch for Braindump: https://git.reviewboard.kde.org/r/123554/ But no-one to apply it. There are other KF5 patches on reviewboard, too: https://git.reviewboard.kde.org/r/123985/ https://git.reviewboard.kde.org/r/123943/ I didn't know. If kde-devel readers knew maybe someone would join. That's last chance. That said for braindump my opinion was that it's a specialized app that needs simple features, ones that are be supereasy/convenient to use in the first place. PS: for large removals let's have tags, good for reference. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [Kexi-devel] Handling of splitted Calligra repos and API changes
On 28 August 2015 at 19:10, Friedrich W. H. Kossebau kosse...@kde.org wrote:
Hi,
with KDb, KProperty and KReport, a few libs/frameworks have been already split
off during the port of Calligra to Qt5/KF5.
And they pose a challenge that needs to be solved quickly:
traditionally we have had no ABI guarantuee in Calligra even in patch releases
and of course also not during development. Because sourcecode of all libs and
libconsumers were in a shared repo, and any API changes were done in atomic
commits both to the libs and libconsumers (because by policy we require any
commits to the repo to not break it's build).
With libs and libconsumers being split in separate repos the atomicity no
longer is given.
Which results in problems:
* people might pull from repos missing part of API change commits
* current KDE CI triggered by commits will build repos without caring for
dependencies between commits, using products from previous lib builds with
old API for the build of libconsumer with commit using newer API
* ?
No idea how to solve the KDE CI one perfectly. But for the problem of pulling
consistent states, what about the following rules with the split off lib
repos:
* no ABI breakage in patch releases for released branches
* weekday of API breakage: a set day per week development branches can get
commits which involve API changes in the libs in separate repos
still related commits should be pushed together in an as small timewindow
as possible
No ABI breakage in patch releases might be a no-brainer, given that targetted
3rd-party consumers would rely on that as well.
The second one would pick up something which seemed to work well enough in
times where close kdelibs and kdeapps development was common, and where people
also did separate svn pulls for libs and apps. Pushing related commits to
all repos in small timewindows might not completely match atomic commits as
possible with subversion. But in the end we all pull in time (fetch latest
commits now) and not by branch state (fetch commits until xyz id), so in
practice this might work as well still.
What do you think? Would this work for you as well?
IMHO we need to have an agreed solution here before Kexi-frameworks is merged
back, because it will force us into this situation (where Plan currently does
not depend on KReport, my respective patch waiting since many weeks for
someone to push this question for handling of the API-break challenge and to
find an agreed resolution ;) ).
((While in the discussion this is only about those 3 libs for now... My
personal desire is to make the Calligra document libs more accessible to other
apps, which partially do document creating/processing. For that I would see
some advantage to split off more libs into own repos as well. In the long run
I would like to see Calligra move out of it's own corner and integrate more
with the normal KDE application scene.
But more on that once we have finally passed the port hurdle, are back in
normal feature development and can start talking post-3.0 (where 3.0 is now
the first real release) :) ))
Friedrich,
Big thanks for this thread. Sorry for the late response.
I'd be OK with complying with the usual rules of patch releases. I
just expect that major releases can come a lot more often than usual
in case of libs I maintain, to address the challenge with API/ABI
break. I am considering to even have
$PREFIX/include/FooLib/{MAJORVERSIONNUMBER}/ dirs if really needed.
And {MAJORVERSIONNUMBER} in sonames. Side-by-side installs can be
supported this way. If 3rdparties come to use some libs, they are
relatively safe, and Kexi can use fresh dedicated versions. This is
from the POV of actual needs. The same time, packagers get predictable
rules.
API deprecation rules - sure I support that - it's a favour to
co-developers that may port away from older API just a few weeks later
than expected. If possible (from C++ POV) I wouldn't silently drop a
symbol. Unless it was just introduced in a feature branch and has
never landed in a release.
Next, how to check versions. A single properly configured kdesrc-build
can solve issues when people try to fetch individual repos and make
human mistakes.
During development you either use kdesrc-build configured to use the
branch for the repos (e.g. master) or you do that by hand. It works
for Kexi+kdb+kreport+kproperty so far.
For people building largely by hand, I'd introduce a support for
specific case: a
find_package wrapper that checks if the dependency has an exact git
revision. That's like an assertion that tells you that your deps are
too old (or too new, or even from incompatible branch - use git to
find out). (I already offer the git revision information for kdb.git,
etc. and believe providing it even in --help for apps is a good thing
in modern times).
So I don't expect many cases with we have kf5-like state for some of
calligra libs. But even now kdb.git is much easier to reuse
Re: Review Request 123554: Readd Braindump to build on frameworks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123554/#review84607 --- Hi Somsubhra. Thanks for your patch. Sadly the old maintainer has no more interest in this application. And noone else is working on it. This is why noone took a look at your work all the time. (And I missed the email notice, with my general interest in Calligra). As you might have read, we are looking for a new maintainer for Braindump. See e.g. https://frinring.wordpress.com/2015/04/17/like-braindump-adopt-it-for-the-qt5kf5-port/ So given you have shown interest in Braindump, by working on creating this patch, might you be interest to simply take over maintainership of Braindump? Please reply quickly, as we are planning to remove Braindump completely in a few days otherwise (only discovered your review request now). Best contact by email on the developer mailinglist of Calligra, see https://community.kde.org/Calligra/Contact for best ways to get in contact. Cheers Friedrich - Friedrich W. H. Kossebau On April 29, 2015, 7:13 a.m., Somsubhra Bairi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123554/ --- (Updated April 29, 2015, 7:13 a.m.) Review request for Calligra. Repository: calligra Description --- Readd Braindump to build on frameworks Diffs - CalligraProducts.cmake 5b15bbe braindump/braindumpcore/CMakeLists.txt 24f3854 braindump/braindumpcore/State.h 5970280 braindump/braindumpcore/StatesRegistry.cpp a611bf4 braindump/plugins/stateshape/CMakeLists.txt 38c9c5e braindump/plugins/stateshape/CategorizedItemDelegate.cpp 4e7a802 braindump/plugins/webshape/CMakeLists.txt 07b25ba braindump/plugins/webshape/WebShapePlugin.cpp 0e8c42e braindump/src/AboutData.h d3dadc4 braindump/src/CMakeLists.txt 0aae217 braindump/src/MainWindow.h d035630 braindump/src/MainWindow.cpp b31df13 braindump/src/SectionsIO.cpp b2d07b7 braindump/src/StatusBarItem.h 9afba37 braindump/src/View.h c3f2cf7 braindump/src/View.cpp 58a05da braindump/src/import/DockerManager.cpp 3521ed5 braindump/src/import/ToolDocker.cpp 090f0bc braindump/src/main.cpp c6c0c38 Diff: https://git.reviewboard.kde.org/r/123554/diff/ Testing --- Braindump starts Thanks, Somsubhra Bairi ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 123955: get calligra frameworks to compile with qt 5.5 by including needed headers
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123955/#review84608 --- This has been commited meanwhile as c0453b985be60dd85f9c264f1d17455edd5a9bf1, so please close this review request, to help us manage open ones :) - Friedrich W. H. Kossebau On May 30, 2015, 11:04 p.m., Nerdopolis Turfwalker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123955/ --- (Updated May 30, 2015, 11:04 p.m.) Review request for Calligra. Repository: calligra Description --- get calligra frameworks to compile with qt 5.5 Diffs - filters/words/mobi/MobiFile.cpp 00922b06f995e54e3cbc1d8fd23334626711163f libs/flake/KoGridData.h 19acb74dd69ba706d6ec26cdb394ba2840ad75d5 libs/flake/KoPathPoint.cpp 5ae455480075409d10db5cdb9d1b3692927346c2 libs/flake/KoPathShape.cpp b3d1d22038570519569bc70df96d7352669eace5 libs/widgetutils/KoProperties.cpp 24e0219079f76856ca00a4c7b576413785b528da Diff: https://git.reviewboard.kde.org/r/123955/diff/ Testing --- Compile with Release, and against QT 5.5 Thanks, Nerdopolis Turfwalker ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Why I love(d) Krita to be part of Calligra (was: Re: After 2.9.7)
On Sat, Aug 29, 2015 at 10:41 PM, Friedrich W. H. Kossebau kosse...@kde.org wrote: Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt: For Krita, and I hate to say this, it probably makes sense to fork our shared libraries. The office-apps maintainers can then strip out all the krita-specific stuff, and for Krita, we can strip out the stuff that only makes sense for office applications. I also think that it makes sense for Krita to integrate the karbon plugins and tools, and maybe the karbon filters. I honestly don't see any future for karbon as a separate application. You cannot build a good vector drawing application without a dedicated maintainer, and Karbon has been officially unmaintained since April 2013 already. Oh dear, for quite some time I have feared this proposal to happen, to split off Krita + fork off shared libs into an own project and repo. Sadly I could not collect enough arguments why that would be an insane idea and only that. From a pragmatical point of view, I see more advantages than disadvantages as well for all parties, if I am honest, given the current interest of all people involved in contributions. There are more and more who only are interested in one app and not the whole Calligra suite, which is just reality and thus fine and nothing to blame someone for. And if one only has interest in one app, shared goods with other apps cannot be dealt with in the needed manner. ((Ideally those people should be made interested in the whole Calligra suite :) But given the current state of most apps that's a mission to fail sadly currently)) But: such a split would conflict a lot with my motivation for why I have joined the Calligra project and spent quite some time on mainly cleaning up Calligra code so far :( I have been appealed by the vision of a component-based system, where one potentially could assemble a custom UI per usecase and create rich composed documents with all kind of content. Like I could when I was a kid and blank sheets of paper were what I had as canvas, and the working shell was by my real-world desktop setup. E.g. with pencils and stickers always in reach on my private desktop, depending on my mood of the day, to do whatever mix of content on the sheet of paper as I liked. When then I had my first computer, I was mainly attracted by the virtual sheets those enabled. Where things could be undone or reshuffled (no need to restart with a new sheet when some text line mistakenly hit the sheet border too early or had a typo or when some item was forgotten in the structure and no more space was available). I loved Geoworks, Amipro, and especially Corel Draw, as those gave me many of the composing freedoms one had with a real sheet and then all the amazing options coming with virtual objects. (And I miss them, so far I found no real FLOSS replacement) Writing reports during education and work I experienced additional challenges, how to best do big structured documents and also automatically integrate things generated from data, like calculations, diagrams, graphs or tables. Doing this with the wordprocessors available to me was not easy, escaping to TeX (or Lyx) only satisfied me to a certain degree. Which is the other aspect of Calligra that appealed me, having Kexi, Sheets and a report generation library as part. So I envisioned one day this should end up with being able to have not only classic line bar diagrams, but e.g. whole flow charts being generated, with custom shapes dynamically powered by data from databases or cell ranges in sheets. One would edit the database table in some UI made from Kexi components or some cell ranges in a UI made from Sheets components and see the document update in realtime. Perhaps even be able to sync changes back from the shapes (e.g. when resizing some element interactively). (Actually I kept Plan alive for now mainly for the reporting stuff, to have another use case around). Connected with this, I also share Jarosław dream about document-wide theming/styling, where all components in the document are bound to the same styling system, and any custom component plugin could link into it. So e.g. colors and fonts in diagrams would be coupled to those of the complete document, for a consistent look. Next, when I wrote the print exporting functionality in Okteta, a hex editor, I would have liked instead to render into some document system, where one could edit the template (think footer/header/title/styles) or and more (actually I once did a hexeditor Shape plugin, that could at least render :) ). There are many applications which render/export content to documents, just think of all the science app in KDE Edu, like Labplot or Cantor. But usually with hardcoded templates. This seems poor to me, we could do better especially in the Free and Libre Software world, where collaboration should be easier than in
Re: Why I love(d) Krita to be part of Calligra (was: Re: After 2.9.7)
Am Sonntag, 30. August 2015, 20:36:06 schrieb Boudewijn Rempt: Long mail :-) Sven already said a lot of what I wanted to say. The thing is, with KOffice 2.0, we actually got further along the road to making fine-grained composite document possible. We got further than Apple, IBM or Microsoft with projects like Taligent, Opendocs or OLE. Sure, we made architectural mistakes, but to very large extent, the result works. Which is what seems so great about Calligra for me :) With Calligra Gemini you can already combine hand-written annotations with your document, for instance. Oh, not noticed that, how can one do that? I saw voice and pre-made stickers, but pen input based option is at least not visible to me in the UI, also not on a touch device. Which code to look out for? Then, Calligra Gemini seems rather dead, no commit since it was imported :/ But I have hopes that I can sit together with leinir at Randa next week :) and revive this former beauty (rotten in master ATM) or at least see how to rescue the QtQuick bits for other usages. There are just two gotchas: the first is that for all of that, Krita's specific strengths aren't needed, but on the other hand, a lot of ballast. There are at least two image filter implementations in Calligra next to Krita's, and those are more suited for compound documents, for instance. Not sure how things are ballast if they are done behind proper abstraction layers. What do you mean filters in image filters? The other is that the users aren't there. It was a grand vision, and one that's really attractive to software developers, but users care about one thing: getting the job done asap, so they can quit the word processor and go back to doing their real work. And they're right. IMHO the users are not here, because most of Calligra's apps were never ready as editors, due to being crashy as hell, losing data and having incomplete features, especially compared to their usecase rivals. The code was/is fine for loading and viewing documents. Both confirmed and reinforced by the commercial products made from Calligra code, as you said. And that is also why I picked up the Okular plugins of Calligra, to make this viewer power available to more players. But the code for document manipulation and storing seems to never have seen a similar care. Krita is the happy exception here. The other problem is also that development of the core has stalled. Krita started to do workarounds to the existing core instead of seeing how to coevolve the core with the other apps, from what I saw. Surely also because of lack of interest of developers for other apps. Then, my real work would rather be in the word processor or even something bigger. Because it's not just a few lines of text that I do. I am talking about rich content. That is why I am here in Calligra. See below. So, I don't see at least this gotcha. That's another difference between Krita and office applications. Office applications, unless you happen to be a novelist, support doing work, are not tools to do the actual work. You use krita to produce the deliverable you send to a customer, you use Words to create the accompanying invoice. Perhaps that's where you miss my needs :) I am not interested in a software to just drop a few lines of text onto a sheet. And still I am not a novelist. No. I am interested in a software that allows me to create my long and content- rich reports, backed from database and other external sources, to create my leaflets, to create my hangout for the blackboard, invitation cards, content enriched letters to friends, tutorials, sheets with drafts for UI and architecture of software, drafts for garden design, costume drafts, etc. pp. With all kind of content types, wildly mixed on the same sheet. (He, I did the xfig import filter for a reason, like I started on the CorelDraw one) Something where LO, Scribus or Inkscape do not cut it, for different reasons. Having to write completely different software for reports, for leaflets, for hangouts, for invitation cards, for letters, for tutorials, for room concepts, for costume drafts, etc. seems insane to me. I still have the hope and many ideas, how reusable fine-grained components for the different kind of content types should allow to assemble working shells optimized for a certain main document type. Like one for doing long reports. And another for doing invitation cards. And a third for costume drafts. Like I can setup my real world desk or bench for different document types, by placing the usual content material and working tools in reach. I did not clean up Calligra code and worked hard to push it together will all over the Qt5 hurdle for nothing, there would be lots of more enjoyable things in life to do ;) No. Hopefully I qualify not as mad, but I have a long TODO list for Calligra libs, and some code drafts. And now we are almost past intial Qt5/KF5 port, I so look forward to finally go
Re: Handling of splitted Calligra repos and API changes
Am Sonntag, 30. August 2015, 23:21:59 schrieb Jaroslaw Staniek: On 28 August 2015 at 19:10, Friedrich W. H. Kossebau kosse...@kde.org wrote: Hi, with KDb, KProperty and KReport, a few libs/frameworks have been already split off during the port of Calligra to Qt5/KF5. And they pose a challenge that needs to be solved quickly: traditionally we have had no ABI guarantuee in Calligra even in patch releases and of course also not during development. Because sourcecode of all libs and libconsumers were in a shared repo, and any API changes were done in atomic commits both to the libs and libconsumers (because by policy we require any commits to the repo to not break it's build). With libs and libconsumers being split in separate repos the atomicity no longer is given. Which results in problems: * people might pull from repos missing part of API change commits * current KDE CI triggered by commits will build repos without caring for dependencies between commits, using products from previous lib builds with old API for the build of libconsumer with commit using newer API * ? No idea how to solve the KDE CI one perfectly. But for the problem of pulling consistent states, what about the following rules with the split off lib repos: * no ABI breakage in patch releases for released branches * weekday of API breakage: a set day per week development branches can get commits which involve API changes in the libs in separate repos still related commits should be pushed together in an as small timewindow as possible No ABI breakage in patch releases might be a no-brainer, given that targetted 3rd-party consumers would rely on that as well. The second one would pick up something which seemed to work well enough in times where close kdelibs and kdeapps development was common, and where people also did separate svn pulls for libs and apps. Pushing related commits to all repos in small timewindows might not completely match atomic commits as possible with subversion. But in the end we all pull in time (fetch latest commits now) and not by branch state (fetch commits until xyz id), so in practice this might work as well still. What do you think? Would this work for you as well? IMHO we need to have an agreed solution here before Kexi-frameworks is merged back, because it will force us into this situation (where Plan currently does not depend on KReport, my respective patch waiting since many weeks for someone to push this question for handling of the API-break challenge and to find an agreed resolution ;) ). ((While in the discussion this is only about those 3 libs for now... My personal desire is to make the Calligra document libs more accessible to other apps, which partially do document creating/processing. For that I would see some advantage to split off more libs into own repos as well. In the long run I would like to see Calligra move out of it's own corner and integrate more with the normal KDE application scene. But more on that once we have finally passed the port hurdle, are back in normal feature development and can start talking post-3.0 (where 3.0 is now the first real release) :) )) snip part about release branches, seems general agreement and no reason to depart from usual handling Next, how to check versions. A single properly configured kdesrc-build can solve issues when people try to fetch individual repos and make human mistakes. During development you either use kdesrc-build configured to use the branch for the repos (e.g. master) I see a problem here: right now everony for the everyday development on the development branch (so not stable/release branches) does a git pull or git pull --rebase before pushing ones own commits. Because when your patch is ready to be pushed, you want to get it out and then do something else. Which you can do now. Using instead kdesrc-build or similar tools every time will add cost more time during that process. And even some seconds already are annoying, when they do not improve your developing experience. Worse, if the tool detects a new commit in one of the repos and starts a rebuild of that, perhaps even a full because some central header was touched, you will lose even more time and be even more annoyed. No, I do not see me using something which checks all repos every time I do now a git pull. And very possibly also not anyone else. On a certain day per week, where I can expect breakage, sure. But not 24/7. We need a solution which does works with a simple git pull on only one of any of the involved repos, at least for 6 days in the week. For people building largely by hand, I'd introduce a support for specific case: a find_package wrapper that checks if the dependency has an exact git revision. That's like an assertion that tells you that your deps are too old (or too new, or even from
Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd
Am Sonntag, 30. August 2015, 20:53:32 schrieb Boudewijn Rempt: On Sun, 30 Aug 2015, Jaroslaw Staniek wrote: How about a blog entry and sending the info to more kde mailing lists? What would that achieve? Blogging about karbon going unmaintained has had zero result. Worse... We have a patch for Braindump: https://git.reviewboard.kde.org/r/123554/ But no-one to apply it. There are other KF5 patches on reviewboard, too: https://git.reviewboard.kde.org/r/123985/ https://git.reviewboard.kde.org/r/123943/ Too bad, I missed that last one. Answered all now, in any case. Friedrich ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Handling of splitted Calligra repos and API changes
On 31 August 2015 at 01:46, Friedrich W. H. Kossebau kosse...@kde.org wrote: Am Sonntag, 30. August 2015, 23:21:59 schrieb Jaroslaw Staniek: On 28 August 2015 at 19:10, Friedrich W. H. Kossebau kosse...@kde.org wrote: Hi, with KDb, KProperty and KReport, a few libs/frameworks have been already split off during the port of Calligra to Qt5/KF5. And they pose a challenge that needs to be solved quickly: traditionally we have had no ABI guarantuee in Calligra even in patch releases and of course also not during development. Because sourcecode of all libs and libconsumers were in a shared repo, and any API changes were done in atomic commits both to the libs and libconsumers (because by policy we require any commits to the repo to not break it's build). With libs and libconsumers being split in separate repos the atomicity no longer is given. Which results in problems: * people might pull from repos missing part of API change commits * current KDE CI triggered by commits will build repos without caring for dependencies between commits, using products from previous lib builds with old API for the build of libconsumer with commit using newer API * ? No idea how to solve the KDE CI one perfectly. But for the problem of pulling consistent states, what about the following rules with the split off lib repos: * no ABI breakage in patch releases for released branches * weekday of API breakage: a set day per week development branches can get commits which involve API changes in the libs in separate repos still related commits should be pushed together in an as small timewindow as possible No ABI breakage in patch releases might be a no-brainer, given that targetted 3rd-party consumers would rely on that as well. The second one would pick up something which seemed to work well enough in times where close kdelibs and kdeapps development was common, and where people also did separate svn pulls for libs and apps. Pushing related commits to all repos in small timewindows might not completely match atomic commits as possible with subversion. But in the end we all pull in time (fetch latest commits now) and not by branch state (fetch commits until xyz id), so in practice this might work as well still. What do you think? Would this work for you as well? IMHO we need to have an agreed solution here before Kexi-frameworks is merged back, because it will force us into this situation (where Plan currently does not depend on KReport, my respective patch waiting since many weeks for someone to push this question for handling of the API-break challenge and to find an agreed resolution ;) ). ((While in the discussion this is only about those 3 libs for now... My personal desire is to make the Calligra document libs more accessible to other apps, which partially do document creating/processing. For that I would see some advantage to split off more libs into own repos as well. In the long run I would like to see Calligra move out of it's own corner and integrate more with the normal KDE application scene. But more on that once we have finally passed the port hurdle, are back in normal feature development and can start talking post-3.0 (where 3.0 is now the first real release) :) )) snip part about release branches, seems general agreement and no reason to depart from usual handling Next, how to check versions. A single properly configured kdesrc-build can solve issues when people try to fetch individual repos and make human mistakes. During development you either use kdesrc-build configured to use the branch for the repos (e.g. master) I see a problem here: right now everony for the everyday development on the development branch (so not stable/release branches) does a git pull or git pull --rebase before pushing ones own commits. Because when your patch is ready to be pushed, you want to get it out and then do something else. Which you can do now. Using instead kdesrc-build or similar tools every time will add cost more time during that process. And even some seconds already are annoying, when they do not improve your developing experience. Worse, if the tool detects a new commit in one of the repos and starts a rebuild of that, perhaps even a full because some central header was touched, you will lose even more time and be even more annoyed. No, I do not see me using something which checks all repos every time I do now a git pull. And very possibly also not anyone else. On a certain day per week, where I can expect breakage, sure. But not 24/7. Todays scenario: Before pushing I am not just rebasing. It just happened to me having kexi in calligra.git: I pull --rebase and compile to double check things. Result: I had to wait compiling Krita and most of calligralibs. Perhaps even a full rebuid if someone cleaned up a top-level calligralibs header. I could just disabling
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,All,gcc - Build # 4 - Still unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/4/ Project: PLATFORM=Linux,Variation=All,compiler=gcc Date of build: Sun, 30 Aug 2015 21:08:13 + Build duration: 1 hr 3 min CHANGE SET Revision 12fdf389e2212ae38ddd1bc61ad0bb5eadd71924 by Friedrich W. H. Kossebau: (Add missing includes) change: edit libs/odf/KoDocumentBase.cpp change: edit libs/widgets/KoModeBox.cpp Revision fe4e7328c68ccaafeb96098be36a485907a7ee11 by Friedrich W. H. Kossebau: (Complete port of setting standard saveas shortcut on windows) change: edit krita/ui/kis_action_manager.cpp Revision 820cbfcbe8f9d0ed3e3e8595040807125d06becb by Friedrich W. H. Kossebau: (Fix build) change: edit krita/ui/KisView.cpp Revision 2ffbcb5427b98f7f3835ca48ec3efb91542cb552 by Friedrich W. H. Kossebau: (Port to KF5 KI18n translation system) change: edit plan/plugins/schedulers/rcps/KPlatoRCPSPlugin.cpp change: edit braindump/plugins/webshape/WebShapePlugin.cpp change: edit krita/plugins/extensions/metadataeditor/metadataeditor.rc change: edit krita/plugins/extensions/rotateimage/rotateimage.rc change: edit plugins/semanticitems/event/CMakeLists.txt change: edit flow/part/flow.rc change: edit plugins/pathshapes/CMakeLists.txt change: edit krita/plugins/extensions/shearimage/shearimage.rc change: edit sheets/plugins/calendar/CMakeLists.txt change: edit krita/plugins/extensions/bigbrother/bigbrother.rc change: edit stage/part/stage_readonly.rc change: edit plan/workpackage/planwork_readonly.rc change: edit extras/calligra/main.cpp change: edit sheets/CMakeLists.txt change: edit plugins/vectorshape/CMakeLists.txt change: edit filters/CMakeLists.txt change: edit plugins/semanticitems/contact/CMakeLists.txt change: edit plugins/kexi/spreadsheet/CMakeLists.txt change: edit plugins/staging/threedshape/CMakeLists.txt change: edit libs/main/calligra_shell.rc change: edit krita/plugins/extensions/separate_channels/imageseparate.rc change: edit plugins/artistictextshape/CMakeLists.txt change: edit krita/plugins/extensions/histogram/histogram.rc change: edit plan/plugins/schedulers/rcps/CMakeLists.txt change: edit krita/gemini/kritagemini.rc change: edit plugins/defaultTools/CMakeLists.txt change: edit plugins/colorengines/lcms2/LcmsEnginePlugin.cpp change: edit words/plugins/scripting/CMakeLists.txt change: edit plugins/colorengines/CMakeLists.txt change: edit krita/plugins/extensions/imagesize/imagesize.rc change: edit krita/plugins/extensions/offsetimage/offsetimage.rc change: edit karbon/plugins/tools/CMakeLists.txt change: edit sheets/shape/CMakeLists.txt change: edit plugins/textediting/autocorrection/CMakeLists.txt change: edit plugins/textediting/spellcheck/CMakeLists.txt change: edit libs/main/KoPart.cpp change: edit stage/CMakeLists.txt change: edit plugins/pictureshape/CMakeLists.txt change: edit plan/plugins/schedulers/tj/PlanTJPlugin.cpp change: edit stage/part/stage.rc change: edit plugins/pluginshape/CMakeLists.txt change: edit sheets/plugins/scripting/CMakeLists.txt change: edit braindump/plugins/stateshape/StateShapePlugin.cpp change: edit sheets/plugins/scripting/scripting.rc change: edit plugins/dockers/CMakeLists.txt change: edit plugins/chartshape/CMakeLists.txt change: edit krita/plugins/extensions/colorrange/colorrange.rc change: edit plugins/videoshape/CMakeLists.txt change: edit words/plugins/scripting/scripting.rc change: edit plan/plugins/scripting/CMakeLists.txt change: edit libs/widgets/KoGlobal.cpp change: edit plugins/musicshape/CMakeLists.txt change: edit words/part/author/author.rc change: edit braindump/plugins/quickstates/quickstates.rc change: edit words/part/author/author_readonly.rc change: edit sheets/sheets.rc change: edit braindump/CMakeLists.txt change: edit plugins/semanticitems/location/CMakeLists.txt change: edit plugins/textediting/thesaurus/CMakeLists.txt change: edit krita/plugins/extensions/layersplit/layersplit.rc change: edit extras/okularodpgenerator/CMakeLists.txt change: edit plan/plugins/scripting/Module.cpp change: edit plan/plugins/scripting/scripting.rc change: edit extras/okularodtgenerator/CMakeLists.txt change: edit plan/plugins/schedulers/tj/CMakeLists.txt change: edit plan/workpackage/planworksettings.kcfgc change: edit krita/plugins/extensions/gmic/gmic.rc change: edit krita/crashreporter/main.cpp change: edit braindump/data/braindumpview.rc change: edit krita/ui/kis_factory2.cc change: edit krita/plugins/extensions/clonesarray/clonesarray.rc change: edit krita/plugins/extensions/colorspaceconversion/colorspaceconversion.rc change: edit words/part/words_readonly.rc change: edit extras/converter/calligraconverter.cpp change: edit plugins/commentshape/CMakeLists.txt change: edit sheets/Localization.cpp change: edit libs/CMakeLists.txt change: edit
Re: Review Request 124883: Fix compilation of PsCommentLexer.cpp on platforms where char is unsigned
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124883/#review84612
---
Ship it!
Indeed there might be more places where this could be a problem.
If only KDE CI also had builds for ARM :)
Do you have commit rights to KDE repos? Otherwise I could commit for you.
- Friedrich W. H. Kossebau
On Aug. 22, 2015, 7:53 p.m., Tom Hall wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124883/
---
(Updated Aug. 22, 2015, 7:53 p.m.)
Review request for Calligra.
Repository: calligra
Description
---
The C standard defines char to be either signed char or unsigned char. In
this case, the char is used to store negative values to signify categories of
characters as well as actual characters. Therefore it must be a signed char
and doesn't work on platforms where char is unsigned (e.g. ARM). In this
specific case, compilation of the file fails with:
error: narrowing conversion of '-127' from 'int' to 'char' inside { }
[-Wnarrowing].
There may be similar issues elsewhere where the char isn't inside initialiser
braces, so it compiles successfully, but silently truncates or wraps the
negative values.
Diffs
-
filters/karbon/eps/PsCommentLexer.cpp 6487df6
Diff: https://git.reviewboard.kde.org/r/124883/diff/
Testing
---
Thanks,
Tom Hall
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
