Re: Retiring
On Wednesday, 13 January 2021 23:05:50 CET Milian Wolff wrote: > On Mittwoch, 13. Januar 2021 21:57:13 CET Christoph Feck wrote: > > Hello developers, > > > > my personal situation allows for much less time for KDE > > related work, at least during the Corona times. > > > > I would like to retire as soon as possible from these > > responsibilities: > > - bug triaging > > - release service > > - KIconTheme maintainer > > - KPlotting maintainer > > - KWidgetAddons maintainer > > > > For bugzilla, I see many new and old contributors doing awesome > > work with triaging, so departing here shouldn't be a big issue. > > I hope someone can continue checking responses to NEEDINFO bugs > > and REPORTED bugs that didn't get a reply within about two weeks. > > > > Regarding the release service work, I have made sure the load > > isn't all back to Albert. For future release work, Heiko Becker > > volunteered to help, but maybe another hand would be awesome, too. > > > > For the frameworks modules, I initially assumed each module > > must have a separate maintainer, so I volunteered. Today I > > see many modules still just community-maintained, and I hope > > the community can take over maintainance. Not that I did any > > relevant work here in the recent years... > > > > I might eventually continue to prepare some patches, so please > > keep all my accounts intact, but only de-list me as the maintainer. > > Thanks a lot Christoph for all your work! As I myself has had the pleasure > of quasi-retiring but never quite leaving - may the same happen to you ;-) > I.e.: Take your well earned break and come back whenever it suites you > again! +100. I can relate to that :) Thanks for all the enduring work you did for KDE, Christoph! Come back when time permits it again! Cheers, Kevin > Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: CuteHMI in kdereview
On Thursday, 13 February 2020 11:00:27 CET Michal Policht wrote: > Yeah, I neglected translations a bit... I am going to implement adequate > Qbs module for extracting translations. Heya, > When it comes to Qbs, it's not dead. Community has taken over the > project, there's active development and recent version was released just > 44 days ago. > > We migrated from QMake to Qbs, when it was still supported by Qt Company > and promoted as official build system for Qt 6. Thus we assumed Qbs is > the future. We've found that Qbs has some issues (like every software), > but in overal it's very capable and powerful piece of software. It also > provides much faster builds on Windows. I wish more people would give it > a try before burying the project, to at least see the potential. With > something like Qbs we could create a build framework with reusable > components, so that each KDE subproject could benefit from it and become > naturally integrated. I think you're beating a dead horse here. The ship has sailed. You'll be missing out on quite a bit of tooling which is implemented in KDE's Extra CMake Modules framework: https://github.com/KDE/extra-cmake-modules (part of that is all the translation handling) There's also no support for building QBS projects on KDE's CI: https://build.kde.org > It may be hard to accomplish with CMake. What exactly? I mean it's all there already. > Regards, PS: Qt's CMake-based build system just got merged into qtbase dev branch a few days ago. Regards, Kevin > Michal > > > El dilluns, 3 de febrer de 2020, a les 17:57:24 CET, Michal Policht va escriure: > >> Hello there, > >> > >> CuteHMI (https://cutehmi.kde.org/) has been moved to kdereview. > > > > It has no Messages.sh for translation extraction. > > > > Any particular reason you're using a dead build system none of our > > projects uses? > > > > Cheers, > > > > Albert > >> > >> CuteHMI is meant to be a set of tools and components that help one to > >> create QML-based HMI/SCADA software. > >> > >> The project has been started few years ago, because I couldn't find any > >> open-source, QML-based HMI/SCADA framework I could put my things into. > >> > >> Regards > >> > >> Michal Policht -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: KDiff3 craft setup
On Tuesday, 5 March 2019 21:11:11 CET Albert Astals Cid wrote: > El dimarts, 19 de febrer de 2019, a les 7:35:58 CET, Kevin Funk va escriure: > > On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote: > > > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1. > > > tar. xz > > > > > > Get some one tell me how to change where it's trying to download from. > > > KDiff3 is not part of applications and doesn't follow the same > > > versioning. > > > > Heya, > > > > Could you please reconsider that decision and check whether it's not more > > worthwhile making kdiff3 part of KDE Applications? It will save you (as > > the > > maintainer) and others (distribution packagers) a major headache. > > > > You'll be responsible for releasing kdiff3 now and in the future if you > > choose to do your own release schedule. Let me just say: It's not > > something which is particular entertaining in the long-term. Your KDiff3 > > involvement will get less eventually, and then someone else needs to take > > over releasing it -- if it's part of the KDE Apps cycle it'll be done > > automatically, no matter what. > > > > KDiff3 is not the type of application which needs its own release cycle, > > IMO, it's too small & "undynamic" [1] for that. > > Just answering now because i did ignore an email named "KDiff3 craft setup" > since i don't know anything about craft and it seems now this is being used > as some kind of agreement that KDiff3 should be moved to KDE Applications. > > Personally given KDiff3 has not had any release on its own for a long time I > would very much prefer to get a few releases on its own. > > This way new features/fixes can be released sooner if needed and not tied to > the more strict KDE Applications schedule. Well, I dont agree, but choose your pain :) This might be true for the very first few releases, but after that you'd be better off just taking part of the KDE Apps cycle. But well, I tried convincing people. /me walks away after almost ruining kdevelop.git due to releaseme script usage (which accidentally pushed tons of stale local tags [1]) and manually scp'ing tarballs to KDE FTP and now waiting for mirrors to pick up the changes. Some wasted hours which are not productive at all and which I'd never experience if there'd be an automatism in place doing all this for me. Just saying. Regards, Kevin [1] https://phabricator.kde.org/D19578 > There's also the matter of http://kdiff3.sourceforge.net/ being > outdated/wrong. Do we have a plan to fix that? > > Cheers, > Albert > > > Regards, > > Kevin > > > > > > [1] "Undynamic" in a sense that we're likely not going to see drastic UI > > changes on weekly basis which need to get out to users ASAP. At least for > > kdiff3 I'd rather have a conservative approach in that regard, since it's > > a > > complex tool by definition. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: KDiff3 craft setup
On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote: > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1.tar. > xz > > Get some one tell me how to change where it's trying to download from. > KDiff3 is not part of applications and doesn't follow the same versioning. Hey, Anyhow, to help you out on that regard: You'll want to check out craft-blueprints-kde.git, and there find the kdiff3 subfolder. You'll probably need to add a separate version.ini file there with custom versions/urls. See e.g. kmymoney/version.ini as example. Regards, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: KDiff3 craft setup
On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote: > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1.tar. > xz > > Get some one tell me how to change where it's trying to download from. > KDiff3 is not part of applications and doesn't follow the same versioning. Heya, Could you please reconsider that decision and check whether it's not more worthwhile making kdiff3 part of KDE Applications? It will save you (as the maintainer) and others (distribution packagers) a major headache. You'll be responsible for releasing kdiff3 now and in the future if you choose to do your own release schedule. Let me just say: It's not something which is particular entertaining in the long-term. Your KDiff3 involvement will get less eventually, and then someone else needs to take over releasing it -- if it's part of the KDE Apps cycle it'll be done automatically, no matter what. KDiff3 is not the type of application which needs its own release cycle, IMO, it's too small & "undynamic" [1] for that. Regards, Kevin [1] "Undynamic" in a sense that we're likely not going to see drastic UI changes on weekly basis which need to get out to users ASAP. At least for kdiff3 I'd rather have a conservative approach in that regard, since it's a complex tool by definition. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
On Friday, 26 January 2018 08:27:55 CET Kevin Ottens wrote: > Hello, > > On Thursday, 25 January 2018 22:35:37 CET Albert Astals Cid wrote: > > El dijous, 25 de gener de 2018, a les 9:01:10 CET, Kevin Ottens va escriure: > > > On Thursday, 25 January 2018 00:08:03 CET Albert Astals Cid wrote: > > > > As I did with the last person that also was confused and annoyed by > > > > all > > > > this burocracy, just ask me any question you may have. > > > > > > Oh come on... the bad mean bureaucracy argument now. Wanna look at the > > > Eclipse incubation process? Or the Apache one? > > > > Can I use the "if all your friends jump from a balcony will you do it" > > defense? > > Not really since my point was more that what we have in place is very very > far from bureaucracy not that we should replicate other's bureaucracy. If > you want an example of bureaucracy look at those friends who jump from a > balcony. ;-) > > > Seriously it's just about having a person already within the community > > > making sure the new project needs get catered to and also making sure > > > the > > > new project is on the right path to put in place rules and procedures > > > compatible with the rest of the community (and the Manifesto). > > > > But how do you find that person? You're just an 'outsider', how do you > > find > > a random person to be your incubator guy? Because as it happens, it's the > > second time in a month or something that i have to volunteer. > > Ah! That is interesting feedback. You're correct that we're currently > assuming that someone will step in to do that and that there's enough of us > and that we're responsible enough to do that when we see something we're > interested in. > > Personally for kdiff3, I'd have expected Kevin Funk to end up doing it, > indeed he was first responder with "I'd love to see kdiff3 being adopted by > KDE again". To me he sounded like a perfect sponsor. Heya, Sorry that wasn't clear from my mail. Several reasons I'd be rather not do it: I'm reaaally lacking time and focus to go through the whole process at this point; and adding to that I'm not familiar with the incubation process myself either... I just expressed that I'd love to see it happen, in general. Somehow. :) Regards, Kevin > I'd like to see that fixed. Right now, I'm not sure how, but if you're the > only one indeed caring about new projects getting in, we have a more general > community problem, it's just that the incubator makes it visible... > > I think it's much easier if we had guidelines and the rest was just "ask > > in > > kde-devel mailing list if you have further questions", > > It'd be easier, but not better. Because then it's no different than "ask the > GitHub support if you have further questions", and it's not what it's > about. > > In my previous email I mentioned this is *also* for the "sponsor" to touch > base with the joining project to verify it's getting into fruition to *be* a > KDE project (which is not just about having a repository on our > infrastructure)... I know, pesky people and culture thing. > > > and sure if you find a dedicated person for you, great, but requiring it > > feels weird, and also makes it for less scalability, as an example I > > already have an email from Michael that was sent only to me but anyone > > else in this list would have been able to answer, but he had to wait at > > least 14 hours for me to have time to answer it. > > Maybe that needs to be made clearer in the wiki? I'd expect the sponsor to > push the involved persons to ask these type of questions on public mailing > lists indeed. One on one discussions are likely to happen but they must be > the minority of the communication going on. The sponsor in that case is the > fail safe mechanism to make sure an answer indeed happens in those public > forums or trying to solve the case if no answer happened for some reason. > > Regards. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
On Wednesday, 24 January 2018 16:24:10 CET Michael Reeves wrote: > A little confused on where to start with this sponsor thing. Huh? 'sponsor thing'? :) Care to elaborate what you mean? Regards, Kevin > On Jan 19, 2018 3:52 PM, "Kevin Funk" <kf...@kde.org> wrote: > > On Wednesday, 17 January 2018 21:40:49 CET Michael Reeves wrote: > > > Yes I use this myself so I won't simply abandon it. That said I work in > > > mostly in Unix world and could use help with the windows specific > > > testing > > > although I should be able to setup a build envirionment to do basic > > > functionality testing. > > > > Heya, > > > > For that please join #kde-windows and get in touch with kfunk (me) or > > TheOneRing (Hannah von Reth) there. > > > > We could guide setting up the development environment. > > > > We use Craft to build Qt/KDE projects on Windows, read more here: > > https://community.kde.org/Craft > > > > Cheers, > > Kevin > > > > > I'll have look at what needs done. Currently working > > > on getting merging in changes from Thomas as needed. Just got through > > > bringing it up to date with Joachim's code. Real fun since it's still > > > > kde4. > > > > > On Jan 15, 2018 5:47 PM, "Albert Astals Cid" <aa...@kde.org> wrote: > > > > > > El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va > > > > > > escriure: > > > > I have a version of kdiff3 that I ported to kf5. I like to what build > > > > requirements kf5 as a whole has. Also what would be the process for > > > > being > > > > > > considered for inclusion in kde? > > > > > > So now that we have Joachim's blessing to use the name, the process is > > > basically outlined at https://community.kde.org/ > > > > Incubator/Incubation_Process > > > > > but it's basically importing the project into our git and then making > > > > sure > > > > > it > > > generally follows our rules & procedures. > > > > > > I understand you want to continue maintaining the new kdiff3 and you are > > > > not > > > > > just "dumping it" into us, right? > > > > > > > > > Cheers, > > > > > > Albert > > > > > > El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va > > > > > > escriure: > > > > Hi, > > > > > > > > You have my blessing to use the name KDiff3. > > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion
On Wednesday, 17 January 2018 21:40:49 CET Michael Reeves wrote: > Yes I use this myself so I won't simply abandon it. That said I work in > mostly in Unix world and could use help with the windows specific testing > although I should be able to setup a build envirionment to do basic > functionality testing. Heya, For that please join #kde-windows and get in touch with kfunk (me) or TheOneRing (Hannah von Reth) there. We could guide setting up the development environment. We use Craft to build Qt/KDE projects on Windows, read more here: https://community.kde.org/Craft Cheers, Kevin > I'll have look at what needs done. Currently working > on getting merging in changes from Thomas as needed. Just got through > bringing it up to date with Joachim's code. Real fun since it's still kde4. > > On Jan 15, 2018 5:47 PM, "Albert Astals Cid" <aa...@kde.org> wrote: > > El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va > > escriure: > > I have a version of kdiff3 that I ported to kf5. I like to what build > > requirements kf5 as a whole has. Also what would be the process for being > > considered for inclusion in kde? > > So now that we have Joachim's blessing to use the name, the process is > basically outlined at https://community.kde.org/Incubator/Incubation_Process > but it's basically importing the project into our git and then making sure > it > generally follows our rules & procedures. > > I understand you want to continue maintaining the new kdiff3 and you are not > just "dumping it" into us, right? > > > Cheers, > Albert > > El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va > > escriure: > > Hi, > > > > You have my blessing to use the name KDiff3. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: KDE inclusion
On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote: > I have a version of kdiff3 that I ported to kf5. I like to what build > requirements kf5 as a whole has. Also what would be the process for being > considered for inclusion in kde? Heya, Note: kdiff3 right now is hosted & developed on SourceForge. I'd love to see kdiff3 being adopted by KDE again (it former was KDE extragear if I understood correctly). kdiff3 is a super useful tool -- and right now development has stalled a bit. Talked to Joachim (the original author) a few weeks ago, where he stated he just doesn't have the time maintaining it anymore, really. I've CC'd Joachim so he can tell us whether he's okay with having kdiff3 developed further under the KDE umbrella. I don't really know the process of having it integrated either. I'll leave that to others. Kudos for doing the KF5 port! Regards, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: How is symbol visibility set in KF5 and KDE?
On Wednesday, 15 November 2017 15:54:17 CET Shaheed Haque wrote: > Hi all, > > I just realised that the Python binding effort is not setting the default > visibility for symbols using the -fvisibility=xxx option when processing > the header files [1]. Of course I can see the export macros set by the > likes of attica_exports.h, but I don't see where the compiler default is > set. Can somebody kindly point that out? It's configured in extra-cmake-modules.git: kde-modules/KDECompilerSettings.cmake 223:set(CMAKE_C_VISIBILITY_PRESET hidden) 224:set(CMAKE_CXX_VISIBILITY_PRESET hidden) 225:set(CMAKE_VISIBILITY_INLINES_HIDDEN 1) Regards, Kevin > Thanks, Shaheed > > [1] I'm also a bit mystified by the fact that I am deliberately querying > CMake for the COMPILE_FLAGS to use, but I have not seen -fvisibility > anywhere... -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
On Monday, 6 November 2017 10:03:05 CET Tomaz Canabrava wrote: > On Mon, Nov 6, 2017 at 8:31 AM, Martin Koller <kol...@aon.at> wrote: > > On Montag, 6. November 2017 01:57:32 CET Aleix Pol wrote: > > > On Fri, Nov 3, 2017 at 9:30 PM, Martin Koller <kol...@aon.at> wrote: > > > > Hi all, > > > > > > > > I'd like to announce an application I've implemented over the last few > > > > weeks - liquidshell > > > > > > liquidshell is a replacement for plasmashell > > > > > > Hi Martin, > > > I'm a bit confused, who is liquidshell for? > > > > Whoever does not like plasmashell, for whatever reason. > > My reasons are mentioned in the README or the announcement mail. > > Free software is about choice, no ? > > It is, of course. Then, it's also about non-fragmentation, and you know, > human resources are spare. > I know it's your time and your project and I will never tell you what to > do, > but considering that there's lxqt which exists basically for the same > 'whatever reasons', why not help them instead of creating yet another > desktop shell? So much +1. I'm really sad to see more fragmentation in the DE space instead of finding people investing their time helping existing projects, even more so if there's one aiming for the same goal under the KDE umbrella. You're free to work on whatever you like to of course, but to me this sounds like wasted effort. Your good incentives would be better spent with joining up with others aiming for the same (LxQt for instance). Hate to be the party pooper here, but I'm just not sure this kind of fragmentation helps KDE in the long-term, where we really have a hard time finding contributors for the majority of our *existing* projects. Regards, Kevin > > Best regards/Schöne Grüße > > > > Martin > > A: Because it breaks the logical sequence of discussion > > Q: Why is top posting bad? > > > > () ascii ribbon campaign - against html e-mail > > /\- against proprietary attachments > > > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Review Request 128854: Add a Tools button above the process list of System Monitor
> On July 31, 2017, 9:11 a.m., Kevin Funk wrote: > > processui/ksysguardprocesslist.cpp, line 354 > > <https://git.reviewboard.kde.org/r/128854/diff/3/?file=498252#file498252line354> > > > > Why this? > > Gregor Mi wrote: > When I try to capture "d", then I get the following compiler error: > > processui/ksysguardprocesslist.cpp:355:36: error: capture of non-variable > ‘KSysGuardProcessList::d’ > > I also find the current solution a bit strange. See here: > https://stackoverflow.com/questions/12944002/capture-by-value-class-members > (C++14 might solve the issue) Just capture `[this]`. `d` is visible then. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128854/#review103512 --- On Aug. 3, 2017, 11:08 a.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128854/ > --- > > (Updated Aug. 3, 2017, 11:08 a.m.) > > > Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, > Thomas Lübking, and Thomas Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > This adds a new "Tools" button to the ksysguard widget which contains entries > to related tools: > > - Run Command --> starts KRunner to execute a command > - KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts > the lightweight System Monitor which has less features) > - Info Center --> starts the Info Center which shows additional system > information > - Htop --> starts htop > - Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. > The displayed shortcut is the one set in Global Keyboard Shortcuts. > Currently, this shortcut is shown in the End Process... button tooltip but > there it is hard-coded. > > This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/ > > > Diffs > - > > CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 > processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 > > Diff: https://git.reviewboard.kde.org/r/128854/diff/ > > > Testing > --- > > - test if all tools start correctly > - check if a changed shortcut for Kill Window is shown in the tools menu (see > screenshot) > - check if for example htop is not installed that there is no menu item for it > > > File Attachments > > > screenshot of the new Tools button > > https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 128854: Add a Tools button above the process list of System Monitor
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128854/#review103512 --- Note: Didn't really check the actual changes in this diff. CMakeLists.txt (line 21) <https://git.reviewboard.kde.org/r/128854/#comment68896> libksysguard should not require Plasma, it should stay optional at best. See one line below in that CMakeLists.txt... processui/ksysguardprocesslist.cpp (line 354) <https://git.reviewboard.kde.org/r/128854/#comment68895> Why this? - Kevin Funk On July 28, 2017, 12:20 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128854/ > --- > > (Updated July 28, 2017, 12:20 p.m.) > > > Review request for KDE Base Apps, Martin Flöser, John Tapsell, Ken Vermette, > Thomas Lübking, and Thomas Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > This adds a new "Tools" button to the ksysguard widget which contains entries > to related tools: > > - Run Command --> starts KRunner to execute a command > - KSysguard --> starts KSysguard (this is useful because Ctrl+Esc only starts > the lightweight System Monitor which has less features) > - Info Center --> starts the Info Center which shows additional system > information > - Htop --> starts htop > - Kill a window (Ctrl+Alt+Esc) --> triggers the KWin kill window function. > The displayed shortcut is the one set in Global Keyboard Shortcuts. > Currently, this shortcut is shown in the End Process... button tooltip but > there it is hard-coded. > > This RR replaces this old RR https://git.reviewboard.kde.org/r/122249/ > > > Diffs > - > > CMakeLists.txt 84a447990563cf1605c06989b255627e99ef31b3 > processui/CMakeLists.txt 1927839282a6282c824f5bbb5d35ea94075f428e > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 79e9bb3c4e9d481a03d2e5992ab1c0692a06de28 > > Diff: https://git.reviewboard.kde.org/r/128854/diff/ > > > Testing > --- > > - test if all tools start correctly > - check if a changed shortcut for Kill Window is shown in the tools menu (see > screenshot) > - check if for example htop is not installed that there is no menu item for it > > > File Attachments > > > screenshot of the new Tools button > > https://git.reviewboard.kde.org/media/uploaded/files/2016/09/07/ac70c386-6665-4898-94e7-b256759f5a5e__screenshot_20160907_140935.png > > > Thanks, > > Gregor Mi > >
Re: What's kde-core-devel for?
On Thursday, 15 December 2016 22:18:31 CET Albert Astals Cid wrote: > In the old days it had kdelibs development discussion but not that that has > moved over to kde-frameworks-devel, waht's kde-core-devel for? > > Can we kill it and move parts of it to kde-devel and other parts maybe to > release-team (like adding new software to releases and such)? +1 from my side. There's tons of cross-posting to both kde-core-devel@ & kde-devel@ already happening... The only thing I still see kde-core-devel being used for is kdelibs development (reviews + CI notifications). This should get less and less by time, let's move that over to kde-devel@ until it's 'dead'. Cheers, Kevin > What do people that read this list think? > > Cheers, > Albert -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Dropping kdelibs4-based applications in KDE Applications 17.12
On Thursday, 17 November 2016 00:51:50 CET Sven Brauch wrote: > On 11/11/16 16:45, Dominik Haumann wrote: > > What do you think about having a Randa meeting (or similar) with focus > > on finishing ports to KF5? Would that make sense? > > +1 actually. There are a few applications on that list which would, in > my eyes, be a real loss if they were not maintained any more; I'm > especially looking at kcachegrind (I know of no comparable tool and it's > really good), maybe kopete. kmag is nice too on occasion but I don't > know if it will die with wayland anyways. +1 on kcachegrind, that would be a real loss. Actually there's an actively maintained frameworks branch, maybe we just need to poke Josef? ;) @Josef: Is the frameworks branch stable? If yes, let's release! > I'd be in for a sprint (or a few days of a sprint) to port those. Consider me in as well. Cheers, Kevin > Greetings, > Sven -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
api.kde.org: Logs?
Heya, I'm trying to figure out why certain KDevelop apidocs are missing from api.kde.org. Where are the logs? Someone on IRC told me there should be: http://api.kde.org/logs/ -> 404 Ideas? Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: [kde-community] Sunsetting of Infrastructure and the Phabricator migration
On Friday, March 18, 2016 7:22:03 AM CET Jeremy Whiting wrote: > Just a note so everyone doesn't need to go google/search this > themselves. To see your scratch repositories look at quickgit.kde.org > and filter by your identity name. To delete old repos, do this: > > ssh g...@git.kde.org D unlock scratch//reponame <-- > notice no .git on the end, if you put .git it will just say "You are > not authorized" > ssh g...@git.kde.org D rm scratch//reponame Thanks a lot for this! /me cleans up. Cheers, Kevin > Hope that helps, > Jeremy > > On Fri, Mar 18, 2016 at 12:46 AM, Ben Cooksley <bcooks...@kde.org> wrote: > > == This mail is considered mandatory reading for all KDE Developers. > > Please read this email in whole. == > > > > Hi all, > > > > As you'll all be aware we are currently in the process of overhauling > > our Git infrastructure, and replacing numerous elements of it. > > > > The first part of this will take place this weekend - with > > projects.kde.org being shutdown. All Git repository browsing from that > > point on should take place through quickgit.kde.org. commits.kde.org > > will also be reconfigured to redirect you exclusively to > > quickgit.kde.org. > > > > As a result the tree structure will only be available from the XML > > file from this point onward. There are no plans to replicate the tree > > structure within Phabricator (although some of the grouping it > > facilitates may be provided through a different mechanism) > > > > The XML file upon which numerous utilities (including kdesrc-build) > > depend will continue to be made available. It will instead be > > generated by a Python script periodically, based on the contents of a > > Git repository. > > > > In terms of Reviewboard, there are no plans to import it's contents > > into Phabricator, as the level of effort required is too high. Once we > > are migrated to Phabricator for reviews, i'm proposing that everyone > > has 4 weeks to finish any final reviews up within Reviewboard before > > it is set to read only by disabling login for everyone. Reviews still > > open at that point would be discarded. > > > > The contents of Kanboard will be migrated into Phabricator, more > > details will come on that over the next few weeks, including details > > of any action people needs to take. As an immediate measure it would > > be appreciated if people could conduct a general cleanup and remove > > tasks and boards they have no intention of using or revisiting in the > > future. Following this migration Kanboard will be shutdown. > > > > In terms of repositories, now would be a good time to look into the > > scratch and clone repositories you have on git.kde.org and perform a > > cleanup of any repositories which are unused, not useful or are > > otherwise no longer needed. > > > > We will be looking into how to import our repositories into > > Phabricator which will include all scratch and clone repositories. > > This means the entire content of these repositories will be indexed, > > and reducing the number of repositories will reduce the amount of > > indexing work which Phabricator needs to complete. > > > > I should also note that as a side affect of the Phabricator > > transition, scratch/clone repositories will to a certain extent cease > > to exist - everything will now be a mainline repository. As a > > consequence force pushes will be disabled for all repositories as part > > of the migration (including scratch repositories). We will be creating > > a mechanism which will allow repositories following certain naming > > conventions to be easily created by developers (although this will > > have to be done through the web interface). > > > > As part of the capabilities of Phabricator, sysadmin will also be > > extending the power to create general purpose mainline repositories > > (and certain other actions within Phabricator) to a number of > > community members. They will be contacted individually over the next > > month or two regarding this. > > > > Comments on the above are welcome (little is in concrete yet), please > > start them in appropriate sub-threads on kde-core-devel (to minimize > > cross-posting, etc). > > > > Thanks, > > Ben Cooksley > > KDE Sysadmin > > ___ > > kde-community mailing list > > kde-commun...@kde.org > > https://mail.kde.org/mailman/listinfo/kde-community -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Product versions on bugs.kde.org
On Monday, March 7, 2016 1:23:01 PM CET Kevin Funk wrote: > On Monday, March 7, 2016 11:10:13 AM CET Jonathan Riddell wrote: > > On Mon, Mar 07, 2016 at 09:25:40AM +0100, Kevin Funk wrote: > > > Is there a way to batch-modify those versions? Obviously noone wants to > > > go > > > through the Bugzilla UI, adding versions one-by-one for each(!) > > > framework. > > > /me found [1]. > > > > > > PS: It's not just the case for frameworks, same applies to KDE > > > Applications, etc. > > > > > > Cheers, > > > Kevin > > > > > > [1] > > > http://blog.asymptotic.co.uk/software-development-log/batch-modifying-bu > > > g > > > zilla-milestones/ > > > > There's no API for this, I've no idea why not. > > > > For Plasma I wrote a shell script which takes your browser cookie and > > takes > > a load of Product names and uses curl to do the calls to add the versions. > > > > https://projects.kde.org/projects/playground/sdk/releaseme/repository/revi > > si ons/master/entry/plasma/plasma-add-bugzilla-versions > > Heh, nice one! > > I'll try this out on Frameworks when I find the time. Added all versions from 5.5.0 to 5.19.0. I've used this little gem here to "hammer" BKO: http://paste.ubuntu.com/15330672/ @dfaure: Do you want me to commit that somewhere (obviously with just a single "version" instead of many), so you can simply invoke that script when releasing a new KF5 version? Cheers, Kevin > Thanks! > Kevin > > > kde:releaseme > > > > Jonathan -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Product versions on bugs.kde.org
On Monday, March 7, 2016 11:10:13 AM CET Jonathan Riddell wrote: > On Mon, Mar 07, 2016 at 09:25:40AM +0100, Kevin Funk wrote: > > Is there a way to batch-modify those versions? Obviously noone wants to go > > through the Bugzilla UI, adding versions one-by-one for each(!) framework. > > /me found [1]. > > > > PS: It's not just the case for frameworks, same applies to KDE > > Applications, etc. > > > > Cheers, > > Kevin > > > > [1] > > http://blog.asymptotic.co.uk/software-development-log/batch-modifying-bug > > zilla-milestones/ > There's no API for this, I've no idea why not. > > For Plasma I wrote a shell script which takes your browser cookie and takes > a load of Product names and uses curl to do the calls to add the versions. > > https://projects.kde.org/projects/playground/sdk/releaseme/repository/revisi > ons/master/entry/plasma/plasma-add-bugzilla-versions Heh, nice one! I'll try this out on Frameworks when I find the time. Thanks! Kevin > kde:releaseme > > Jonathan -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Product versions on bugs.kde.org
Heya, The versions of some products on bugs.kde.org are quite out of date: For example for frameworks: https://bugs.kde.org/editproducts.cgi?action=edit=frameworks-solid is at 5.9.0 https://bugs.kde.org/editproducts.cgi?action=edit=frameworks-khtml is at 5.1.0 https://bugs.kde.org/editproducts.cgi?action=edit=frameworks-ktexteditor is at 5.1.0 Is there a way to batch-modify those versions? Obviously noone wants to go through the Bugzilla UI, adding versions one-by-one for each(!) framework. /me found [1]. PS: It's not just the case for frameworks, same applies to KDE Applications, etc. Cheers, Kevin [1] http://blog.asymptotic.co.uk/software-development-log/batch-modifying-bugzilla-milestones/ -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins
On Thursday, September 10, 2015 10:36:10 PM Albert Astals Cid wrote: > We have this nice ECM module that gives us the option to compile with ASAN. > > I'd like to propose that we enable it by default in jenkins. > > This way we get all the autotests run with ASAN and potentially catch more > bugs/regressions. > > Comments? > > Cheers, > Albert Sounds good to me. We should try it out. Worth the slowdown of the ASAN-enabled programs on the CI. Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?
On Monday 31 August 2015 09:29:52 Jeremy Whiting wrote: > The way the knewstuff tests work is by linking the source files being > tested directly. For example the Entry test also links entry.cpp and > entry.h directly. This way it doesn't need to have Entry private > methods exported at all. This may or may not be the best way to do it > though, but has worked ok there and was the suggestion when I had the > same question when reenabling KNewStuff unit tests a year or so ago. Unfortunately that requires you to compile entry.cpp (at least) twice. Once for the shared lib, once for each unit test using it. Another approach is to do something CMake tried to advocate with its OBJECT libraries. It has its flaws (not going further in details), and there's a similar approach using static libraries. Taking your example further: - Compile entry.cpp and all other files part of your lib into MyStaticLib - Make test_entry.cpp link against MyStaticLib (no exports needed) - Make the MyLib shared object link against MyStaticLib The good: - entry.cpp (and all others) only need to be compiled once The bad (compared against a shared-object-only solution): - each unit tests needs to be relinked in case MyStaticLib changes We're using this approach in KDevelop plugins, successfully. Also to avoid any intermediate libs. We want the plugin to be self-contained, to reduce loading times and generally to reduce the number of installed libs. PS: This approach is not really recommendable for large-scale projects like Calligra, I guess. Having to relink every unit test if you change some central implementation file is a no-go. Having a separate export macro like Friedrich suggested initially is the better thought. > On Mon, Aug 31, 2015 at 6:41 AM, Friedrich W. H. Kossebau > > <kosse...@kde.org> wrote: > > Hi, > > > > what approach is best-practise currently for testing internal parts of > > libs? E.g. by symbols (classes) are not exported by default? > > > > In Calligra we have code that uses XYZ_TEST_EXPORT macros for those > > symbols > > which should be only exported in test-enabled builds, e.g. by defining > > COMPILING_TESTS to true and having code in the export header like > > > > #ifdef COMPILING_TESTS > > #if defined _WIN32 || defined _WIN64 > > # if defined(calligrasheetsodf_EXPORTS) > > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT > > # else > > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT > > # endif > > # else /* not windows */ > > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT > > # endif > > #else /* not compiling tests */ > > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT > > #endif > > > > But when switching to generated export headers, using cmake's > > generate_export_header macro, this seems no longer an option. > > > > Grepping for TEST_EXPORT on lxr.kde.org points that this seems an older > > approach which only might have survived in the island of Calligra :) when > > the rest of KDE world evolved to something else? > > So what are others doing? > > > > The only place lxr.kde.org pointed out to use the *TEST_EXPORT approach > > was > > grantlee, which simply creates a separate file with the define that then > > is > > appended to the file generated with generate_export_header: > > http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt > > > > Seems a working hack which we could copy. But not sure if this is the best > > way and if this should not be done more generically? > > > > Cheers > > Friedrich -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Review Request 122556: Bump Qt version to 5.4
On Feb. 13, 2015, 8:41 a.m., Martin Gräßlin wrote: AFAIK our CI system doesn't support Qt 5.4 yet. I think we should first ensure the CI system is prepared for building with the new dependency. Albert Astals Cid wrote: It does http://build.kde.org/job/kde-baseapps_master_qt5/238/consoleFull qt5 - Branch 5.4.1 Are we sure we want to depend on 5.4 just yet for such a central part of the KDE workspace? I don't know the policies, but I'm curious. Qt 5.4 is not even available on Kubuntu Vivid 15.04 yet. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122556/#review75971 --- On Feb. 13, 2015, 8:06 a.m., Arjun AK wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122556/ --- (Updated Feb. 13, 2015, 8:06 a.m.) Review request for KDE Base Apps. Repository: kde-baseapps Description --- `QUrl::fromUserInput(userInput, workingDirectory, UserInputResolutionOptions options)` seems to be Qt 5.4+. We either need to bump requirement to 5.4 or do what kompare [did](https://projects.kde.org/projects/kde/kdesdk/kompare/repository/revisions/master/entry/libdialogpages/diffpage.cpp#L45) Diffs - CMakeLists.txt 6df9015 Diff: https://git.reviewboard.kde.org/r/122556/diff/ Testing --- Thanks, Arjun AK
Re: Review Request 122534: [konq-plugins] fsview: Add missing include(ECMMarkAsTest)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122534/#review75894 --- I'd move that line to the top CMakeLists.txt. And remove the duplicate ones in other CMakeLists.txt files. - Kevin Funk On Feb. 11, 2015, 9:43 p.m., Andreas Sturmlechner wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122534/ --- (Updated Feb. 11, 2015, 9:43 p.m.) Review request for KDE Base Apps. Repository: kde-baseapps Description --- [konq-plugins] fsview: Add missing include(ECMMarkAsTest) Diffs - konq-plugins/fsview/tests/CMakeLists.txt 4ee03006999dfb62c25a36bb643f92c3078697b6 Diff: https://git.reviewboard.kde.org/r/122534/diff/ Testing --- Thanks, Andreas Sturmlechner
Re: Build dependency issues with kdesrc-build
On Friday 06 February 2015 19:46:28 Michael Pyne wrote: On Fri, February 6, 2015 15:11:22 Kevin Funk wrote: On Thursday 05 February 2015 22:16:54 Michael Pyne wrote: However as of now it only reorders modules you pull into the build list, so you still need to specify dependencies somehow. E.g. if you only asked to build plasmate, kdesrc-build wouldn't pull kdevplatform for you, but if you asked to build both kdesrc-build would do it in the right order. Question: Can't we add an option that does exactly that? Anything that'd prevent us to do so? I've been meaning to forever now. :-/ The only real catch is that you'd probably want to have a way to specify dependencies not to include, and what to do with soft deps. These are all additional features. Just start off with no way to filter deps, and don't build soft deps, rest could be implemented later. Please note that the kf5-*-build-include files with kdesrc-build are not authoritative information about what depends on what, they are very coarse groupings intended to help with high-level organization. Hm, but in fact it gives you the information about the actual package dependencies pretty precisely, no? (Otherwise the whole CI infrastructure wouldn't work -- Our CI scripts can figure out the exact dependency set needed for a build) We're talking about two different things. The CI scripts (and kdesrc-build) use data from the kde-build-metadata git module, which *is* authoritative regarding which modules depend on which. Thanks for the clarification, in fact I was thinking about kde-build-metadata for dependency information, which kdesrc-build takes advantage of. The kf5-*-build-include files come with kdesrc-build itself, and are generally used with a sample kdesrc-buildrc to tell kdesrc-build which KF5 modules to build. These files don't include dependencies per se (though the order that modules are listed is used as a hint in the absence of any other dependency information). Rather they are used to get kdesrc-build to bother with building those specific KF5 modules in the first place. Ah, okay. Didn't know that. Regards, - Michael Pyne -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Build dependency issues with kdesrc-build
On Thursday 05 February 2015 22:16:54 Michael Pyne wrote: On Tue, February 3, 2015 00:54:25 Albert Astals Cid wrote: El Dissabte, 31 de gener de 2015, a les 19:20:06, Mathieu Tarral va escriure: Hi, I noticed an issue with the plasmate component, which is build when you include kf5-workspace-build-include. It has a build dependency on KDevPlatform, but this component is only selected in kf5-applications-build-include. So should we move plasmate into Applications ? I have no idea how kdesrc-build but i'd hope/guess/expect it maps the virtual hierarchy of the repos, so probably plasmate should go to something extragear- ish that can depend on kdevlplatform just fine? But as said i know not much of kdesrc-build so i could be talking crap :D kdesrc-build will reorder modules into the right build order (assuming the needed metadata in kde-build-metadata is present). However as of now it only reorders modules you pull into the build list, so you still need to specify dependencies somehow. E.g. if you only asked to build plasmate, kdesrc-build wouldn't pull kdevplatform for you, but if you asked to build both kdesrc-build would do it in the right order. Question: Can't we add an option that does exactly that? Anything that'd prevent us to do so? Proposal: Build everything that is a dependency of the package passed to kdesrc-build. I personally would like to have this as well. A first time user (I want to hack on plasmate) could then just invoke something along: $ kdesrc-build --include-deps plasmate Please note that the kf5-*-build-include files with kdesrc-build are not authoritative information about what depends on what, they are very coarse groupings intended to help with high-level organization. Hm, but in fact it gives you the information about the actual package dependencies pretty precisely, no? (Otherwise the whole CI infrastructure wouldn't work -- Our CI scripts can figure out the exact dependency set needed for a build) You don't even need to use kf5-*-build-include, you can make your own kdesrc-buildrc that does the same thing; you can consider them as maintained sample files. Regards, - Michael Pyne -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: make uninstall
On Friday 30 January 2015 10:47:22 Alex Merry wrote: On Friday 30 January 2015 10:44:23 Alex Merry wrote: Over on kde-frameworks-devel, there have been several requests to bring back `make uninstall` for KF5 and KF5-based projects. KDELibs4 used to define this for any dependent projects (it's essentially `xargs rm install_manifest.txt` under the hood), and we could easily add it to KDECMakeSettings (with an option to disable it). We could also easily make it opt-in, either by making a separate module to define an uninstall target or by requiring projects or users to set a variable/option. I'm all for doing it opt-*out*, such as in KDE4 times. For developers, the uninstall target can be quite useful, and it'd be useless if you need to enable that on a project-by-project basis in the KDE domain. Newcomers probably don't need to know about that target, thus, if they don't know they cannot use it and cause harm to their files anyway. Also, the name uninstall indicates it's a destructive operation, so you have been warned. +1 for defining this by default Alex -- Kevin Funk | kf...@kde.org | http://kfunk.org
Re: Triggering rebuild after changing a *.json file
On Sunday 23 November 2014 17:54:21 Milian Wolff wrote:
On Sunday 23 November 2014 10:39:02 Andreas Pakulat wrote:
Hi,
On Sun, Nov 23, 2014 at 4:36 AM, Milian Wolff m...@milianw.de wrote:
Hey all,
in my quest for better *.json support in KF5 based applications, I
noticed
that we currently do not rebuild properly on changes to the *.desktop or
*.json files.
For KDevelop, I'm thus playing around with something like this
currently:
~~~+
function(kdevplatform_add_plugin plugin)
set(options )
set(oneValueArgs JSON)
set(multiValueArgs SOURCES)
cmake_parse_arguments(KDEV_ADD_PLUGIN ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN})
string(REGEX REPLACE \\.cmake$ json_out
${KDEV_ADD_PLUGIN_JSON})
configure_file(${KDEV_ADD_PLUGIN_JSON}
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
# ensure we recompile the corresponding object files when the json
file
changes
set(dependent_sources )
foreach(header ${KDEV_ADD_PLUGIN_SOURCES})
file(STRINGS ${header} match REGEX
K_PLUGIN_FACTORY_WITH_JSON)
if(match)
list(APPEND dependent_sources ${header})
endif()
endforeach()
if(NOT dependent_sources)
# fallback to all sources - better safe than sorry...
set(dependent_sources ${KDEV_ADD_PLUGIN_SOURCES})
endif()
set_property(SOURCE ${dependent_sources} APPEND PROPERTY
OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
add_library(${plugin} MODULE ${KDEV_ADD_PLUGIN_SOURCES})
set_property(TARGET ${plugin} APPEND PROPERTY AUTOGEN_TARGET_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
endfunction()
~~~+
To be used like this:
kdevplatform_add_plugin(kdevgit JSON kdevgit.json.cmake SOURCES
${kdevgit_PART_SRCS})
This does trigger a rebuild, but the strings are still not updated
properly.
I'm quite confused actually, does anyone know where the code comes from
that
is embedded into the *.o that uses Q_PLUGIN_METADATA? I suspect CMake
AUTOGEN?
But where does that put its generated binary JSON representation? How
can
I
make sure that it gets updated properly when the source file changes?
To reproduce this, you can just change any *.desktop file that is piped
through desktop_to_json. The change will be picked up by CMake and a
reconfigure is triggered, which is pretty slow as well. But nothing is
rebuilt. With the macro above, I trigger the build but still, the *.o
file
that uses K_PLUGIN_FACTORY_WITH_JSON is still containing the old
strings...
I'm at loss - can someone help me please? http://milianw.de
Is there a particular reason why you run the to-json part during cmake
time? If you setup a simple cmake script you could easily switch the
generation to be a custom target and then have the plugin depend on that
custom target (or rather its json output file).
That was apparently a side-effect of KDevelop using configure_file to embed
the version number in the *.desktop file. This is not required anymore with
the JSON-based plugin loading mechanism, as we install plugins into a
versioned directory path. I've changed this now and the CMake configure step
when changing a file is gone. Note that desktop_to_json already uses a
custom target internally.
I also think you're misunderstanding the AUTOGEN_TARGET_DEPENDS property,
according to the documentation it is to be set on an auto-generator target
and not on a 'standard' one like the library. As far as I can see you know
the input and output files of the desktop-to-json conversion so a custom
target should be easily doable (unlike automoc).
This might be true, yes. Note that I just copied that line from
desktop_to_json. But note that in the ideal case, we wouldn't have any
desktop-to-json. Rather, we just have a *.json file, a *.cpp file that uses
K_PLUGIN_FACTORY_WITH_JSON. Currently, when the *.json file is changed, the
*.cpp.o is not updated, nor the plugin *.so rebuilt and thus the new strings
are not available at runtime.
This is what we need to fix somehow, and I still don't know how. Will we
have to fix this inside CMake?
Seems like a job for OBJECT_DEPENDS... That would require you to explicitly
name the .cpp containing the K_PLUGIN_FACTORY_WITH_JSON(...) use, though.
Something along:
SET_SOURCE_FILES_PROPERTIES(myplugin.cpp
PROPERTIES OBJECT_DEPENDS myplugin.json)
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_sf%3aOBJECT_DEPENDS
Greets
PS: Thanks for providing a kdevplatform_add_plugin macro (awesome!)
--
Kevin Funk | kf...@kde.org | http://kfunk.org
Re: Triggering rebuild after changing a *.json file
On Sunday 23 November 2014 23:37:45 Kevin Funk wrote:
On Sunday 23 November 2014 17:54:21 Milian Wolff wrote:
On Sunday 23 November 2014 10:39:02 Andreas Pakulat wrote:
Hi,
On Sun, Nov 23, 2014 at 4:36 AM, Milian Wolff m...@milianw.de wrote:
Hey all,
in my quest for better *.json support in KF5 based applications, I
noticed
that we currently do not rebuild properly on changes to the *.desktop
or
*.json files.
For KDevelop, I'm thus playing around with something like this
currently:
~~~+
function(kdevplatform_add_plugin plugin)
set(options )
set(oneValueArgs JSON)
set(multiValueArgs SOURCES)
cmake_parse_arguments(KDEV_ADD_PLUGIN ${options}
${oneValueArgs}
${multiValueArgs} ${ARGN})
string(REGEX REPLACE \\.cmake$ json_out
${KDEV_ADD_PLUGIN_JSON})
configure_file(${KDEV_ADD_PLUGIN_JSON}
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
# ensure we recompile the corresponding object files when the json
file
changes
set(dependent_sources )
foreach(header ${KDEV_ADD_PLUGIN_SOURCES})
file(STRINGS ${header} match REGEX
K_PLUGIN_FACTORY_WITH_JSON)
if(match)
list(APPEND dependent_sources ${header})
endif()
endforeach()
if(NOT dependent_sources)
# fallback to all sources - better safe than sorry...
set(dependent_sources ${KDEV_ADD_PLUGIN_SOURCES})
endif()
set_property(SOURCE ${dependent_sources} APPEND PROPERTY
OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
add_library(${plugin} MODULE ${KDEV_ADD_PLUGIN_SOURCES})
set_property(TARGET ${plugin} APPEND PROPERTY
AUTOGEN_TARGET_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/${json_out})
endfunction()
~~~+
To be used like this:
kdevplatform_add_plugin(kdevgit JSON kdevgit.json.cmake SOURCES
${kdevgit_PART_SRCS})
This does trigger a rebuild, but the strings are still not updated
properly.
I'm quite confused actually, does anyone know where the code comes
from
that
is embedded into the *.o that uses Q_PLUGIN_METADATA? I suspect CMake
AUTOGEN?
But where does that put its generated binary JSON representation? How
can
I
make sure that it gets updated properly when the source file changes?
To reproduce this, you can just change any *.desktop file that is
piped
through desktop_to_json. The change will be picked up by CMake and a
reconfigure is triggered, which is pretty slow as well. But nothing is
rebuilt. With the macro above, I trigger the build but still, the *.o
file
that uses K_PLUGIN_FACTORY_WITH_JSON is still containing the old
strings...
I'm at loss - can someone help me please? http://milianw.de
Is there a particular reason why you run the to-json part during cmake
time? If you setup a simple cmake script you could easily switch the
generation to be a custom target and then have the plugin depend on that
custom target (or rather its json output file).
That was apparently a side-effect of KDevelop using configure_file to
embed
the version number in the *.desktop file. This is not required anymore
with
the JSON-based plugin loading mechanism, as we install plugins into a
versioned directory path. I've changed this now and the CMake configure
step when changing a file is gone. Note that desktop_to_json already uses
a custom target internally.
I also think you're misunderstanding the AUTOGEN_TARGET_DEPENDS
property,
according to the documentation it is to be set on an auto-generator
target
and not on a 'standard' one like the library. As far as I can see you
know
the input and output files of the desktop-to-json conversion so a custom
target should be easily doable (unlike automoc).
This might be true, yes. Note that I just copied that line from
desktop_to_json. But note that in the ideal case, we wouldn't have any
desktop-to-json. Rather, we just have a *.json file, a *.cpp file that
uses
K_PLUGIN_FACTORY_WITH_JSON. Currently, when the *.json file is changed,
the
*.cpp.o is not updated, nor the plugin *.so rebuilt and thus the new
strings are not available at runtime.
This is what we need to fix somehow, and I still don't know how. Will we
have to fix this inside CMake?
Seems like a job for OBJECT_DEPENDS... That would require you to explicitly
name the .cpp containing the K_PLUGIN_FACTORY_WITH_JSON(...) use, though.
Something along:
SET_SOURCE_FILES_PROPERTIES(myplugin.cpp
PROPERTIES OBJECT_DEPENDS myplugin.json)
Sorry for the noise. Should've read through your macro *completely*. You're
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org
Re: Review Request 118816: Don't crash konsole when a container destructs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118816/#review60449 --- Note: This is about https://bugs.kde.org/show_bug.cgi?id=331724. - Kevin Funk On June 18, 2014, 9:51 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118816/ --- (Updated June 18, 2014, 9:51 p.m.) Review request for KDE Base Apps and Eike Hein. Bugs: 331724 http://bugs.kde.org/show_bug.cgi?id=331724 Repository: konsole Description --- When containers are destructed, they emit a signal that the splitter is connected to which removes and unregisters the container from the splitter. A crash happens when the splitter is destroyed before the container, so a slot in a deleted splitter is called, tries to unregister the container, and segfaults. I added a destructor to ViewSplitter which unregisters all it's containers, this fixes the crash here on closing of a tab in yakuake and on closing a tab in konsole. Diffs - src/ViewSplitter.h c1e4552 src/ViewSplitter.cpp bfc727e src/ViewContainer.cpp 79c24d5 Diff: https://git.reviewboard.kde.org/r/118816/diff/ Testing --- Manual testing, it seems to work fine. Thanks, Jeremy Whiting
Re: Review Request 115351: Use kDebug instead of qDebug in QSpellEnchantDict
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115351/#review52053 --- Heh, the Git history looks very sad in this part of kdelibs. Noone worked on this for years now. Personally I'd just get rid off the debug output, seems like noone cares anyway. (I'm also annoyed by the useless output) - Kevin Funk On Jan. 28, 2014, 1 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115351/ --- (Updated Jan. 28, 2014, 1 p.m.) Review request for kdelibs. Repository: kdelibs Description --- Enabling automatic spell checking in Kate, I see a lot of debug output in the form of: Enchant dict for en_US 0x43a1480 This patch should fix this and only output the lines when debug output is enabled via kdebugdialog. Diffs - sonnet/plugins/enchant/enchantdict.cpp c289d26 Diff: https://git.reviewboard.kde.org/r/115351/diff/ Testing --- None actually, not even tested if it compiles. Thanks, Milian Wolff
Re: KZoneAllocator static in KCompletion crashes on exit
Am Montag, 10. Februar 2014, 01:28:03 schrieb Thomas Lübking: On Sonntag, 9. Februar 2014 22:16:16 CEST, Albert Astals Cid wrote: So while exiting krecipes i get ==15297== Invalid read of size 8 ==15297==at 0xABE051C: QString::vsprintf(char const*, __va_list_tag*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xAB87F94: qt_message(QtMsgType, char const*, __va_list_tag*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xAB88190: qDebug(char const*, ...) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xA59AC14: KZoneAllocator::~KZoneAllocator() (kallocator.cpp:110) https://git.reviewboard.kde.org/r/114715/ ? Cheers, Thomas Hey Albert, (Actually I replied much earlier, but KMail refused to send the mail somehow) It's interesting that you can reproduce this on a Linux system, I never got that far. What version of kdelibs are you running? This particular issue should indeed be fixed in v4.12.2 and KF5. The KZoneAllocator instance in KCompTreeNode got turned into 'static QSharedPointerKZoneAllocator alloc' member and KCompTreeNode instances are now keeping strong-refs to it to avoid the allocator (along its provided memory pool) being deleted too early. I also replaced the qDebug usage with printfs because I got similar crashes at shutdown. Greets -- Kevin Funk
Re: KZoneAllocator static in KCompletion crashes on exit
Am Montag, 10. Februar 2014, 20:38:15 schrieb Albert Astals Cid: El Dilluns, 10 de febrer de 2014, a les 12:14:31, Kevin Funk va escriure: Am Montag, 10. Februar 2014, 01:28:03 schrieb Thomas Lübking: On Sonntag, 9. Februar 2014 22:16:16 CEST, Albert Astals Cid wrote: So while exiting krecipes i get ==15297== Invalid read of size 8 ==15297==at 0xABE051C: QString::vsprintf(char const*, __va_list_tag*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xAB87F94: qt_message(QtMsgType, char const*, __va_list_tag*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xAB88190: qDebug(char const*, ...) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6) ==15297==by 0xA59AC14: KZoneAllocator::~KZoneAllocator() (kallocator.cpp:110) https://git.reviewboard.kde.org/r/114715/ ? Cheers, Thomas Hey Albert, (Actually I replied much earlier, but KMail refused to send the mail somehow) It's interesting that you can reproduce this on a Linux system, I never got that far. What version of kdelibs are you running? This particular issue should indeed be fixed in v4.12.2 and KF5. Actually it was only fixed for master (4.13) and KF5. I've now cherry-picked it to KDE/4.12 too since it fixes the crash i was getting. Thanks! Cheers, Albert Great, good to know! Cheers -- Kevin Funk
Re: Review Request 114715: Attempt to fix KZoneAllocator issue
On Jan. 24, 2014, 4:32 p.m., David Faure wrote: Urgh - a static object in a library? How did we not notice before... Needs to be fixed indeed. I would have used Q_GLOBAL_STATIC (which has methods like isDestroyed()), but I guess that's equivalent to your sharedpointer + strong ref idea, so why not. Where do you want me to commit this? Both to kdelibs master + kcompletion framework? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114715/#review48232 --- On Jan. 3, 2014, 5:52 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114715/ --- (Updated Jan. 3, 2014, 5:52 p.m.) Review request for kdelibs and Frank Reininghaus. Bugs: 327599 http://bugs.kde.org/show_bug.cgi?id=327599 Repository: kdelibs Description --- Attempt to fix KZoneAllocator issue kcompletion.p_h: Make the static KZoneAllocator member of KCompTreeNode a shared pointer so external users can hold a reference to it. kcompletion.cpp: Hold a reference to KCompTreeNode's KZoneAllocator instance so we avoid deleting the KZoneAllocator too early. See attached bug report for possible causes. (Hint: It crashes on Windows because ~KZoneAllocator is called to early.) kallocator.cpp: Use printf instead of qDebug(), because this code path code might be called very late during destruction and qDebug() will crash deep inside Qt. Also see discussion: http://lists.kde.org/?l=kde-develm=138583383708455w=1 BUG: 327599 CCBUG: 243375 Diffs - kdecore/util/kallocator.cpp 8b21120c62c513ea41686fe8185ec2808fe5d83a kdeui/util/kcompletion.cpp 340aa92b900d670e2ad73f70a63d5221d0feed1d kdeui/util/kcompletion_p.h 1cf31db3f16fe3421415cd54265eee20bb998710 Diff: https://git.reviewboard.kde.org/r/114715/diff/ Testing --- Thanks, Kevin Funk
Re: Coding style: block braces in switch cases
Am Montag, 13. Januar 2014, 17:05:04 schrieb Kevin Krammer:
Hi all,
at KDE PIM we are cleaning up our code base from over a decade of different
coding styles. Well, we means Guy Maurel, he does all the actual work :)
We follow the kdelibs rules which in turn are close to what Qt uses IIRC.
Now we've hit a snag. There is no common rule regarding block braces in
cases of switch statements.
All example of switch statements show that the switch block braces start at
the line of the switch condition, just like with if conditions or loops.
They also show that case is aligned with switch, i.e. no intentation.
However, there seems to be no rule how to place block braces for case
statements.
I've looked around and found quite a variation:
Interesting topic...
I always wondered about how to do it right(tm) when facing this. In this
particular case I think ruling out the variations by method of elimination is
the best way to go.
e.g. qdatetime.cpp:
switch (...) {
case Foo: {
}
}
Putting another indentation level after the 'case' statement disrupts
readability, esp. if you have other 'case' labels without curly braces.
Consider:
switch (...) {
case Foo: {
decl;
stmt;
break;
}
case Foo2:
stmt;
break;
case Foo: {
decl;
stmt;
break;
}
}
Lots of jumping between the columns when you scan for 'break' statements, for
example.
e.g. qrasterizer.cpp:
switch (...) {
case Foo:
{
}
}
e.g. qcommandlineparser.cpp:
switch (...) {
case Foo:
{
}
}
'{' on next line is not encouraged in our coding style guide. (Besides on
function implementations, after 'class', etc.)
IMO it also just wastes vertical screen space, which I dislike (subjective, of
course)
e.g. qlocale.cpp:
switch (...) {
case Foo: {
}
}
My favored variation. Considering my initial example code, this would end up
looking like:
switch (...) {
case Foo: {
decl;
stmt;
break;
}
case Foo2:
stmt;
break;
case Foo: {
decl;
stmt;
break;
}
}
The same indentation level for the '}'s is not nice, but IMO the improved
readability of the code this indentation scheme encourages is worth it. (All
'break' statements in one column, less jumping of your eye focus).
In any case, the '{' and '}' inside a case label is syntactic sugar anyway,
so it should not get into your way when reading or writing code. Your compiler
is clever enough to error out when they're missing, and it doesn't harm
(semantically) if they're redundant.
Any thoughts anyone?
Cheers,
Kevin
Just my two cents.
Greets
--
Kevin Funk
Re: Review Request 114715: Attempt to fix KZoneAllocator issue
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114715/ --- (Updated Jan. 3, 2014, 5:52 p.m.) Review request for kdelibs and Frank Reininghaus. Bugs: 327599 http://bugs.kde.org/show_bug.cgi?id=327599 Repository: kdelibs Description --- Attempt to fix KZoneAllocator issue kcompletion.p_h: Make the static KZoneAllocator member of KCompTreeNode a shared pointer so external users can hold a reference to it. kcompletion.cpp: Hold a reference to KCompTreeNode's KZoneAllocator instance so we avoid deleting the KZoneAllocator too early. See attached bug report for possible causes. (Hint: It crashes on Windows because ~KZoneAllocator is called to early.) kallocator.cpp: Use printf instead of qDebug(), because this code path code might be called very late during destruction and qDebug() will crash deep inside Qt. Also see discussion: http://lists.kde.org/?l=kde-develm=138583383708455w=1 BUG: 327599 CCBUG: 243375 Diffs - kdecore/util/kallocator.cpp 8b21120c62c513ea41686fe8185ec2808fe5d83a kdeui/util/kcompletion.cpp 340aa92b900d670e2ad73f70a63d5221d0feed1d kdeui/util/kcompletion_p.h 1cf31db3f16fe3421415cd54265eee20bb998710 Diff: https://git.reviewboard.kde.org/r/114715/diff/ Testing --- Thanks, Kevin Funk
Re: Review Request 113858: Add .reviewboardrc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113858/ --- (Updated Nov. 28, 2013, 9:35 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Repository: kdelibs Description --- Add .reviewboardrc Diffs - .reviewboardrc PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113858/diff/ Testing --- Thanks, Kevin Funk
Re: Review Request 113857: Get rid off ifdefs for windows driver kit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113857/ --- (Updated Nov. 19, 2013, 6:18 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs, Patrick Spendrin and Patrick von Reth. Repository: kdelibs Description --- Get rid off ifdefs for windows driver kit Headers are now part of kdewin As discussed with Patrick von Reth on IRC. Diffs - solid/solid/backends/win/winblock.cpp 1f4d378a9614775b4f8abe186d147189a550858c solid/solid/backends/win/windevicemanager.h b2d3c40779a60f24be498ba6e435a0c9cba1f2f8 solid/solid/backends/win/winopticaldisc.cpp c20ee43e33e20f795e814f13d7507756df394c1e solid/solid/backends/win/winopticaldrive.h ce6c2c45338edbe470ba8f040dd3a3e829073d9c solid/solid/backends/win/winopticaldrive.cpp fd87eb982a75ff2cff48f9f5ab5e13ac400d9a5e Diff: http://git.reviewboard.kde.org/r/113857/diff/ Testing --- Thanks, Kevin Funk
Review Request 113954: Remove dead code related to kompare support
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113954/ --- Review request for kdelibs. Repository: kdevplatform Description --- Remove dead code related to kompare support Never used. Minor: Code cleanup ApplyChangesWidget: Get rid off kompare support Never used, and never enabled since 2009. ApplyChangesWidget: Remove useless changes view Just clutters the view, doesn't really provide information Minor: Cleanup code Diffs - CMakeLists.txt ee6ee330078ceae283823c112f50afb6b295cc25 config-kdevplatform.h.cmake ff1db70ab10ff558f0881a31ff63b26d02f5d859 language/CMakeLists.txt 2f777e4ffab3f8b7dca814d09d9a9492861814e6 language/codegen/applychangeswidget.h d316d826d14b6118b4c40996ef0726cf788bb867 language/codegen/applychangeswidget.cpp c5c0a5c3ea4eee72b888b47d9eab84d04cb9341c language/codegen/komparesupport.h 001144ad162a3913430bc46c6d90337fc14a3327 language/codegen/komparesupport.cpp c5c04ed092e8723613a5e97ca5777cd0f2ac479f shell/CMakeLists.txt 57c5b72c3eef30e37c3a9c58016c6eb247f53e23 shell/documentcontroller.cpp 21916b359bc88ed87d2353ffccb408cf243dcf89 shell/patchdocument.h fe0d7de2d0a32c211a567a4d312de461a59d0c98 shell/patchdocument.cpp 724ce2af92882cbe336bd389e2e99b38a0c820e9 vcs/vcspluginhelper.cpp 0456aee4c1395a90d3c51009cfc1cd662afbf2c3 Diff: http://git.reviewboard.kde.org/r/113954/diff/ Testing --- Thanks, Kevin Funk
Review Request 113857: Get rid off ifdefs for windows driver kit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113857/ --- Review request for kdelibs, Patrick Spendrin and Patrick von Reth. Repository: kdelibs Description --- Get rid off ifdefs for windows driver kit Headers are now part of kdewin As discussed with Patrick von Reth on IRC. Diffs - solid/solid/backends/win/winblock.cpp 1f4d378a9614775b4f8abe186d147189a550858c solid/solid/backends/win/windevicemanager.h b2d3c40779a60f24be498ba6e435a0c9cba1f2f8 solid/solid/backends/win/winopticaldisc.cpp c20ee43e33e20f795e814f13d7507756df394c1e solid/solid/backends/win/winopticaldrive.h ce6c2c45338edbe470ba8f040dd3a3e829073d9c solid/solid/backends/win/winopticaldrive.cpp fd87eb982a75ff2cff48f9f5ab5e13ac400d9a5e Diff: http://git.reviewboard.kde.org/r/113857/diff/ Testing --- Thanks, Kevin Funk
Review Request 113858: Add .reviewboardrc
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113858/ --- Review request for kdelibs. Repository: kdelibs Description --- Add .reviewboardrc Diffs - .reviewboardrc PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113858/diff/ Testing --- Thanks, Kevin Funk
Re: Review Request 108770: Fix double-free in ~KCompositeJobPrivate
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108770/
---
(Updated Feb. 6, 2013, 11:33 a.m.)
Review request for kdelibs and Kevin Ottens.
Changes
---
Diff updated.
Description
---
Fix double-free in ~KCompositeJobPrivate
In case a subjob of KCompositeJob has been deleted, this KCompositeJob
instance will crash as soon as it is being destructed, trying to delete
this subjob again. The reason for this is that KCompositeJob::addSubjob()
does not change the ownership of @p job. So, this job could be still
deleted by ~QObject() by the original parent.
Add tests for this corner case.
This fixes a bug in KDevelop.
Backtrace:
1 0x77a3f28e in qDeleteAllQListKJob*::const_iterator
(end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322
2 qDeleteAllQListKJob* (c=QListKJob * = {...}) at
/usr/include/qt4/QtCore/qalgorithms.h:330 #3
KCompositeJobPrivate::~KCompositeJobPrivate (this=0x8849850,
__in_chrg=optimized out) at ../../kdecore/jobs/kcompositejob.cpp:29
4 0x77a3f2c9 in KCompositeJobPrivate::~KCompositeJobPrivate
(this=0x8849850, __in_chrg=optimized out) at
../../kdecore/jobs/kcompositejob.cpp:30
5 0x77a3fd70 in KJob::~KJob (this=0x880b030,
__in_chrg=optimized out) at
../../kdecore/jobs/kjob.cpp:73
6 0x71a8e5d9 in KDevelop::BuilderJob::~BuilderJob
(this=0x880b030, __in_chrg=optimized
out) at /home/krf/devel/src/kdevplatform/project/builderjob.cpp:158
BUG: 230692
REVIEW: 108770
FIXED-IN: 4.11
This addresses bug 230692.
http://bugs.kde.org/show_bug.cgi?id=230692
Diffs (updated)
-
kdecore/jobs/kcompositejob.h 6ca8eed3ebf8c6f0f5c68d8843bd09a3ea928bbd
kdecore/jobs/kcompositejob.cpp 5ddabd71e5bbb5f0a555a201223a52950b85e786
kdecore/tests/CMakeLists.txt f19e563d5d99ad2f2806140c5b21e38b20dbde0d
kdecore/tests/kcompositejobtest.h PRE-CREATION
kdecore/tests/kcompositejobtest.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/108770/diff/
Testing
---
Thanks,
Kevin Funk
Re: Review Request 108770: Fix double-free in ~KCompositeJobPrivate
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108770/
---
(Updated Feb. 6, 2013, 1:15 p.m.)
Review request for kdelibs and Kevin Ottens.
Description
---
Fix double-free in ~KCompositeJobPrivate
In case a subjob of KCompositeJob has been deleted, this KCompositeJob
instance will crash as soon as it is being destructed, trying to delete
this subjob again. The reason for this is that KCompositeJob::addSubjob()
does not change the ownership of @p job. So, this job could be still
deleted by ~QObject() by the original parent.
Add tests for this corner case.
This fixes a bug in KDevelop.
Backtrace:
1 0x77a3f28e in qDeleteAllQListKJob*::const_iterator
(end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322
2 qDeleteAllQListKJob* (c=QListKJob * = {...}) at
/usr/include/qt4/QtCore/qalgorithms.h:330 #3
KCompositeJobPrivate::~KCompositeJobPrivate (this=0x8849850,
__in_chrg=optimized out) at ../../kdecore/jobs/kcompositejob.cpp:29
4 0x77a3f2c9 in KCompositeJobPrivate::~KCompositeJobPrivate
(this=0x8849850, __in_chrg=optimized out) at
../../kdecore/jobs/kcompositejob.cpp:30
5 0x77a3fd70 in KJob::~KJob (this=0x880b030,
__in_chrg=optimized out) at
../../kdecore/jobs/kjob.cpp:73
6 0x71a8e5d9 in KDevelop::BuilderJob::~BuilderJob
(this=0x880b030, __in_chrg=optimized
out) at /home/krf/devel/src/kdevplatform/project/builderjob.cpp:158
BUG: 230692
REVIEW: 108770
FIXED-IN: 4.11
This addresses bug 230692.
http://bugs.kde.org/show_bug.cgi?id=230692
Diffs (updated)
-
kdecore/jobs/kcompositejob.h 6ca8eed3ebf8c6f0f5c68d8843bd09a3ea928bbd
kdecore/jobs/kcompositejob.cpp 5ddabd71e5bbb5f0a555a201223a52950b85e786
kdecore/tests/CMakeLists.txt f19e563d5d99ad2f2806140c5b21e38b20dbde0d
kdecore/tests/kcompositejobtest.h PRE-CREATION
kdecore/tests/kcompositejobtest.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/108770/diff/
Testing
---
Thanks,
Kevin Funk
Re: Review Request 108770: Fix double-free in ~KCompositeJobPrivate
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108770/
---
(Updated Feb. 5, 2013, 1:31 p.m.)
Review request for kdelibs.
Description
---
Fix double-free in ~KCompositeJobPrivate
In case a subjob of KCompositeJob has been deleted, this KCompositeJob
instance will crash as soon as it is being destructed, trying to delete
this subjob again.
This fixes a bug in KDevelop.
Backtrace:
1 0x77a3f28e in qDeleteAllQListKJob*::const_iterator
(end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322
2 qDeleteAllQListKJob* (c=QListKJob * = {...}) at
/usr/include/qt4/QtCore/qalgorithms.h:330 #3
KCompositeJobPrivate::~KCompositeJobPrivate (this=0x8849850,
__in_chrg=optimized out) at ../../kdecore/jobs/kcompositejob.cpp:29
4 0x77a3f2c9 in KCompositeJobPrivate::~KCompositeJobPrivate
(this=0x8849850, __in_chrg=optimized out) at
../../kdecore/jobs/kcompositejob.cpp:30
5 0x77a3fd70 in KJob::~KJob (this=0x880b030, __in_chrg=optimized out)
at
../../kdecore/jobs/kjob.cpp:73
6 0x71a8e5d9 in KDevelop::BuilderJob::~BuilderJob (this=0x880b030,
__in_chrg=optimized
out) at /home/krf/devel/src/kdevplatform/project/builderjob.cpp:158
BUG: 230692
FIXED-IN: 4.11
This addresses bug 230692.
http://bugs.kde.org/show_bug.cgi?id=230692
Diffs
-
kdecore/jobs/kcompositejob.h 6ca8eed3ebf8c6f0f5c68d8843bd09a3ea928bbd
kdecore/jobs/kcompositejob.cpp 5ddabd71e5bbb5f0a555a201223a52950b85e786
kdecore/jobs/kcompositejob_p.h bef06e9bff532b45a8d66380a65117737275be9e
Diff: http://git.reviewboard.kde.org/r/108770/diff/
Testing
---
Thanks,
Kevin Funk
Re: Review Request 108770: Fix double-free in ~KCompositeJobPrivate
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108770/
---
(Updated Feb. 5, 2013, 3:39 p.m.)
Review request for kdelibs.
Changes
---
Diff updated.
KCompositeJob::clearSubjobs() is a bit tricky. Do we want to setParent(0) all
jobs here? Can we assume that the jobs are still valid at this point?
Description (updated)
---
Fix double-free in ~KCompositeJobPrivate
In case a subjob of KCompositeJob has been deleted, this KCompositeJob
instance will crash as soon as it is being destructed, trying to delete
this subjob again. The reason for this is that KCompositeJob::addSubjob()
does not change the ownership of @p job. So, this job could be still
deleted by ~QObject() by the original parent.
Add tests for this corner case.
This fixes a bug in KDevelop.
Backtrace:
1 0x77a3f28e in qDeleteAllQListKJob*::const_iterator
(end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322
2 qDeleteAllQListKJob* (c=QListKJob * = {...}) at
/usr/include/qt4/QtCore/qalgorithms.h:330 #3
KCompositeJobPrivate::~KCompositeJobPrivate (this=0x8849850,
__in_chrg=optimized out) at ../../kdecore/jobs/kcompositejob.cpp:29
4 0x77a3f2c9 in KCompositeJobPrivate::~KCompositeJobPrivate
(this=0x8849850, __in_chrg=optimized out) at
../../kdecore/jobs/kcompositejob.cpp:30
5 0x77a3fd70 in KJob::~KJob (this=0x880b030,
__in_chrg=optimized out) at
../../kdecore/jobs/kjob.cpp:73
6 0x71a8e5d9 in KDevelop::BuilderJob::~BuilderJob
(this=0x880b030, __in_chrg=optimized
out) at /home/krf/devel/src/kdevplatform/project/builderjob.cpp:158
BUG: 230692
REVIEW: 108770
FIXED-IN: 4.11
This addresses bug 230692.
http://bugs.kde.org/show_bug.cgi?id=230692
Diffs (updated)
-
kdecore/jobs/kcompositejob.h 6ca8eed3ebf8c6f0f5c68d8843bd09a3ea928bbd
kdecore/jobs/kcompositejob.cpp 5ddabd71e5bbb5f0a555a201223a52950b85e786
kdecore/tests/CMakeLists.txt f19e563d5d99ad2f2806140c5b21e38b20dbde0d
kdecore/tests/kcompositejobtest.h PRE-CREATION
kdecore/tests/kcompositejobtest.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/108770/diff/
Testing
---
Thanks,
Kevin Funk
Review Request 108770: Fix double-free in ~KCompositeJobPrivate
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108770/
---
Review request for kdelibs.
Description
---
Fix double-free in ~KCompositeJobPrivate
In case a subjob of KCompositeJob has been deleted, this KCompositeJob
instance will crash as soon as it is being destructed, trying to delete
this subjob again.
This fixes a bug in KDevelop.
Backtrace:
1 0x77a3f28e in qDeleteAllQListKJob*::const_iterator
(end=..., begin=...) at /usr/include/qt4/QtCore/qalgorithms.h:322
2 qDeleteAllQListKJob* (c=QListKJob * = {...}) at
/usr/include/qt4/QtCore/qalgorithms.h:330 #3
KCompositeJobPrivate::~KCompositeJobPrivate (this=0x8849850,
__in_chrg=optimized out) at ../../kdecore/jobs/kcompositejob.cpp:29
4 0x77a3f2c9 in KCompositeJobPrivate::~KCompositeJobPrivate
(this=0x8849850, __in_chrg=optimized out) at
../../kdecore/jobs/kcompositejob.cpp:30
5 0x77a3fd70 in KJob::~KJob (this=0x880b030, __in_chrg=optimized out)
at
../../kdecore/jobs/kjob.cpp:73
6 0x71a8e5d9 in KDevelop::BuilderJob::~BuilderJob (this=0x880b030,
__in_chrg=optimized
out) at /home/krf/devel/src/kdevplatform/project/builderjob.cpp:158
BUG: 230692
FIXED-IN: 4.11
Diffs
-
kdecore/jobs/kcompositejob.h 6ca8eed3ebf8c6f0f5c68d8843bd09a3ea928bbd
kdecore/jobs/kcompositejob.cpp 5ddabd71e5bbb5f0a555a201223a52950b85e786
kdecore/jobs/kcompositejob_p.h bef06e9bff532b45a8d66380a65117737275be9e
Diff: http://git.reviewboard.kde.org/r/108770/diff/
Testing
---
Thanks,
Kevin Funk
Re: Review Request: make folderview compile with Qt 4.7
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104030/#review10768
---
Isn't the Q_ASSERT in the wrong block?
And I'd rather use a boolean variable indicating that the item was found, then
doing if (!success) {...} after the for loop. Avoid return statements in
deeply nested code (hard to debug).
- Kevin Funk
On Feb. 20, 2012, 5:18 p.m., Ralf Jung wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104030/
---
(Updated Feb. 20, 2012, 5:18 p.m.)
Review request for KDE Base Apps.
Description
---
Currently, kde-baseapps does not compile against Qt 4.7, in contrast to what
cmake checks. This patch fixes the only place where Qt 4.8 API was used.
Diffs
-
plasma/applets/folderview/actionoverlay.cpp 791cfdf
Diff: http://git.reviewboard.kde.org/r/104030/diff/
Testing
---
compile-tested
Thanks,
Ralf Jung
