Re: Forcing Q_SLOTS on non frameworks code
On 14/12/13 15:04, Albert Astals Cid wrote: Easy peasy. extra-cmake-modules/kde-modules/KDECompilerSettings.cmake does add_definitions(-DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII -DQT_STRICT_ITERATORS -DQT_NO_URL_CAST_FROM_STRING -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS ) I guess that'd need to be refined into something that is enabled on demand (i.e. for frameworks). I am by far a cmake expert but if you guys tell me what needs to be done I can try to make it happen. The idea of having two sets of settings, one for frameworks and one for normal applications, has come up on this list before, although I think nothing ever came of it in the end. The most obvious options are to either have a KDEFrameworkCompilerSettings module, or a cmake function called something like kf5_apply_framework_settings that would apply the relevant definitions. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forcing Q_SLOTS on non frameworks code
On Sat, Dec 14, 2013 at 3:58 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 14 de desembre de 2013, a les 14:30:14, Kevin Ottens va escriure: On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: Hi there, so here I am at the KF5 porting sprint at Barcelona trying to port libkdegames and I am realizing that I can not use code like private slots: anymore. I understand that for frameworks libraries it is interesting to have -DQT_NO_SIGNALS_SLOTS_KEYWORDS defined so we end up with code that is as widely includable from anywhere, but forcing that to the rest of the world is a bit too much if you ask me. I don't think that was intended. Can we somehow make it so that people using frameworks are not forced to add a remove_definitions so they get their code compiling? Definitely need to be fixed... we need to find what ends up activating it for everyone. I would guess you get the same thing for the implicit ascii casts? That would not be intended either. Yep, it's the same, I'll have a look to see where they come from. Cheers, Albert Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We should have a KDEFrameworkCompilerSettings.cmake file in extra-cmake-modules/kde-modules, that will have the settings we want for frameworks exclusively, then we'll have to include it from all frameworks. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPageDialog - What happened to source compatibility?
On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: I think to remember one of the goals was that the KF5 would be as source compatible as possible. Now i see that KPageDialog is not a KDialog anymore and thus setButtons, setDefaultButton, setButtonGuiItem, etc are not available in it anymore. Now, i *do* understand that for the tierization some rework was needed, otherwise you would not be able to get KPageDialog to be of tier1, but I think that either of this should have happened: a) K4PageDialog exists in kde4support for all of us that are happy not being strict about library dependenices b) KDE5PORTING.html has notes on how to port KDE4 KPageDialog to KF5 KPageDialog if it is really trivial. +1 to improve the situation. I also run into this issue during porting $stuff. Shame on me for not raising the issue like Albert did. There is an option c) add everything from kdialog marked as deprecated for source compatibility. KPageDialog is not the only affected class. In fact everything which used to derive from KDialog is affected. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 114447: Split Frameworks only definitions to a new file
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: extra-cmake-modules Description --- Don't force this extra correctness Qt flags on the rest of the people, let them decide by themselves. Diffs - kde-modules/KDEFrameworkCompilerSettings.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114447/diff/ Testing --- Installed, change kdelibs to use the new file instead of the old, all was the same. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114447: Split Frameworks only definitions to a new file
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- (Updated Dec. 14, 2013, 3:29 p.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Changes --- Correct diff ^_^ Repository: extra-cmake-modules Description --- Don't force this extra correctness Qt flags on the rest of the people, let them decide by themselves. Diffs (updated) - kde-modules/KDECompilerSettings.cmake 5f2da5e kde-modules/KDEFrameworkCompilerSettings.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114447/diff/ Testing --- Installed, change kdelibs to use the new file instead of the old, all was the same. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPageDialog - What happened to source compatibility?
El Dissabte, 14 de desembre de 2013, a les 16:30:04, Martin Graesslin va escriure: On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: I think to remember one of the goals was that the KF5 would be as source compatible as possible. Now i see that KPageDialog is not a KDialog anymore and thus setButtons, setDefaultButton, setButtonGuiItem, etc are not available in it anymore. Now, i *do* understand that for the tierization some rework was needed, otherwise you would not be able to get KPageDialog to be of tier1, but I think that either of this should have happened: a) K4PageDialog exists in kde4support for all of us that are happy not being strict about library dependenices b) KDE5PORTING.html has notes on how to port KDE4 KPageDialog to KF5 KPageDialog if it is really trivial. +1 to improve the situation. I also run into this issue during porting $stuff. Well, that means you have some experience then :) Do you think b) is achievable? I.e. how hard is to document the KDialog to QDialog uses cases in KDE5PORTING.html ? Cheers, Albert Shame on me for not raising the issue like Albert did. There is an option c) add everything from kdialog marked as deprecated for source compatibility. KPageDialog is not the only affected class. In fact everything which used to derive from KDialog is affected. Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114447: Split Frameworks only definitions to a new file
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/#review45683 --- Ship it! Ship It! - Aleix Pol Gonzalez On Dec. 14, 2013, 3:29 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- (Updated Dec. 14, 2013, 3:29 p.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: extra-cmake-modules Description --- Don't force this extra correctness Qt flags on the rest of the people, let them decide by themselves. Diffs - kde-modules/KDECompilerSettings.cmake 5f2da5e kde-modules/KDEFrameworkCompilerSettings.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114447/diff/ Testing --- Installed, change kdelibs to use the new file instead of the old, all was the same. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114447: Split Frameworks only definitions to a new file
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- (Updated Dec. 14, 2013, 3:58 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: extra-cmake-modules Description --- Don't force this extra correctness Qt flags on the rest of the people, let them decide by themselves. Diffs - kde-modules/KDECompilerSettings.cmake 5f2da5e kde-modules/KDEFrameworkCompilerSettings.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/114447/diff/ Testing --- Installed, change kdelibs to use the new file instead of the old, all was the same. Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Update extra-cmake-modules when updating kdelibs frameworks
Hi, due to the split in KDECompilerSettings and KDEFrameworkCompilerSettings that just happened you'll need to update extra-cmake-modules if you update kdelibs frameworks branch. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPageDialog - What happened to source compatibility?
On Saturday 14 December 2013 16:40:23 Albert Astals Cid wrote: El Dissabte, 14 de desembre de 2013, a les 16:30:04, Martin Graesslin va escriure: On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: I think to remember one of the goals was that the KF5 would be as source compatible as possible. Now i see that KPageDialog is not a KDialog anymore and thus setButtons, setDefaultButton, setButtonGuiItem, etc are not available in it anymore. Now, i *do* understand that for the tierization some rework was needed, otherwise you would not be able to get KPageDialog to be of tier1, but I think that either of this should have happened: a) K4PageDialog exists in kde4support for all of us that are happy not being strict about library dependenices b) KDE5PORTING.html has notes on how to port KDE4 KPageDialog to KF5 KPageDialog if it is really trivial. +1 to improve the situation. I also run into this issue during porting $stuff. Well, that means you have some experience then :) Do you think b) is achievable? I.e. how hard is to document the KDialog to QDialog uses cases in KDE5PORTING.html ? It's difficult, there are for example miss-matching signals. E.g. KDialog emits finished(), but QDialog emits finished(int). As one doesn't get a compile error for incorrect connects, this can be really annoying and I'm not sure documenting that really helps. See for example [1] for such an issue. Especially if it's somewhere underneath and one doesn't hit a compile error, it's easy to miss those connect problems. Cheers Martin [1] b7a67bab6269f8cbd61c0fa293baa659b98184f7 kdelibs Cheers, Albert Shame on me for not raising the issue like Albert did. There is an option c) add everything from kdialog marked as deprecated for source compatibility. KPageDialog is not the only affected class. In fact everything which used to derive from KDialog is affected. Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Tracking bugs in Frameworks
Hi, 2013/12/14 David Edmundson: As we gear Frameworks up for release we need a way to track bugs that exist in the new Frameworks. We have two options; either we copy all the bugs in kdelibs, triaging, testing and moving to the right new component or we start fresh. There are approximate 1400 open bugs marked against in kdelibs; many of these I think are invalid duplicates. It's not an impossible amount to triage, but it would still be a large amount of work to test and then either move or resolve them. Given we still plan to support bugs in kdelibs officially for a while yet and I personally think it would be easiest for everyone to make a new bugzilla product called Frameworks and add newly found Frameworks bugs there. an alternative would be to let every Framework have its own product. Some parts of kdelibs have had their own products for quite some time (e.g., kio and kfile), whereas others are tracked at the generic product kdelibs, or at yet other products (like konqeuror/khtml) IMHO, it would be much more transparent for bug triagers, developers, and users if there was a nice 1:1 correspondence between the split repositories/frameworks and the bugzilla products. One could argue that each repository could also be a component of the product Frameworks, but this would remove the option to define more fine-grained components for a particular framework (e.g., the current product kfile has some different components for different parts of that library). Maybe one could create a bugzilla product for each Framework (unless the product exists already, like kio). One could set up a version frameworks in each of them as long as the frameworks don't have proper versions yet. About the existing kdelibs bugs: I think they should just remain assigned to kdelibs as long as 4.x is supported. If any of these bugs is fixed, one just has to remember to forward-port the fix to the split frameworks repositories. Finally, I think it's crucial to consider the opinion of the people who do the most work at bugs.kde.org. I've CC'ed some of them because I'm not sure if they follow this mailing list. Best regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPageDialog - What happened to source compatibility?
On Saturday 14 December 2013 16:30:04 Martin Graesslin wrote: On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: I think to remember one of the goals was that the KF5 would be as source compatible as possible. Now i see that KPageDialog is not a KDialog anymore and thus setButtons, setDefaultButton, setButtonGuiItem, etc are not available in it anymore. Now, i *do* understand that for the tierization some rework was needed, otherwise you would not be able to get KPageDialog to be of tier1, but I think that either of this should have happened: a) K4PageDialog exists in kde4support for all of us that are happy not being strict about library dependenices b) KDE5PORTING.html has notes on how to port KDE4 KPageDialog to KF5 KPageDialog if it is really trivial. +1 to improve the situation. I also run into this issue during porting $stuff. Shame on me for not raising the issue like Albert did. There is an option c) add everything from kdialog marked as deprecated for source compatibility. Makes sense to me, if possible put them purely in the header file. KPageDialog is not the only affected class. In fact everything which used to derive from KDialog is affected. Yep, exactly. The KDialog - QDialog transition is unfortunately the one which introduced the most SC breakage I think. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kdelibs_frameworks_qt5 #1851
See http://build.kde.org/job/kdelibs_frameworks_qt5/1851/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Let's get in release mode!
Hello everyone, Now we're really getting there! Epics and review board are clean, thanks to everyone who helped to get there. Now it's the time to go for the last push. For that I opened what will be the last epic for the 5.0 release: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation As you can see it is split in two, one part for the tech preview, the second part for what will be needed for a final release. I urge everyone to focus on the tech preview tasks for now. Don't hesitate to give a hand to the people I put in contact for those tasks. Obviously splitting the repositories will likely come first as it was the focus for the past efforts. In particular please help Ben with the transition to the split repositories by first not pushing stuff (although if he prevents pushes in the first place you'll be the ones with patches to port ;)) and second by extensively testing the repositories once they are online. We might need several tries to get them ready, so pay attention to Ben's communication as he'll obviously coordinate that with his sysadmin super powers. Once the technology preview is tagged, then all attention will be needed on the remaining tasks to get a final release. This list looks suspiciously short to me (although some tasks are in fact rather large), so either we're in a good position already or I missed some stuff... The later being the most probable don't hesitate to add more to the list if you see fit. This list of tasks is basically our disguised definition of done for KF 5.0. If we get all the tasks done we should be able to release right away. After the technology preview we'll switch to a time based release for alphas and betas. We still have to decide on a frequency (I'm leaning toward every two weeks). It will be a good exercise to find issues in our release process and fix them before 5.0 final. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
