Re: build.kde.org: Failing ktoolbar_unittest
Hello, On Friday 11 October 2013 20:10:23 Aleix Pol wrote: On Fri, Oct 11, 2013 at 6:31 PM, Kevin Ottens er...@kde.org wrote: ktoolbar_unittest segfaults in the CI. I tried to reproduce the error here with no luck so far. If someone who manages to reproduce it or who has access to build.kde.org shell could look into it that would be nice. Should be fixed now. It was a bit tricky to reproduce (here it happened randomly), it was easily spotted by using valgrind. Excellent thanks for looking into it. And this morning we're green, yay I might make progress this week! :-) Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113205: Make KJob::result public for the new signal/slot syntax.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41670 --- Why do it just for result and not finished, suspended, resumed? We end up with both mechanisms for private signals in the same header otherwise. - Kevin Ottens On Oct. 12, 2013, 6:30 p.m., Mark Gaiser wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/ --- (Updated Oct. 12, 2013, 6:30 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. Repository: kdelibs Description --- The new signal/slot connection: connect(job, KJob::result,... does't like result to be private and throws an compile error: error: 'void KJob::result(KJob*)' is private Making it public resolves the issue and makes this slot usable in the new syntax. In my case i wanted to use the new syntax and directly use a lambda as slot. Which isn't possible on this signal if it isn't public. Diffs - tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f Diff: http://git.reviewboard.kde.org/r/113205/diff/ Testing --- Works just fine. Thanks, Mark Gaiser ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting 2013-w42 Reminder
Hello all, Just a quick reminder: The next KF5 Update Meeting will happen on #kde-devel tomorrow at 4pm Paris time. See you there! Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/#review41675 --- Yes, should have a note in KDE5Porting before going in. - Kevin Ottens On Oct. 7, 2013, 5:01 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- (Updated Oct. 7, 2013, 5:01 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). - Kevin Ottens On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/#review41679 --- tier1/itemviews/src/kcategorydrawer.h http://git.reviewboard.kde.org/r/113182/#comment30452 Wouldn't a typedef be enough? OK... would loose the DEPRECATED effect though... - Kevin Ottens On Oct. 9, 2013, 4:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- (Updated Oct. 9, 2013, 4:45 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113199: KHTML: KComponentData - KAboutData
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113199/#review41680 --- Ship it! Ship It! - Kevin Ottens On Oct. 11, 2013, 12:16 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113199/ --- (Updated Oct. 11, 2013, 12:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KComponentData - KAboutData This drops the KDE4Support dependency in KHTML. Diffs - khtml/src/java/kjavaappletviewer.h 3c3fd77 khtml/src/java/kjavaappletviewer.cpp cf6acf1 khtml/src/java/CMakeLists.txt 02efcd8 khtml/src/CMakeLists.txt dd36945 khtml/src/khtml_global.h 0d16716 khtml/src/khtml_global.cpp 4d7c6ca khtml/src/khtml_part.cpp 6e7f87e khtml/src/khtmlimage.h 9623a2a khtml/src/khtmlimage.cpp a074051 Diff: http://git.reviewboard.kde.org/r/113199/diff/ Testing --- Compiles. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113197: KMessageBox: Factorize code between regular and *WId functions
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/#review41682
---
Looks good indeed.
Maybe an idea for an improvement: What about having the internal methods use a
QScopedPointer on the dialog? It'd avoid the delete before the return, and if
someone modifies the file later on adding more such returns it reduces the risk
of missing one such delete.
Since those dialogs are exec'd anyway that should do the trick.
- Kevin Ottens
On Oct. 11, 2013, 8:56 a.m., Aurélien Gâteau wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/
---
(Updated Oct. 11, 2013, 8:56 a.m.)
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
Factorize code between regular and *WId functions, reducing the file size by
12%.
This patch adds another level of indirection. For example the sorry()
function is changed from:
void sorry(QWidget *parent, ...args)
{
QDialog *dialog = new QDialog(parent);
/* fill dialog */
}
to:
static void sorryInternal(QDialog *dialog, ...args)
{
/* fill dialog */
}
void sorry(QWidget *parent, ...args)
{
sorryInternal(new QDialog(parent), ...args);
}
This makes it possible to turn the sorryWId() function into a forward
function rather than a slightly-different copy of the original sorry()
function:
void sorryWId(WId parent_id, ...args)
{
sorryInternal(createWIdDialog(parent_id), ...args);
}
createWIdDialog() is a helper function to create a dialog which is a child of
a window belonging to another process.
Note: I kept most of the code to the place where it originally was in the
file. This keeps the diff small, but readability would be improved by
grouping together similar functions. Let me know if you think it is worth
doing so.
Diffs
-
tier1/kwidgetsaddons/src/kmessagebox.cpp 0cfa491
Diff: http://git.reviewboard.kde.org/r/113197/diff/
Testing
---
Builds, kmessageboxwidtest.cpp runs correctly. No other tests are available
though.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113158: Implement queueing directly in KDialogJobUiDelegate
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113158/#review41683 --- I'm not sold on bastardizing QErrorMessage for that feature. The intent was more to have some code similar to what KDialogQueue (moved to KDE4Support) was doing directly in KDialogJobUiDelegate implementation. - Kevin Ottens On Oct. 7, 2013, 6:28 p.m., Rohan Garg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113158/ --- (Updated Oct. 7, 2013, 6:28 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Instead of implementing queueing in KDialogJobUiDelegate, I'm making use of QErrorMessage which has queueing built into it. We also inherit the Show this message again checkbox, but I have a review request here https://codereview.qt-project.org/67243 that adds new API to Qt 5.3 , so we can hide that once 5.3 comes out ( if that makes sense ). Diffs - staging/kjobwidgets/src/kdialogjobuidelegate.h 5d17a4d staging/kjobwidgets/src/kdialogjobuidelegate.cpp 29c2bae Diff: http://git.reviewboard.kde.org/r/113158/diff/ Testing --- Tested by writing a application that uses KIO to fetch an invalid site url. Dialog pops up just fine. Thanks, Rohan Garg ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113157: Remove Nepomuk dependency from kde4support
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113157/#review41684 --- Ship it! Ship It! - Kevin Ottens On Oct. 7, 2013, 5:25 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113157/ --- (Updated Oct. 7, 2013, 5:25 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- The only class using it is KFileMetaInfoItem which is just using the ontology parts in order to get a better name for a property. It can rely on strigi instead. Diffs - staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/config-kde4support.h.cmake 95a092f staging/kde4support/src/kdebug.areas 2cabd98 staging/kde4support/src/kio/kfilemetainfoitem.cpp 9df2602 staging/kde4support/src/kio/kfilemetainfoitem_p.h 959fbd6 Diff: http://git.reviewboard.kde.org/r/113157/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113199: KHTML: KComponentData - KAboutData
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113199/ --- (Updated Oct. 14, 2013, 9:06 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- KComponentData - KAboutData This drops the KDE4Support dependency in KHTML. Diffs - khtml/src/java/kjavaappletviewer.h 3c3fd77 khtml/src/java/kjavaappletviewer.cpp cf6acf1 khtml/src/java/CMakeLists.txt 02efcd8 khtml/src/CMakeLists.txt dd36945 khtml/src/khtml_global.h 0d16716 khtml/src/khtml_global.cpp 4d7c6ca khtml/src/khtml_part.cpp 6e7f87e khtml/src/khtmlimage.h 9623a2a khtml/src/khtmlimage.cpp a074051 Diff: http://git.reviewboard.kde.org/r/113199/diff/ Testing --- Compiles. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113199: KHTML: KComponentData - KAboutData
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113199/#review41685 --- This review has been submitted with commit 1ad41d1c158091be9e7f48293e4029de768b7639 by David Edmundson to branch frameworks. - Commit Hook On Oct. 11, 2013, 12:16 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113199/ --- (Updated Oct. 11, 2013, 12:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KComponentData - KAboutData This drops the KDE4Support dependency in KHTML. Diffs - khtml/src/java/kjavaappletviewer.h 3c3fd77 khtml/src/java/kjavaappletviewer.cpp cf6acf1 khtml/src/java/CMakeLists.txt 02efcd8 khtml/src/CMakeLists.txt dd36945 khtml/src/khtml_global.h 0d16716 khtml/src/khtml_global.cpp 4d7c6ca khtml/src/khtml_part.cpp 6e7f87e khtml/src/khtmlimage.h 9623a2a khtml/src/khtmlimage.cpp a074051 Diff: http://git.reviewboard.kde.org/r/113199/diff/ Testing --- Compiles. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112730: add CMake changes to knewstuff
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/#review41686 --- knewstuff/CMakeLists.txt http://git.reviewboard.kde.org/r/112730/#comment30454 You probably need to revisit that patch, especially that part now that we started using the ALIAS feature from cmake 2.8.12. That should simplify things quite a bit. knewstuff/CMakeLists.txt http://git.reviewboard.kde.org/r/112730/#comment30453 Shouldn't be here at all. It means you'd be able to build this module independently only if you did a full build of kdelibs first anyway. Sounds like a bad idea. - Kevin Ottens On Oct. 9, 2013, 8:24 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/ --- (Updated Oct. 9, 2013, 8:24 p.m.) Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Chusslove Illich. Repository: kdelibs Description --- This makes it so I can mkdir build; cd build; cmake ../; make install from knewstuff sources. It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio libraries have been split out apparently. I'm not sure why sources had to be changed, but I had to add includes of klocalizedstring where we didn't need them before somehow. Diffs - knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a knewstuff/KNewStuffConfig.cmake.in PRE-CREATION knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 knewstuff/src/ui/entrydetailsdialog.cpp 65b75d79941d9026f368f82c7b6df91d754e0925 knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 Diff: http://git.reviewboard.kde.org/r/112730/diff/ Testing --- It builds and installs. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113226: Cleanup kdirwatch includes.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113226/#review41687 --- Ship it! Ship It! - Kevin Ottens On Oct. 13, 2013, 5:20 a.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113226/ --- (Updated Oct. 13, 2013, 5:20 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Cleanup kdirwatch includes. * kdirwatch_p.h is including inotify.h, but it doesn't use any inotify types or macros. The types are only used in kdirwatch.cpp, so I moved the inotify includes there. * kdirwatch.cpp includes sys/ioctl.h and sys/utsname.h. These headers are not available in Windows, and they are only needed if inotify is present. Thus, include them in the #if HAVE_SYS_INOTIFY_H block. Diffs - tier1/kcoreaddons/src/lib/io/kdirwatch.cpp a56801a67fd787d879ac6b300f80a20a5d054bbe tier1/kcoreaddons/src/lib/io/kdirwatch_p.h 3858bfaa68967d29327ca4319ab164af511d3186 Diff: http://git.reviewboard.kde.org/r/113226/diff/ Testing --- Compiles and tests pass on Linux. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
On Oct. 14, 2013, 8:27 a.m., Kevin Ottens wrote: tier1/itemviews/src/kcategorydrawer.h, line 228 http://git.reviewboard.kde.org/r/113182/diff/1/?file=200162#file200162line228 Wouldn't a typedef be enough? OK... would loose the DEPRECATED effect though... I tried a typedef first, it caused errors in code using it which had class KCategoryDrawerV3; ... #include kcategorydrawer.h (which had my typedef in) Giving the incredibly daft error: error: 'class KCategoryDrawerV3' has a previous declaration as 'class KCategoryDrawerV3' The inheritance seemed like the neatest solution. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/#review41679 --- On Oct. 9, 2013, 4:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- (Updated Oct. 9, 2013, 4:45 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Kevin Ottens wrote: Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. Well, avoiding that would be mean that I need to either (1) port it to Nepomuk2 and thus get a dependency to nepomuk-core or (2) remove all the Nepomuk code. If it is really required I can go with (2), though it'll be a lot more work. The nepomuk-core replacement classes are almost source compatible with the kio ones. So the port is mostly just changing the class name, and linking to the new library. Also, Konversation and Conquire (Nepomuk app) seems to be the only users of this class. KGet has been ported. Do you still want me to go with (2)? - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
On Oct. 14, 2013, 8:27 a.m., Kevin Ottens wrote: tier1/itemviews/src/kcategorydrawer.h, line 228 http://git.reviewboard.kde.org/r/113182/diff/1/?file=200162#file200162line228 Wouldn't a typedef be enough? OK... would loose the DEPRECATED effect though... David Edmundson wrote: I tried a typedef first, it caused errors in code using it which had class KCategoryDrawerV3; ... #include kcategorydrawer.h (which had my typedef in) Giving the incredibly daft error: error: 'class KCategoryDrawerV3' has a previous declaration as 'class KCategoryDrawerV3' The inheritance seemed like the neatest solution. OK, makes sense. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/#review41679 --- On Oct. 9, 2013, 4:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- (Updated Oct. 9, 2013, 4:45 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/#review41695 --- This review has been submitted with commit 9cda5f809335481dd26bf6cebb8c789b1aa6e793 by David Edmundson to branch frameworks. - Commit Hook On Oct. 9, 2013, 4:45 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- (Updated Oct. 9, 2013, 4:45 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113182: Remove all the versioned classes of KCategoryDrawer.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113182/ --- (Updated Oct. 14, 2013, 10:24 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Remove all the versioned classes of KCategoryDrawer. Remove original KCategoryDrawer and KCategoryDrawerV2 which were already deprecated and merge everything into one class which has the features of KCategoryDrawerV3 called simply KCategoryDrawer. Compatability with KCategoryDrawerV3 is left and marked as deprecated. Diffs - tier1/itemviews/src/kcategorizedview.h c8035c5 tier1/itemviews/src/kcategorizedview.cpp 35fafae tier1/itemviews/src/kcategorizedview_p.h 4c175fb tier1/itemviews/src/kcategorydrawer.h e36197b tier1/itemviews/src/kcategorydrawer.cpp 0e45e23 tier1/itemviews/tests/kcategorizedviewtest.cpp 116278c Diff: http://git.reviewboard.kde.org/r/113182/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Kevin Ottens wrote: Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. Vishesh Handa wrote: Well, avoiding that would be mean that I need to either (1) port it to Nepomuk2 and thus get a dependency to nepomuk-core or (2) remove all the Nepomuk code. If it is really required I can go with (2), though it'll be a lot more work. The nepomuk-core replacement classes are almost source compatible with the kio ones. So the port is mostly just changing the class name, and linking to the new library. Also, Konversation and Conquire (Nepomuk app) seems to be the only users of this class. KGet has been ported. Do you still want me to go with (2)? OK, I guess I miss a piece of information then: What happened to the Nepomuk API it currently uses? Did it simply disappear? if yes it means even more broken promises. :-) - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_frameworks_qt5 #1428
See http://build.kde.org/job/kdelibs_frameworks_qt5/1428/changes ___ 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 #1429
See http://build.kde.org/job/kdelibs_frameworks_qt5/1429/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113238: Remove set _LIBRARIES calls in root CMakeLists.txt
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Remove set _LIBRARIES calls in root CMakeLists.txt Update all other modules to use KF5::LibraryName Diffs - CMakeLists.txt 17c3090 kded/CMakeLists.txt 7532687 kdewidgets/CMakeLists.txt 885091e khtml/src/CMakeLists.txt 5e00c8c khtml/src/kmultipart/CMakeLists.txt 3fc6982 kio/misc/kpac/CMakeLists.txt 897de8e staging/kio/src/core/CMakeLists.txt 5d75fc9 staging/kio/src/filewidgets/CMakeLists.txt 3790250 Diff: http://git.reviewboard.kde.org/r/113238/diff/ Testing --- compiled Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 7:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in 18b6e2f tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112785/diff/ Testing --- Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113238: Remove set _LIBRARIES calls in root CMakeLists.txt
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/#review41699 --- Ship it! Also consider (separately) removing the _LIBRARIES variables from the Config files, so that there is one consistent way to use a KF5 framework (KF5::Solid, not Solid_LIBRARIES). kde-workspace and plasma currently mix both and should be normalized first, obviously. - Stephen Kelly On Oct. 14, 2013, 10:43 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/ --- (Updated Oct. 14, 2013, 10:43 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove set _LIBRARIES calls in root CMakeLists.txt Update all other modules to use KF5::LibraryName Diffs - CMakeLists.txt 17c3090 kded/CMakeLists.txt 7532687 kdewidgets/CMakeLists.txt 885091e khtml/src/CMakeLists.txt 5e00c8c khtml/src/kmultipart/CMakeLists.txt 3fc6982 kio/misc/kpac/CMakeLists.txt 897de8e staging/kio/src/core/CMakeLists.txt 5d75fc9 staging/kio/src/filewidgets/CMakeLists.txt 3790250 Diff: http://git.reviewboard.kde.org/r/113238/diff/ Testing --- compiled Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
Hello, On Thursday 03 October 2013 18:15:22 John Layt wrote: KDateTimeEdit - My new widget to replace many local widgets, added in last kdelibs release - Can replace KDateComboBox, KTimeComboBox, api is almost the same - Not used anywhere!?! - API uses QDate, QTime, KDateTime, KCalendarSystem, KTimeZone - Suggest: Port to Qt5 - KDE4 era apps can start pre-porting? - Or add to Qt? KDateTimeWidget - Used 8 times - API uses QDateTime - Poor UX - Suggest: kde4support, replace with KDateTimeEdit Giving it a closer look, I'm wondering: are you sure about this course of action? KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted together. So deprecating those two without deprecating KDateTimeEdit sounds weird to me... In particular internally it could/should use KDateEdit (which is forked several times and not in kdelibs ATM) which is a much more interesting widget. At that point I would be tempted to move KDateTimeEdit to kde4support too as it's not used anyway and push people toward using stock Qt widgets to their date/time needs. It means the only two widgets we would save from the kde4support fate are KDatePicker and later on KDateEdit (once all its forks are merged or we pick one implementation from the lot). Opinion? Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 7:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in 18b6e2f tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112785/diff/ Testing --- Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113237: Move KInit to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KInit to tier3 Diffs - CMakeLists.txt 17c3090 staging/CMakeLists.txt a3bfaab staging/kinit/CMakeLists.txt staging/kinit/ConfigureChecks.cmake staging/kinit/Info.plist.template staging/kinit/KInitConfig.cmake staging/kinit/KInitMacros.cmake 67d24dd staging/kinit/Mainpage.dox staging/kinit/README staging/kinit/README.autostart staging/kinit/README.wrapper staging/kinit/kde5init_dummy.cpp.in staging/kinit/kde5init_win32lib_dummy.cpp.in staging/kinit/src/CMakeLists.txt 12d1590 staging/kinit/src/config-kdeinit.h.cmake staging/kinit/src/kdeinit/CMakeLists.txt staging/kinit/src/kdeinit/kinit.cpp staging/kinit/src/kdeinit/kinit_win.cpp staging/kinit/src/kdeinit/proctitle.h staging/kinit/src/kdeinit/proctitle.cpp staging/kinit/src/kioslave/CMakeLists.txt staging/kinit/src/kioslave/kioslave.cpp staging/kinit/src/klauncher/CMakeLists.txt staging/kinit/src/klauncher/autostart.h staging/kinit/src/klauncher/autostart.cpp staging/kinit/src/klauncher/klauncher.h staging/kinit/src/klauncher/klauncher.cpp staging/kinit/src/klauncher/klauncher_adaptor.h staging/kinit/src/klauncher/klauncher_adaptor.cpp staging/kinit/src/klauncher/klauncher_main.cpp staging/kinit/src/klauncher_cmds.h staging/kinit/src/klauncher_cmds.cpp staging/kinit/src/kshell/CMakeLists.txt staging/kinit/src/kshell/shell.cpp staging/kinit/src/kwrapper/CMakeLists.txt staging/kinit/src/kwrapper/kwrapper.cpp staging/kinit/src/kwrapper/kwrapper_win.cpp staging/kinit/src/start_kdeinit/CMakeLists.txt staging/kinit/src/start_kdeinit/start_kdeinit.c staging/kinit/src/start_kdeinit/start_kdeinit_wrapper.c staging/kinit/src/wrapper.cpp tier3/CMakeLists.txt 4f5c1c8 Diff: http://git.reviewboard.kde.org/r/113237/diff/ Testing --- Builds, tests pass. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Kevin Ottens wrote: Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. Vishesh Handa wrote: Well, avoiding that would be mean that I need to either (1) port it to Nepomuk2 and thus get a dependency to nepomuk-core or (2) remove all the Nepomuk code. If it is really required I can go with (2), though it'll be a lot more work. The nepomuk-core replacement classes are almost source compatible with the kio ones. So the port is mostly just changing the class name, and linking to the new library. Also, Konversation and Conquire (Nepomuk app) seems to be the only users of this class. KGet has been ported. Do you still want me to go with (2)? Kevin Ottens wrote: OK, I guess I miss a piece of information then: What happened to the Nepomuk API it currently uses? Did it simply disappear? if yes it means even more broken promises. :-) The Nepomuk API that was originally in kdelibs/nepomuk was removed very long ago. The code now lives in nepomuk-core and nepomuk-widgets. We almost maintain source compatibility (minus some small things). - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Failing Tests in Kross
Minor update - Sebastian Sauer's email does not seem to be working. I've tried contacting him via twitter. Lets see. If anyone knows how to contact him, please inform me. -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113046: Move kconfigwidgets to tier3
On Wednesday 02 October 2013 15:09:35 Aurélien Gâteau wrote: On Wednesday 02 October 2013 14:48:45 Stephen Kelly wrote: Aurélien Gâteau wrote: On Wednesday 02 October 2013 12:06:57 Stephen Kelly wrote: Aurélien Gâteau wrote: I don't have any strong opinion on this, but if we allow tier2 frameworks to depend on other tier2 frameworks then is there a need for tier3 at all? Your wiki pages seems to indicate there is no need for it. That wiki page predates the Randa meeting, where some stuff was made more- concrete. I don't know of any reason to not let tier2 depend on tier2 though. Still, what would be the difference between tier2 and tier3 if tier2 frameworks were allowed to depend on other tier2 frameworks? I don't know. I don't see any benefit of 3 tiers instead of 2. I'd collapse tier3 into tier2 if it was my decision :). I agree with this, but I think you should start a separate thread to discuss this topic, otherwise it is going to be missed by David, Kevin and others. For the record, I strongly disagree with this. It's one of the design decisions taken during Platform 11 that I think should survive (some other we changed along the way of course). The tiers are here to give information to third parties using our frameworks. Why three for the number of tiers and not two or twenty? It's almost arbitrary of course. Three is an interesting sweet spot from a third parties perspective as it gives a gradual picture of the dependency tree depth you pull while at the same time not overdoing it. At one point conveying the dependency tree depth doesn't bring value anymore hence why it should be kept low. OTOH, with one or two you loose the gradual effect (I lack a better word here) completely. So yes, this choice in the number of tiers is mostly for communication with outsiders purpose and marketing (tier 1 easy to reuse, tier 2 a bit more deps but manageable still, tier 3 be ready to be motivated to bring them in your project). Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Kevin Ottens wrote: Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. Vishesh Handa wrote: Well, avoiding that would be mean that I need to either (1) port it to Nepomuk2 and thus get a dependency to nepomuk-core or (2) remove all the Nepomuk code. If it is really required I can go with (2), though it'll be a lot more work. The nepomuk-core replacement classes are almost source compatible with the kio ones. So the port is mostly just changing the class name, and linking to the new library. Also, Konversation and Conquire (Nepomuk app) seems to be the only users of this class. KGet has been ported. Do you still want me to go with (2)? Kevin Ottens wrote: OK, I guess I miss a piece of information then: What happened to the Nepomuk API it currently uses? Did it simply disappear? if yes it means even more broken promises. :-) Vishesh Handa wrote: The Nepomuk API that was originally in kdelibs/nepomuk was removed very long ago. The code now lives in nepomuk-core and nepomuk-widgets. We almost maintain source compatibility (minus some small things). OK, so that's what I had in mind. It means the API used by those classes in kde4support you're trying to remove is still there for their consumption, so why not just let them alone? I don't see the benefit of removing them or porting them to something different, it'll just create more build errors to code built against kf5, making ports harder. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 7:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in 18b6e2f tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112785/diff/ Testing --- Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 12:37 p.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Stephen Kelly wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. Right, a preprocessor macro. And I meant setting it by implementing the -define option in uic, rather than the more specific -domain. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui with explicit -tr option (and -include unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then ki18n_qt5_wrap_ui is not needed indeed. - Chusslove --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 9:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 9:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable from within kdelibs, i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect one more thing is needed to make it work from within kdelibs builds. Diffs - tier2/ki18n/CMakeLists.txt d0ed448 tier2/ki18n/KI18nConfig.cmake.in
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Stephen Kelly wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. Chusslove Illich wrote: Right, a preprocessor macro. And I meant setting it by implementing the -define option in uic, rather than the more specific -domain. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui with explicit -tr option (and -include unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then ki18n_qt5_wrap_ui is not needed indeed. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui That would also not be needed. The required options to uic would be used simply by linking to KI18n. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/ --- (Updated Sept. 17, 2013, 7:56 p.m.) Review request for KDE Frameworks and Alexander Neundorf. Repository: kdelibs Description --- It builds and installs, but doesn't seem to be usable
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 12:37 p.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Stephen Kelly wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. Chusslove Illich wrote: Right, a preprocessor macro. And I meant setting it by implementing the -define option in uic, rather than the more specific -domain. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui with explicit -tr option (and -include unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then ki18n_qt5_wrap_ui is not needed indeed. Stephen Kelly wrote: But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui That would also not be needed. The required options to uic would be used simply by linking to KI18n. So, one must be able to set two things. Add the TRANSLATION_DOMAIN macro; this can be done by add_definitions. Choose whether -tr tr2i18n or -tr tr2xi18n is issued to uic; how can this be done? - Chusslove --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/#review40518 --- On Sept. 17, 2013, 9:56 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112785/
Re: Review Request 113197: KMessageBox: Factorize code between regular and *WId functions
On Oct. 14, 2013, 11 a.m., Kevin Ottens wrote:
Looks good indeed.
Maybe an idea for an improvement: What about having the internal methods
use a QScopedPointer on the dialog? It'd avoid the delete before the
return, and if someone modifies the file later on adding more such returns
it reduces the risk of missing one such delete.
Since those dialogs are exec'd anyway that should do the trick.
Sounded like a good idea, but it does not work because createKMessageBox()
deletes the dialog itself. This causes a double-delete when leaving the
internal method. Since one can't pass a QScopedPointer as argument to turn
createKMessageBox() into a sink method, it cannot work.
- Aurélien
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/#review41682
---
On Oct. 11, 2013, 10:56 a.m., Aurélien Gâteau wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/
---
(Updated Oct. 11, 2013, 10:56 a.m.)
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
Factorize code between regular and *WId functions, reducing the file size by
12%.
This patch adds another level of indirection. For example the sorry()
function is changed from:
void sorry(QWidget *parent, ...args)
{
QDialog *dialog = new QDialog(parent);
/* fill dialog */
}
to:
static void sorryInternal(QDialog *dialog, ...args)
{
/* fill dialog */
}
void sorry(QWidget *parent, ...args)
{
sorryInternal(new QDialog(parent), ...args);
}
This makes it possible to turn the sorryWId() function into a forward
function rather than a slightly-different copy of the original sorry()
function:
void sorryWId(WId parent_id, ...args)
{
sorryInternal(createWIdDialog(parent_id), ...args);
}
createWIdDialog() is a helper function to create a dialog which is a child of
a window belonging to another process.
Note: I kept most of the code to the place where it originally was in the
file. This keeps the diff small, but readability would be improved by
grouping together similar functions. Let me know if you think it is worth
doing so.
Diffs
-
tier1/kwidgetsaddons/src/kmessagebox.cpp 0cfa491
Diff: http://git.reviewboard.kde.org/r/113197/diff/
Testing
---
Builds, kmessageboxwidtest.cpp runs correctly. No other tests are available
though.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113205: Make KJob::result public for the new signal/slot syntax.
On Oct. 14, 2013, 6:47 a.m., Kevin Ottens wrote: Why do it just for result and not finished, suspended, resumed? We end up with both mechanisms for private signals in the same header otherwise. Will do. Will update this patch shortly. - Mark --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41670 --- On Oct. 12, 2013, 6:30 p.m., Mark Gaiser wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/ --- (Updated Oct. 12, 2013, 6:30 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. Repository: kdelibs Description --- The new signal/slot connection: connect(job, KJob::result,... does't like result to be private and throws an compile error: error: 'void KJob::result(KJob*)' is private Making it public resolves the issue and makes this slot usable in the new syntax. In my case i wanted to use the new syntax and directly use a lambda as slot. Which isn't possible on this signal if it isn't public. Diffs - tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f Diff: http://git.reviewboard.kde.org/r/113205/diff/ Testing --- Works just fine. Thanks, Mark Gaiser ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote: I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly. Jeremy Whiting wrote: well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui. Kevin Ottens wrote: Could you please look into it? Chusslove Illich wrote: This is why I asked Jeremy in the other review, that motivated this one, to commit using the plain qt5_wrap_ui, until I get to doing the proper thing for k18n_wrap_ui. Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I would call it k18n_qt5_wrap_ui. If uic would have some additional command line options, k18n_wrap_ui would internally really be a wrapper for qt5_wrap_ui; but without these options, it may end up just copying the code (little as there is) from qt5_wrap_ui and adding its own stuff atop. k18n_qt5_wrap_ui must also have its own macro options to support the new/ modified ki18n functionality (namely setting the translation domain and activating the KUIT markup processing). Jeremy Whiting wrote: Ok, I'll leave this alone for now, and just #include klocalizedstring.h where we were depending on that being added to the ui_*.h files before. Kevin Ottens wrote: Is this patch abandoned or it'll see another revision soon? Chusslove Illich wrote: It should see another revision soon, from me. Or maybe that should be another review (different submitter)? The topic is the same... Stephen Kelly wrote: Actually, uic should get a command line option to add an include. Then no macro will be needed at all (with the next CMake release - CMake 3.0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b All that would be needed is set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h) in KI18nConfig.cmake. Aleix Pol Gonzalez wrote: Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied. Stephen Kelly wrote: Projects which use KI18nConfig.cmake do though, yesno? Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution. Chusslove Illich wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like: ki18n_qt5_wrap_ui(outfilevar [DOMAIN domain] [KUIT] uifiles...) and internally call uic with proper options. For example: ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN foolib KUIT fooconfig.ui foo.ui ... ) Before uic gets these options, ki18n_qt5_wrap_ui would internally do what qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4). Stephen Kelly wrote: Another needed option to uic is to define a macro, for setting TRANSLATION_DOMAIN in library code. Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right? I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first. Chusslove Illich wrote: Right, a preprocessor macro. And I meant setting it by implementing the -define option in uic, rather than the more specific -domain. But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui with explicit -tr option (and -include unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then ki18n_qt5_wrap_ui is not needed indeed. Stephen Kelly wrote: But how to set all this information is just a matter of convenience. If add_definitions plus qt5_wrap_ui That would also not be needed. The required options to uic would be used simply by linking to KI18n. Chusslove Illich wrote: So, one must be able to set two things. Add the TRANSLATION_DOMAIN macro; this can be done by add_definitions. Choose whether -tr tr2i18n or -tr tr2xi18n is issued to uic; how can this be done? I think there's no need for the add_definitions. We would add something like this to ki18n: set_property(TARGET KI18n PROPERTY INTERFACE_AUTOUIC_OPTIONS -include klocalizedstring -tr tr2i18n -define TRANSLATION_DOMAIN=$TARGET_PROPERTY:NAME) Additionally, if the TRANSLATION_DOMAIN is needed in c++ code that I write as a developer, we should this to ki18n: set_property(TARGET KI18n PROPERTY INTERFACE_COMPILE_DEFINITIONS
Re: Review Request 113205: Make KJob's finished/suspend/resume/result signals public for the new signal/slot syntax.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/ --- (Updated Oct. 14, 2013, 12:46 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. Summary (updated) - Make KJob's finished/suspend/resume/result signals public for the new signal/slot syntax. Repository: kdelibs Description --- The new signal/slot connection: connect(job, KJob::result,... does't like result to be private and throws an compile error: error: 'void KJob::result(KJob*)' is private Making it public resolves the issue and makes this slot usable in the new syntax. In my case i wanted to use the new syntax and directly use a lambda as slot. Which isn't possible on this signal if it isn't public. Diffs (updated) - tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f Diff: http://git.reviewboard.kde.org/r/113205/diff/ Testing --- Works just fine. Thanks, Mark Gaiser ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113205: Make KJob's finished/suspend/resume/result signals public for the new signal/slot syntax.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41714 --- Ship it! tier1/kcoreaddons/src/lib/jobs/kjob.h http://git.reviewboard.kde.org/r/113205/#comment30463 I wonder if the Qt/kdelibs coding style has something about indentation of pre-processor directives, I would have expected this to be left-aligned on column 0. - David Faure On Oct. 14, 2013, 12:46 p.m., Mark Gaiser wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/ --- (Updated Oct. 14, 2013, 12:46 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. Repository: kdelibs Description --- The new signal/slot connection: connect(job, KJob::result,... does't like result to be private and throws an compile error: error: 'void KJob::result(KJob*)' is private Making it public resolves the issue and makes this slot usable in the new syntax. In my case i wanted to use the new syntax and directly use a lambda as slot. Which isn't possible on this signal if it isn't public. Diffs - tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f Diff: http://git.reviewboard.kde.org/r/113205/diff/ Testing --- Works just fine. Thanks, Mark Gaiser ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113205: Make KJob's finished/suspend/resume/result signals public for the new signal/slot syntax.
On Oct. 14, 2013, 12:52 p.m., David Faure wrote: tier1/kcoreaddons/src/lib/jobs/kjob.h, line 372 http://git.reviewboard.kde.org/r/113205/diff/3/?file=201072#file201072line372 I wonder if the Qt/kdelibs coding style has something about indentation of pre-processor directives, I would have expected this to be left-aligned on column 0. Do you want me to left align it for the commit? Both are OK with me, this simply looked better :) - Mark --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/#review41714 --- On Oct. 14, 2013, 12:46 p.m., Mark Gaiser wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113205/ --- (Updated Oct. 14, 2013, 12:46 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Kevin Ottens. Repository: kdelibs Description --- The new signal/slot connection: connect(job, KJob::result,... does't like result to be private and throws an compile error: error: 'void KJob::result(KJob*)' is private Making it public resolves the issue and makes this slot usable in the new syntax. In my case i wanted to use the new syntax and directly use a lambda as slot. Which isn't possible on this signal if it isn't public. Diffs - tier1/kcoreaddons/src/lib/jobs/kjob.h d663530 tier1/kcoreaddons/src/lib/jobs/kjob.cpp f99a99f Diff: http://git.reviewboard.kde.org/r/113205/diff/ Testing --- Works just fine. Thanks, Mark Gaiser ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113197: KMessageBox: Factorize code between regular and *WId functions
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/#review41728
---
This review has been submitted with commit
d16abdc34489e19d67145b58a3ece1c8f4c42e96 by Aurélien Gâteau to branch
frameworks.
- Commit Hook
On Oct. 11, 2013, 8:56 a.m., Aurélien Gâteau wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/
---
(Updated Oct. 11, 2013, 8:56 a.m.)
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
Factorize code between regular and *WId functions, reducing the file size by
12%.
This patch adds another level of indirection. For example the sorry()
function is changed from:
void sorry(QWidget *parent, ...args)
{
QDialog *dialog = new QDialog(parent);
/* fill dialog */
}
to:
static void sorryInternal(QDialog *dialog, ...args)
{
/* fill dialog */
}
void sorry(QWidget *parent, ...args)
{
sorryInternal(new QDialog(parent), ...args);
}
This makes it possible to turn the sorryWId() function into a forward
function rather than a slightly-different copy of the original sorry()
function:
void sorryWId(WId parent_id, ...args)
{
sorryInternal(createWIdDialog(parent_id), ...args);
}
createWIdDialog() is a helper function to create a dialog which is a child of
a window belonging to another process.
Note: I kept most of the code to the place where it originally was in the
file. This keeps the diff small, but readability would be improved by
grouping together similar functions. Let me know if you think it is worth
doing so.
Diffs
-
tier1/kwidgetsaddons/src/kmessagebox.cpp 0cfa491
Diff: http://git.reviewboard.kde.org/r/113197/diff/
Testing
---
Builds, kmessageboxwidtest.cpp runs correctly. No other tests are available
though.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113197: KMessageBox: Factorize code between regular and *WId functions
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113197/
---
(Updated Oct. 14, 2013, 2 p.m.)
Status
--
This change has been marked as submitted.
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
Factorize code between regular and *WId functions, reducing the file size by
12%.
This patch adds another level of indirection. For example the sorry() function
is changed from:
void sorry(QWidget *parent, ...args)
{
QDialog *dialog = new QDialog(parent);
/* fill dialog */
}
to:
static void sorryInternal(QDialog *dialog, ...args)
{
/* fill dialog */
}
void sorry(QWidget *parent, ...args)
{
sorryInternal(new QDialog(parent), ...args);
}
This makes it possible to turn the sorryWId() function into a forward function
rather than a slightly-different copy of the original sorry() function:
void sorryWId(WId parent_id, ...args)
{
sorryInternal(createWIdDialog(parent_id), ...args);
}
createWIdDialog() is a helper function to create a dialog which is a child of a
window belonging to another process.
Note: I kept most of the code to the place where it originally was in the file.
This keeps the diff small, but readability would be improved by grouping
together similar functions. Let me know if you think it is worth doing so.
Diffs
-
tier1/kwidgetsaddons/src/kmessagebox.cpp 0cfa491
Diff: http://git.reviewboard.kde.org/r/113197/diff/
Testing
---
Builds, kmessageboxwidtest.cpp runs correctly. No other tests are available
though.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113238: Remove set _LIBRARIES calls in root CMakeLists.txt
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/#review41729 --- This review has been submitted with commit 884a0ff9a25973be6d0cbd6c973ccbcfa7c53673 by David Edmundson to branch frameworks. - Commit Hook On Oct. 14, 2013, 10:43 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/ --- (Updated Oct. 14, 2013, 10:43 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove set _LIBRARIES calls in root CMakeLists.txt Update all other modules to use KF5::LibraryName Diffs - CMakeLists.txt 17c3090 kded/CMakeLists.txt 7532687 kdewidgets/CMakeLists.txt 885091e khtml/src/CMakeLists.txt 5e00c8c khtml/src/kmultipart/CMakeLists.txt 3fc6982 kio/misc/kpac/CMakeLists.txt 897de8e staging/kio/src/core/CMakeLists.txt 5d75fc9 staging/kio/src/filewidgets/CMakeLists.txt 3790250 Diff: http://git.reviewboard.kde.org/r/113238/diff/ Testing --- compiled Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113238: Remove set _LIBRARIES calls in root CMakeLists.txt
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113238/ --- (Updated Oct. 14, 2013, 2:07 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Remove set _LIBRARIES calls in root CMakeLists.txt Update all other modules to use KF5::LibraryName Diffs - CMakeLists.txt 17c3090 kded/CMakeLists.txt 7532687 kdewidgets/CMakeLists.txt 885091e khtml/src/CMakeLists.txt 5e00c8c khtml/src/kmultipart/CMakeLists.txt 3fc6982 kio/misc/kpac/CMakeLists.txt 897de8e staging/kio/src/core/CMakeLists.txt 5d75fc9 staging/kio/src/filewidgets/CMakeLists.txt 3790250 Diff: http://git.reviewboard.kde.org/r/113238/diff/ Testing --- compiled Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
On Oct. 14, 2013, 7:31 a.m., Kevin Ottens wrote: -1 I disagree with the removal, OK they get deprecated in KDE4... but it's been done only recently (the patch isn't even in yet). We still have a couple of users for those classes and it would be one more breakage on our SC promise (and one we can avoid at that). Kevin Ottens wrote: Of course I meant for the removals in kde4support. The comments cleanup in kio I'm fine with it. Vishesh Handa wrote: Well, avoiding that would be mean that I need to either (1) port it to Nepomuk2 and thus get a dependency to nepomuk-core or (2) remove all the Nepomuk code. If it is really required I can go with (2), though it'll be a lot more work. The nepomuk-core replacement classes are almost source compatible with the kio ones. So the port is mostly just changing the class name, and linking to the new library. Also, Konversation and Conquire (Nepomuk app) seems to be the only users of this class. KGet has been ported. Do you still want me to go with (2)? Kevin Ottens wrote: OK, I guess I miss a piece of information then: What happened to the Nepomuk API it currently uses? Did it simply disappear? if yes it means even more broken promises. :-) Vishesh Handa wrote: The Nepomuk API that was originally in kdelibs/nepomuk was removed very long ago. The code now lives in nepomuk-core and nepomuk-widgets. We almost maintain source compatibility (minus some small things). Kevin Ottens wrote: OK, so that's what I had in mind. It means the API used by those classes in kde4support you're trying to remove is still there for their consumption, so why not just let them alone? I don't see the benefit of removing them or porting them to something different, it'll just create more build errors to code built against kf5, making ports harder. Alright. I'll let this be and start working on nepomuk-core frameworks port. Please note that this means kdesupport will depend on nepomuk-core. It also means that this patch is now invalid - https://git.reviewboard.kde.org/r/113157/ - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/#review41676 --- On Oct. 10, 2013, 12:56 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 10, 2013, 12:56 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Compiling Plasma-Framework with a QT5 compiled with -egl -opengl es2
On Friday 11 October 2013 07:32:47 nerdopolis wrote: On Thursday, October 10, 2013 12:00:04 PM kde-frameworks-devel- requ...@kde.org wrote: Is this a bug I should file? no need to file a bug about it. It's code I have written and I know that it currently requires glx. The problem here is that GLX is found on your system but Qt is compiled as gles. This is an unfortunate situation and should not happen in real world as one has either desktop gl or gles and not both on a system. Cheers Martin Hi. It seems qtwayland needs egl though, which seems to require qt to be built with es2? it shouldn't require es2. It's obvious that it needs egl, but it shouldn't need es2. If it does that would be clearly an upstream bug. KWin 4.11 for Wayland requires egl, but doesn't work with es2. Checking for wayland... yes Checking for xkbcommon... yes Checking for wayland_scanner... yes Checking for wayland_egl... no Checking for egl... no Checking for brcm_egl... no Checking for glx... yes Checking for xcomposite... yes Project MESSAGE: no wayland-egl support detected, cross-toolkit compatibility disabled It doesn't seem to build the plugin when I removed the -egl -opengl es2 and rebuilt QT. What if you add the -egl and not the -opengl es2? Egl is an own library and not part of opengles. 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 113241: Move khtml java tests into the test directory
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Move khtml java tests into the test directory Diffs - khtml/src/java/CMakeLists.txt 3e73c8d khtml/src/java/tests/CMakeLists.txt 65e16ae khtml/src/java/tests/badapplets/BadApplet.jar khtml/src/java/tests/badapplets/BadApplet.java khtml/src/java/tests/badapplets/applet.html khtml/src/java/tests/good_sites khtml/src/java/tests/testkjavaappletserver.cpp khtml/tests/CMakeLists.txt 9a742cf Diff: http://git.reviewboard.kde.org/r/113241/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113241: Move khtml java tests into the test directory
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/#review41734 --- Ship it! Makes sense to have all this tests into their own java subfolder, ship it! - Àlex Fiestas On Oct. 14, 2013, 2:38 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/ --- (Updated Oct. 14, 2013, 2:38 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Move khtml java tests into the test directory Diffs - khtml/src/java/CMakeLists.txt 3e73c8d khtml/src/java/tests/CMakeLists.txt 65e16ae khtml/src/java/tests/badapplets/BadApplet.jar khtml/src/java/tests/badapplets/BadApplet.java khtml/src/java/tests/badapplets/applet.html khtml/src/java/tests/good_sites khtml/src/java/tests/testkjavaappletserver.cpp khtml/tests/CMakeLists.txt 9a742cf Diff: http://git.reviewboard.kde.org/r/113241/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens er...@kde.org wrote: Giving it a closer look, I'm wondering: are you sure about this course of action? KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted together. So deprecating those two without deprecating KDateTimeEdit sounds weird to me... In particular internally it could/should use KDateEdit (which is forked several times and not in kdelibs ATM) which is a much more interesting widget. At that point I would be tempted to move KDateTimeEdit to kde4support too as it's not used anyway and push people toward using stock Qt widgets to their date/time needs. It means the only two widgets we would save from the kde4support fate are KDatePicker and later on KDateEdit (once all its forks are merged or we pick one implementation from the lot). Opinion? Hi, KDateEdit and KTimeEdit are forks of KDateComboBox and KTimeComboBox with extra features added, which were then copied around a lot. KDateTimeEdit was a new kdelibs widget in 4.8 designed to replace all the forks and merge all the extra features into one clean new widget, which was done in consultation with the apps involved (I think you even did the review?). Why none of the apps maintaining their own forks have changed over I don't know, I certainly told them it was available, but it may be worth asking them to find out why. KDateTimeEdit can replace all of KDateEdit, KTimeEdit, KDateComboBox, and KTimeComboBox simply by setting the mode to use, hence why I prefer for it to be the one that is kept if any are. Another plus is it is only derived from QWidget so can have its internals changed, unlike KDateWidget and KDateComboBox which are derived from QComboBox and KComboBox. Pushing people to use the Qt widgets might be preferable, but we'd need to do a feature-by-feature comparison to see if people would actually want to use them or if it would just lead to more forks. Also it would need to be an either/or thing, as the date edit widgets need a date picker pop-up, so the two go together. Ideally I'd have time to write brand new Qt widgets, but I can't guarantee that. Speaking of which, I was looking at KDatePicker vs QCalendarWidget situation, and here's my analysis. - K has optional close button - K has next/prev year and month buttons, Q only month buttons - K has year edit pop-up, Q has spin box - K has Today button - K has visible line edit for date, Q has hidden entry when type numbers - K has week selector combo - K has optional right-click context menu (unused) - K can set font size (prob obsolete?) - K has more signals - K has custom date painting, can set fg/bg colour and bg shape circle/square - Q has custom date painting using QTextCharFormat - Q can set nav bar invisible, K uses separate KDateTable class - Q can change header day name length, can format with QTextCharFormat - Q has optional week number column, can format with QTextCharFormat - Q can toggle visible grid - Q can set min/max date, but only in 100AD to 7999AD range - Q can override first day of week - Q can set editable or not editable - Q can set single date selction or no selection Basically QCalendarWidget has better guts, more flexability and themability, but KDatePicker looks better and has better usability. We may be able to extend QCalendarWidget with some of the KDE features, but that would require buy-in from the Widgets maintainers. Current Q looks ugly when used with Oxygen, it doesn't seem to pick up any themeing? Then again, KDateTable is not exactly very themed either. I'm not sure what the best option is here. If others could have a play with QCalendarWidget and give an opinion on whether it performs well enough or not? Also, how receptive have the QWidgets maintainers been to visible changes? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113240: Move KJsEmbed to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113240/#review41735 --- Ship it! Looks good, it compiles and all policies are done so good to go. - Àlex Fiestas On Oct. 14, 2013, 2:04 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113240/ --- (Updated Oct. 14, 2013, 2:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It does the move, not much else going on. Diffs - staging/CMakeLists.txt a3bfaab staging/kjsembed/AUTHORS staging/kjsembed/CMakeLists.txt staging/kjsembed/KJsEmbedConfig.cmake.in staging/kjsembed/Mainpage.dox staging/kjsembed/examples/calc/calc.js staging/kjsembed/examples/calc/calc.ui staging/kjsembed/examples/console/console.js staging/kjsembed/examples/console/console.ui staging/kjsembed/examples/docviewer/docviewer.js staging/kjsembed/examples/docviewer/docviewer.ui staging/kjsembed/examples/fancy/fancy.js staging/kjsembed/examples/grammar/grammar.js staging/kjsembed/examples/kjsconsole/CMakeLists.txt staging/kjsembed/examples/kjsconsole/console.h staging/kjsembed/examples/kjsconsole/console.cpp staging/kjsembed/examples/kjsconsole/console.qrc staging/kjsembed/examples/kjsconsole/images/bug.png staging/kjsembed/examples/kjsconsole/images/class.png staging/kjsembed/examples/kjsconsole/images/constant.png staging/kjsembed/examples/kjsconsole/images/method.png staging/kjsembed/examples/kjsconsole/images/next.png staging/kjsembed/examples/kjsconsole/images/no.png staging/kjsembed/examples/kjsconsole/images/property.png staging/kjsembed/examples/kjsconsole/images/runto.png staging/kjsembed/examples/kjsconsole/images/start.png staging/kjsembed/examples/kjsconsole/images/step.png staging/kjsembed/examples/kjsconsole/images/stop.png staging/kjsembed/examples/kjsconsole/jsconsole.ui staging/kjsembed/examples/kjsconsole/kjs_object_model.h staging/kjsembed/examples/kjsconsole/kjs_object_model.cpp staging/kjsembed/examples/kjsconsole/main.cpp staging/kjsembed/examples/kjsconsole/numberedtextview.h staging/kjsembed/examples/kjsconsole/numberedtextview.cpp staging/kjsembed/examples/scribble/scribble.js staging/kjsembed/examples/tests/args.js staging/kjsembed/examples/tests/brush.js staging/kjsembed/examples/tests/builtins.js staging/kjsembed/examples/tests/class.js staging/kjsembed/examples/tests/colortest.js staging/kjsembed/examples/tests/conio.js staging/kjsembed/examples/tests/domtest.js staging/kjsembed/examples/tests/events.js staging/kjsembed/examples/tests/fileio.js staging/kjsembed/examples/tests/fonttest.js staging/kjsembed/examples/tests/frame.js staging/kjsembed/examples/tests/gc.js staging/kjsembed/examples/tests/include.js staging/kjsembed/examples/tests/inner.js staging/kjsembed/examples/tests/jsslot.js staging/kjsembed/examples/tests/layout.js staging/kjsembed/examples/tests/library.js staging/kjsembed/examples/tests/listproperties.js staging/kjsembed/examples/tests/matt.js staging/kjsembed/examples/tests/paintertest.js staging/kjsembed/examples/tests/paintevent.js staging/kjsembed/examples/tests/pixmap.js staging/kjsembed/examples/tests/recttest.js staging/kjsembed/examples/tests/settings.js staging/kjsembed/examples/tests/signslots.js staging/kjsembed/examples/tests/statictest.js staging/kjsembed/examples/tests/stylesheet.js staging/kjsembed/examples/tests/svgtest.js staging/kjsembed/examples/tests/system.js staging/kjsembed/examples/tests/test.svg staging/kjsembed/examples/tests/test.ui staging/kjsembed/examples/tests/typecheck.js staging/kjsembed/examples/tests/uitest.js staging/kjsembed/examples/tests/uitest2.js staging/kjsembed/examples/tests/url.js staging/kjsembed/examples/tests/widgettest.js staging/kjsembed/src/CMakeLists.txt staging/kjsembed/src/kjscmd/CMakeLists.txt staging/kjsembed/src/kjscmd/console.js staging/kjsembed/src/kjscmd/kjscmd.cpp staging/kjsembed/src/kjscmd/kjscmd.qrc staging/kjsembed/src/kjsembed/CMakeLists.txt staging/kjsembed/src/kjsembed/QBrush_bind.h staging/kjsembed/src/kjsembed/QBrush_bind.cpp staging/kjsembed/src/kjsembed/application.h staging/kjsembed/src/kjsembed/application.cpp staging/kjsembed/src/kjsembed/binding_support.h staging/kjsembed/src/kjsembed/binding_support.cpp staging/kjsembed/src/kjsembed/brush.h
Re: Review Request 113237: Move KInit to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/#review41736 --- Ship it! No test is breaking because of the patch, it looks good so please ship it. - Àlex Fiestas On Oct. 14, 2013, 11:12 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/ --- (Updated Oct. 14, 2013, 11:12 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KInit to tier3 Diffs - CMakeLists.txt 17c3090 staging/CMakeLists.txt a3bfaab staging/kinit/CMakeLists.txt staging/kinit/ConfigureChecks.cmake staging/kinit/Info.plist.template staging/kinit/KInitConfig.cmake staging/kinit/KInitMacros.cmake 67d24dd staging/kinit/Mainpage.dox staging/kinit/README staging/kinit/README.autostart staging/kinit/README.wrapper staging/kinit/kde5init_dummy.cpp.in staging/kinit/kde5init_win32lib_dummy.cpp.in staging/kinit/src/CMakeLists.txt 12d1590 staging/kinit/src/config-kdeinit.h.cmake staging/kinit/src/kdeinit/CMakeLists.txt staging/kinit/src/kdeinit/kinit.cpp staging/kinit/src/kdeinit/kinit_win.cpp staging/kinit/src/kdeinit/proctitle.h staging/kinit/src/kdeinit/proctitle.cpp staging/kinit/src/kioslave/CMakeLists.txt staging/kinit/src/kioslave/kioslave.cpp staging/kinit/src/klauncher/CMakeLists.txt staging/kinit/src/klauncher/autostart.h staging/kinit/src/klauncher/autostart.cpp staging/kinit/src/klauncher/klauncher.h staging/kinit/src/klauncher/klauncher.cpp staging/kinit/src/klauncher/klauncher_adaptor.h staging/kinit/src/klauncher/klauncher_adaptor.cpp staging/kinit/src/klauncher/klauncher_main.cpp staging/kinit/src/klauncher_cmds.h staging/kinit/src/klauncher_cmds.cpp staging/kinit/src/kshell/CMakeLists.txt staging/kinit/src/kshell/shell.cpp staging/kinit/src/kwrapper/CMakeLists.txt staging/kinit/src/kwrapper/kwrapper.cpp staging/kinit/src/kwrapper/kwrapper_win.cpp staging/kinit/src/start_kdeinit/CMakeLists.txt staging/kinit/src/start_kdeinit/start_kdeinit.c staging/kinit/src/start_kdeinit/start_kdeinit_wrapper.c staging/kinit/src/wrapper.cpp tier3/CMakeLists.txt 4f5c1c8 Diff: http://git.reviewboard.kde.org/r/113237/diff/ Testing --- Builds, tests pass. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113148: Move and clean KBuildsycoca to KService
On Oct. 12, 2013, 4:57 p.m., David Faure wrote: kded/kbuildsycoca.cpp, line 84 http://git.reviewboard.kde.org/r/113148/diff/3/?file=200224#file200224line84 Not called anymore with your commit. But I'm not sure we want to remove the feature... what's the problem with keeping the kcrash dependency? I don't have an opinion on this, if you want to keep it then we can keep it. I removed it because it looked like we wanted to do it but we couldn't because of abi/api/behavior compatibility, now it is the time to break things so I removed it :p For what is worth I think that we could replace some of KSCrash functionality with systemd-coredump but I don't know exactly how either of them work so... - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/#review41603 --- On Oct. 10, 2013, 10:04 a.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113148/ --- (Updated Oct. 10, 2013, 10:04 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moved KBuildsyscoca to KService. I have done the moving and the cleaning in different commits, just unified them for reviewboard. Diffs - kded/CMakeLists.txt 4f9133f kded/applications.menu kded/kbuildmimetypefactory.h kded/kbuildmimetypefactory.cpp 2e81ce7 kded/kbuildservicefactory.h kded/kbuildservicefactory.cpp 971f327 kded/kbuildservicegroupfactory.h kded/kbuildservicegroupfactory.cpp 5485b1c kded/kbuildservicetypefactory.h kded/kbuildservicetypefactory.cpp f473cd6 kded/kbuildsycoca.h kded/kbuildsycoca.cpp 8ea2d2e kded/kbuildsycocainterface.h kded/kctimefactory.h kded/kctimefactory.cpp kded/kmimeassociations.h kded/kmimeassociations.cpp kded/ksycocaresourcelist.h kded/tests/CMakeLists.txt ca392d2 kded/tests/kmimeassociationstest.cpp kded/vfolder_menu.h kded/vfolder_menu.cpp staging/kservice/CMakeLists.txt b244731 staging/kservice/kbuildsycoca/CMakeLists.txt PRE-CREATION staging/kservice/tests/CMakeLists.txt 23d4854 Diff: http://git.reviewboard.kde.org/r/113148/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113241: Move khtml java tests into the test directory
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/#review41739 --- This review has been submitted with commit 1472061e9e203ae1d81ab3b654f85809399de0c1 by David Edmundson to branch frameworks. - Commit Hook On Oct. 14, 2013, 2:38 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/ --- (Updated Oct. 14, 2013, 2:38 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Move khtml java tests into the test directory Diffs - khtml/src/java/CMakeLists.txt 3e73c8d khtml/src/java/tests/CMakeLists.txt 65e16ae khtml/src/java/tests/badapplets/BadApplet.jar khtml/src/java/tests/badapplets/BadApplet.java khtml/src/java/tests/badapplets/applet.html khtml/src/java/tests/good_sites khtml/src/java/tests/testkjavaappletserver.cpp khtml/tests/CMakeLists.txt 9a742cf Diff: http://git.reviewboard.kde.org/r/113241/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113241: Move khtml java tests into the test directory
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113241/ --- (Updated Oct. 14, 2013, 4:10 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Move khtml java tests into the test directory Diffs - khtml/src/java/CMakeLists.txt 3e73c8d khtml/src/java/tests/CMakeLists.txt 65e16ae khtml/src/java/tests/badapplets/BadApplet.jar khtml/src/java/tests/badapplets/BadApplet.java khtml/src/java/tests/badapplets/applet.html khtml/src/java/tests/good_sites khtml/src/java/tests/testkjavaappletserver.cpp khtml/tests/CMakeLists.txt 9a742cf Diff: http://git.reviewboard.kde.org/r/113241/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113237: Move KInit to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/#review41740 --- This review has been submitted with commit bc43c8b20d21d6c06c61bea999a36b8c4e31ba7c by Aleix Pol to branch frameworks. - Commit Hook On Oct. 14, 2013, 11:12 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/ --- (Updated Oct. 14, 2013, 11:12 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KInit to tier3 Diffs - CMakeLists.txt 17c3090 staging/CMakeLists.txt a3bfaab staging/kinit/CMakeLists.txt staging/kinit/ConfigureChecks.cmake staging/kinit/Info.plist.template staging/kinit/KInitConfig.cmake staging/kinit/KInitMacros.cmake 67d24dd staging/kinit/Mainpage.dox staging/kinit/README staging/kinit/README.autostart staging/kinit/README.wrapper staging/kinit/kde5init_dummy.cpp.in staging/kinit/kde5init_win32lib_dummy.cpp.in staging/kinit/src/CMakeLists.txt 12d1590 staging/kinit/src/config-kdeinit.h.cmake staging/kinit/src/kdeinit/CMakeLists.txt staging/kinit/src/kdeinit/kinit.cpp staging/kinit/src/kdeinit/kinit_win.cpp staging/kinit/src/kdeinit/proctitle.h staging/kinit/src/kdeinit/proctitle.cpp staging/kinit/src/kioslave/CMakeLists.txt staging/kinit/src/kioslave/kioslave.cpp staging/kinit/src/klauncher/CMakeLists.txt staging/kinit/src/klauncher/autostart.h staging/kinit/src/klauncher/autostart.cpp staging/kinit/src/klauncher/klauncher.h staging/kinit/src/klauncher/klauncher.cpp staging/kinit/src/klauncher/klauncher_adaptor.h staging/kinit/src/klauncher/klauncher_adaptor.cpp staging/kinit/src/klauncher/klauncher_main.cpp staging/kinit/src/klauncher_cmds.h staging/kinit/src/klauncher_cmds.cpp staging/kinit/src/kshell/CMakeLists.txt staging/kinit/src/kshell/shell.cpp staging/kinit/src/kwrapper/CMakeLists.txt staging/kinit/src/kwrapper/kwrapper.cpp staging/kinit/src/kwrapper/kwrapper_win.cpp staging/kinit/src/start_kdeinit/CMakeLists.txt staging/kinit/src/start_kdeinit/start_kdeinit.c staging/kinit/src/start_kdeinit/start_kdeinit_wrapper.c staging/kinit/src/wrapper.cpp tier3/CMakeLists.txt 4f5c1c8 Diff: http://git.reviewboard.kde.org/r/113237/diff/ Testing --- Builds, tests pass. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113237: Move KInit to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113237/ --- (Updated Oct. 14, 2013, 4:15 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Moves KInit to tier3 Diffs - CMakeLists.txt 17c3090 staging/CMakeLists.txt a3bfaab staging/kinit/CMakeLists.txt staging/kinit/ConfigureChecks.cmake staging/kinit/Info.plist.template staging/kinit/KInitConfig.cmake staging/kinit/KInitMacros.cmake 67d24dd staging/kinit/Mainpage.dox staging/kinit/README staging/kinit/README.autostart staging/kinit/README.wrapper staging/kinit/kde5init_dummy.cpp.in staging/kinit/kde5init_win32lib_dummy.cpp.in staging/kinit/src/CMakeLists.txt 12d1590 staging/kinit/src/config-kdeinit.h.cmake staging/kinit/src/kdeinit/CMakeLists.txt staging/kinit/src/kdeinit/kinit.cpp staging/kinit/src/kdeinit/kinit_win.cpp staging/kinit/src/kdeinit/proctitle.h staging/kinit/src/kdeinit/proctitle.cpp staging/kinit/src/kioslave/CMakeLists.txt staging/kinit/src/kioslave/kioslave.cpp staging/kinit/src/klauncher/CMakeLists.txt staging/kinit/src/klauncher/autostart.h staging/kinit/src/klauncher/autostart.cpp staging/kinit/src/klauncher/klauncher.h staging/kinit/src/klauncher/klauncher.cpp staging/kinit/src/klauncher/klauncher_adaptor.h staging/kinit/src/klauncher/klauncher_adaptor.cpp staging/kinit/src/klauncher/klauncher_main.cpp staging/kinit/src/klauncher_cmds.h staging/kinit/src/klauncher_cmds.cpp staging/kinit/src/kshell/CMakeLists.txt staging/kinit/src/kshell/shell.cpp staging/kinit/src/kwrapper/CMakeLists.txt staging/kinit/src/kwrapper/kwrapper.cpp staging/kinit/src/kwrapper/kwrapper_win.cpp staging/kinit/src/start_kdeinit/CMakeLists.txt staging/kinit/src/start_kdeinit/start_kdeinit.c staging/kinit/src/start_kdeinit/start_kdeinit_wrapper.c staging/kinit/src/wrapper.cpp tier3/CMakeLists.txt 4f5c1c8 Diff: http://git.reviewboard.kde.org/r/113237/diff/ Testing --- Builds, tests pass. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/#review41741 --- This review has been submitted with commit af8deabf64506b4f3ee4186e42b6e9904eed36bc by Vishesh Handa to branch master. - Commit Hook On Oct. 7, 2013, 5:01 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- (Updated Oct. 7, 2013, 5:01 p.m.) Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- (Updated Oct. 14, 2013, 4:16 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113243: KMessageBox: Re-enable squeezed text for extreme situations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113243/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- KMessageBox: Re-enable squeezed text for extreme situations Also adds a test for it to kmessageboxtest.cpp Diffs - KDE5PORTING.html 9ed2294 tier1/kwidgetsaddons/src/kmessagebox.cpp e56f666 tier1/kwidgetsaddons/tests/kmessageboxtest.cpp 18c50b7 Diff: http://git.reviewboard.kde.org/r/113243/diff/ Testing --- Builds, message box shows for the new test in kmessageboxtest.cpp. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113157: Remove Nepomuk dependency from kde4support
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113157/ --- (Updated Oct. 14, 2013, 4:21 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kdelibs Description --- The only class using it is KFileMetaInfoItem which is just using the ontology parts in order to get a better name for a property. It can rely on strigi instead. Diffs - staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/config-kde4support.h.cmake 95a092f staging/kde4support/src/kdebug.areas 2cabd98 staging/kde4support/src/kio/kfilemetainfoitem.cpp 9df2602 staging/kde4support/src/kio/kfilemetainfoitem_p.h 959fbd6 Diff: http://git.reviewboard.kde.org/r/113157/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113154: Remove KFileMetaDataWidget and friends
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113154/ --- (Updated Oct. 14, 2013, 4:21 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KFileMetaDataWidget and friends These have been deprecated in KDE4.[1] This also removes the KFileMetaPropsPlugin in the KPropertiesDialog - The code was commented out so it doesn't really make a difference. Eventually we will need a proper plugin based system so that the Nepomuk2::FileMetadataWidget can be used in the KPropertiesDialog [1] https://git.reviewboard.kde.org/r/113153/ Diffs - KDE5PORTING.html 3171afc kdewidgets/kde.widgets b138d4e staging/kde4support/src/CMakeLists.txt 5eb649c staging/kde4support/src/kio/kcommentwidget.cpp 6223a0c staging/kde4support/src/kio/kcommentwidget_p.h 7a9c710 staging/kde4support/src/kio/kfilemetadataconfigurationwidget.h 52735ad staging/kde4support/src/kio/kfilemetadataconfigurationwidget.cpp 018d183 staging/kde4support/src/kio/kfilemetadataprovider.cpp 59cb238 staging/kde4support/src/kio/kfilemetadataprovider_p.h 0969f53 staging/kde4support/src/kio/kfilemetadatareader.cpp 6a7909c staging/kde4support/src/kio/kfilemetadatareader_p.h af054c2 staging/kde4support/src/kio/kfilemetadatareaderprocess.cpp 0d2b993 staging/kde4support/src/kio/kfilemetadatawidget.h 31dd3c7 staging/kde4support/src/kio/kfilemetadatawidget.cpp 2df2312 staging/kde4support/src/kio/kmetaprops.h b03dd4c staging/kde4support/src/kio/kmetaprops.cpp 46624c5 staging/kde4support/src/kio/knfotranslator.cpp 0494679 staging/kde4support/src/kio/knfotranslator_p.h ddbe4a1 staging/kio/src/widgets/kpropertiesdialog.cpp 63e4435 Diff: http://git.reviewboard.kde.org/r/113154/diff/ Testing --- Thanks, Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113240: Move KJsEmbed to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113240/#review41744 --- This review has been submitted with commit 5344e02ae20deaea435b9596c18f4f51a017a58c by Aleix Pol to branch frameworks. - Commit Hook On Oct. 14, 2013, 2:04 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113240/ --- (Updated Oct. 14, 2013, 2:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It does the move, not much else going on. Diffs - staging/CMakeLists.txt a3bfaab staging/kjsembed/AUTHORS staging/kjsembed/CMakeLists.txt staging/kjsembed/KJsEmbedConfig.cmake.in staging/kjsembed/Mainpage.dox staging/kjsembed/examples/calc/calc.js staging/kjsembed/examples/calc/calc.ui staging/kjsembed/examples/console/console.js staging/kjsembed/examples/console/console.ui staging/kjsembed/examples/docviewer/docviewer.js staging/kjsembed/examples/docviewer/docviewer.ui staging/kjsembed/examples/fancy/fancy.js staging/kjsembed/examples/grammar/grammar.js staging/kjsembed/examples/kjsconsole/CMakeLists.txt staging/kjsembed/examples/kjsconsole/console.h staging/kjsembed/examples/kjsconsole/console.cpp staging/kjsembed/examples/kjsconsole/console.qrc staging/kjsembed/examples/kjsconsole/images/bug.png staging/kjsembed/examples/kjsconsole/images/class.png staging/kjsembed/examples/kjsconsole/images/constant.png staging/kjsembed/examples/kjsconsole/images/method.png staging/kjsembed/examples/kjsconsole/images/next.png staging/kjsembed/examples/kjsconsole/images/no.png staging/kjsembed/examples/kjsconsole/images/property.png staging/kjsembed/examples/kjsconsole/images/runto.png staging/kjsembed/examples/kjsconsole/images/start.png staging/kjsembed/examples/kjsconsole/images/step.png staging/kjsembed/examples/kjsconsole/images/stop.png staging/kjsembed/examples/kjsconsole/jsconsole.ui staging/kjsembed/examples/kjsconsole/kjs_object_model.h staging/kjsembed/examples/kjsconsole/kjs_object_model.cpp staging/kjsembed/examples/kjsconsole/main.cpp staging/kjsembed/examples/kjsconsole/numberedtextview.h staging/kjsembed/examples/kjsconsole/numberedtextview.cpp staging/kjsembed/examples/scribble/scribble.js staging/kjsembed/examples/tests/args.js staging/kjsembed/examples/tests/brush.js staging/kjsembed/examples/tests/builtins.js staging/kjsembed/examples/tests/class.js staging/kjsembed/examples/tests/colortest.js staging/kjsembed/examples/tests/conio.js staging/kjsembed/examples/tests/domtest.js staging/kjsembed/examples/tests/events.js staging/kjsembed/examples/tests/fileio.js staging/kjsembed/examples/tests/fonttest.js staging/kjsembed/examples/tests/frame.js staging/kjsembed/examples/tests/gc.js staging/kjsembed/examples/tests/include.js staging/kjsembed/examples/tests/inner.js staging/kjsembed/examples/tests/jsslot.js staging/kjsembed/examples/tests/layout.js staging/kjsembed/examples/tests/library.js staging/kjsembed/examples/tests/listproperties.js staging/kjsembed/examples/tests/matt.js staging/kjsembed/examples/tests/paintertest.js staging/kjsembed/examples/tests/paintevent.js staging/kjsembed/examples/tests/pixmap.js staging/kjsembed/examples/tests/recttest.js staging/kjsembed/examples/tests/settings.js staging/kjsembed/examples/tests/signslots.js staging/kjsembed/examples/tests/statictest.js staging/kjsembed/examples/tests/stylesheet.js staging/kjsembed/examples/tests/svgtest.js staging/kjsembed/examples/tests/system.js staging/kjsembed/examples/tests/test.svg staging/kjsembed/examples/tests/test.ui staging/kjsembed/examples/tests/typecheck.js staging/kjsembed/examples/tests/uitest.js staging/kjsembed/examples/tests/uitest2.js staging/kjsembed/examples/tests/url.js staging/kjsembed/examples/tests/widgettest.js staging/kjsembed/src/CMakeLists.txt staging/kjsembed/src/kjscmd/CMakeLists.txt staging/kjsembed/src/kjscmd/console.js staging/kjsembed/src/kjscmd/kjscmd.cpp staging/kjsembed/src/kjscmd/kjscmd.qrc staging/kjsembed/src/kjsembed/CMakeLists.txt staging/kjsembed/src/kjsembed/QBrush_bind.h staging/kjsembed/src/kjsembed/QBrush_bind.cpp staging/kjsembed/src/kjsembed/application.h staging/kjsembed/src/kjsembed/application.cpp staging/kjsembed/src/kjsembed/binding_support.h staging/kjsembed/src/kjsembed/binding_support.cpp
Re: Review Request 113240: Move KJsEmbed to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113240/ --- (Updated Oct. 14, 2013, 4:30 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- It does the move, not much else going on. Diffs - staging/CMakeLists.txt a3bfaab staging/kjsembed/AUTHORS staging/kjsembed/CMakeLists.txt staging/kjsembed/KJsEmbedConfig.cmake.in staging/kjsembed/Mainpage.dox staging/kjsembed/examples/calc/calc.js staging/kjsembed/examples/calc/calc.ui staging/kjsembed/examples/console/console.js staging/kjsembed/examples/console/console.ui staging/kjsembed/examples/docviewer/docviewer.js staging/kjsembed/examples/docviewer/docviewer.ui staging/kjsembed/examples/fancy/fancy.js staging/kjsembed/examples/grammar/grammar.js staging/kjsembed/examples/kjsconsole/CMakeLists.txt staging/kjsembed/examples/kjsconsole/console.h staging/kjsembed/examples/kjsconsole/console.cpp staging/kjsembed/examples/kjsconsole/console.qrc staging/kjsembed/examples/kjsconsole/images/bug.png staging/kjsembed/examples/kjsconsole/images/class.png staging/kjsembed/examples/kjsconsole/images/constant.png staging/kjsembed/examples/kjsconsole/images/method.png staging/kjsembed/examples/kjsconsole/images/next.png staging/kjsembed/examples/kjsconsole/images/no.png staging/kjsembed/examples/kjsconsole/images/property.png staging/kjsembed/examples/kjsconsole/images/runto.png staging/kjsembed/examples/kjsconsole/images/start.png staging/kjsembed/examples/kjsconsole/images/step.png staging/kjsembed/examples/kjsconsole/images/stop.png staging/kjsembed/examples/kjsconsole/jsconsole.ui staging/kjsembed/examples/kjsconsole/kjs_object_model.h staging/kjsembed/examples/kjsconsole/kjs_object_model.cpp staging/kjsembed/examples/kjsconsole/main.cpp staging/kjsembed/examples/kjsconsole/numberedtextview.h staging/kjsembed/examples/kjsconsole/numberedtextview.cpp staging/kjsembed/examples/scribble/scribble.js staging/kjsembed/examples/tests/args.js staging/kjsembed/examples/tests/brush.js staging/kjsembed/examples/tests/builtins.js staging/kjsembed/examples/tests/class.js staging/kjsembed/examples/tests/colortest.js staging/kjsembed/examples/tests/conio.js staging/kjsembed/examples/tests/domtest.js staging/kjsembed/examples/tests/events.js staging/kjsembed/examples/tests/fileio.js staging/kjsembed/examples/tests/fonttest.js staging/kjsembed/examples/tests/frame.js staging/kjsembed/examples/tests/gc.js staging/kjsembed/examples/tests/include.js staging/kjsembed/examples/tests/inner.js staging/kjsembed/examples/tests/jsslot.js staging/kjsembed/examples/tests/layout.js staging/kjsembed/examples/tests/library.js staging/kjsembed/examples/tests/listproperties.js staging/kjsembed/examples/tests/matt.js staging/kjsembed/examples/tests/paintertest.js staging/kjsembed/examples/tests/paintevent.js staging/kjsembed/examples/tests/pixmap.js staging/kjsembed/examples/tests/recttest.js staging/kjsembed/examples/tests/settings.js staging/kjsembed/examples/tests/signslots.js staging/kjsembed/examples/tests/statictest.js staging/kjsembed/examples/tests/stylesheet.js staging/kjsembed/examples/tests/svgtest.js staging/kjsembed/examples/tests/system.js staging/kjsembed/examples/tests/test.svg staging/kjsembed/examples/tests/test.ui staging/kjsembed/examples/tests/typecheck.js staging/kjsembed/examples/tests/uitest.js staging/kjsembed/examples/tests/uitest2.js staging/kjsembed/examples/tests/url.js staging/kjsembed/examples/tests/widgettest.js staging/kjsembed/src/CMakeLists.txt staging/kjsembed/src/kjscmd/CMakeLists.txt staging/kjsembed/src/kjscmd/console.js staging/kjsembed/src/kjscmd/kjscmd.cpp staging/kjsembed/src/kjscmd/kjscmd.qrc staging/kjsembed/src/kjsembed/CMakeLists.txt staging/kjsembed/src/kjsembed/QBrush_bind.h staging/kjsembed/src/kjsembed/QBrush_bind.cpp staging/kjsembed/src/kjsembed/application.h staging/kjsembed/src/kjsembed/application.cpp staging/kjsembed/src/kjsembed/binding_support.h staging/kjsembed/src/kjsembed/binding_support.cpp staging/kjsembed/src/kjsembed/brush.h staging/kjsembed/src/kjsembed/brush.cpp staging/kjsembed/src/kjsembed/builtins.h staging/kjsembed/src/kjsembed/builtins.cpp staging/kjsembed/src/kjsembed/color.h staging/kjsembed/src/kjsembed/color.cpp staging/kjsembed/src/kjsembed/dom.h staging/kjsembed/src/kjsembed/dom.cpp staging/kjsembed/src/kjsembed/eventproxy.h staging/kjsembed/src/kjsembed/eventproxy.cpp
Re: QTimeZone merged for 5.2
On 14 October 2013 12:55, Kevin Ottens er...@kde.org wrote: Giving it a closer look, I'm wondering: are you sure about this course of action? KDateTimeEdit is basically a KDateComboBox and a KTimeComboBox layouted together. So deprecating those two without deprecating KDateTimeEdit sounds weird to me... In particular internally it could/should use KDateEdit (which is forked several times and not in kdelibs ATM) which is a much more interesting widget. At that point I would be tempted to move KDateTimeEdit to kde4support too as it's not used anyway and push people toward using stock Qt widgets to their date/time needs. It means the only two widgets we would save from the kde4support fate are KDatePicker and later on KDateEdit (once all its forks are merged or we pick one implementation from the lot). KDateEdit and KTimeEdit are forks of KDateComboBox and KTimeComboBox with extra features added, which were then copied around a lot. KDateTimeEdit was a new kdelibs widget in 4.8 designed to replace all the forks and merge all the extra features into one clean new widget, which was done in consultation with the apps involved (I think you even did the review?). Why none of the apps maintaining their own forks have changed over I don't know, I certainly told them it was available, but it may be worth asking them to find out why. KDateTimeEdit can replace all of KDateEdit, KTimeEdit, KDateComboBox, and KTimeComboBox simply by setting the mode to use, hence why I prefer for it to be the one that is kept if any are. Another plus is it is only derived from QWidget so can have its internals changed, unlike KDateWidget and KDateComboBox which are derived from QComboBox and KComboBox. Pushing people to use the Qt widgets might be preferable, but we'd need to do a feature-by-feature comparison to see if people would actually want to use them or if it would just lead to more forks. Also it would need to be an either/or thing, as the date edit widgets need a date picker pop-up, so the two go together. Ideally I'd have time to write brand new Qt widgets, but I can't guarantee that. Speaking of which, I was looking at KDatePicker vs QCalendarWidget situation, and here's my analysis. - K has optional close button - K has next/prev year and month buttons, Q only month buttons - K has year edit pop-up, Q has spin box - K has Today button - K has visible line edit for date, Q has hidden entry when type numbers - K has week selector combo - K has optional right-click context menu (unused) - K can set font size (prob obsolete?) - K has more signals - K has custom date painting, can set fg/bg colour and bg shape circle/square - Q has custom date painting using QTextCharFormat - Q can set nav bar invisible, K uses separate KDateTable class - Q can change header day name length, can format with QTextCharFormat - Q has optional week number column, can format with QTextCharFormat - Q can toggle visible grid - Q can set min/max date, but only in 100AD to 7999AD range - Q can override first day of week - Q can set editable or not editable - Q can set single date selction or no selection Basically QCalendarWidget has better guts, more flexability and themability, but KDatePicker looks better and has better usability. We may be able to extend QCalendarWidget with some of the KDE features, but that would require buy-in from the Widgets maintainers. Current Q looks ugly when used with Oxygen, it doesn't seem to pick up any themeing? Then again, KDateTable is not exactly very themed either. I'm not sure what the best option is here. If others could have a play with QCalendarWidget and give an opinion on whether it performs well enough or not? Also, how receptive have the QWidgets maintainers been to visible changes? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113243: KMessageBox: Re-enable squeezed text for extreme situations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113243/#review41746 --- Ship it! Ship It! - Aleix Pol Gonzalez On Oct. 14, 2013, 4:20 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113243/ --- (Updated Oct. 14, 2013, 4:20 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KMessageBox: Re-enable squeezed text for extreme situations Also adds a test for it to kmessageboxtest.cpp Diffs - KDE5PORTING.html 9ed2294 tier1/kwidgetsaddons/src/kmessagebox.cpp e56f666 tier1/kwidgetsaddons/tests/kmessageboxtest.cpp 18c50b7 Diff: http://git.reviewboard.kde.org/r/113243/diff/ Testing --- Builds, message box shows for the new test in kmessageboxtest.cpp. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113247: Port KCompletion away from KStandardAction
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113247/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Fix depends in KCompletion KCompletion cannot use KStandardAction which is from kconfigwidgets in tier3 Diffs - tier2/kcompletion/CMakeLists.txt 8c34bd6 tier2/kcompletion/KCompletionConfig.cmake.in 46647d1 tier2/kcompletion/src/CMakeLists.txt d2b7602 tier2/kcompletion/src/klineedit.cpp 2f70935 Diff: http://git.reviewboard.kde.org/r/113247/diff/ Testing --- Compiled in source Tried compiling standalone (it builds, but has a linker fail on something unrelated) Ran klineedittest and checked combobox was the same. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113248: Cleanup KNotifyConfig
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113248/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Sort dependencies out, adopt the different cmake constructions to make sure everything will be installed properly. Diffs - Diff: http://git.reviewboard.kde.org/r/113248/diff/ Testing --- builds, teh test seems to work still. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113247: Port KCompletion away from KStandardAction
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113247/#review41750 --- Ship it! Good catch David! - Aleix Pol Gonzalez On Oct. 14, 2013, 5:04 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113247/ --- (Updated Oct. 14, 2013, 5:04 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix depends in KCompletion KCompletion cannot use KStandardAction which is from kconfigwidgets in tier3 Diffs - tier2/kcompletion/CMakeLists.txt 8c34bd6 tier2/kcompletion/KCompletionConfig.cmake.in 46647d1 tier2/kcompletion/src/CMakeLists.txt d2b7602 tier2/kcompletion/src/klineedit.cpp 2f70935 Diff: http://git.reviewboard.kde.org/r/113247/diff/ Testing --- Compiled in source Tried compiling standalone (it builds, but has a linker fail on something unrelated) Ran klineedittest and checked combobox was the same. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113248: Cleanup KNotifyConfig
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113248/ --- (Updated Oct. 14, 2013, 5:33 p.m.) Review request for KDE Frameworks. Changes --- forgot the diff Repository: kdelibs Description --- Sort dependencies out, adopt the different cmake constructions to make sure everything will be installed properly. Diffs (updated) - staging/knotifyconfig/CMakeLists.txt 65867ba staging/knotifyconfig/KNotifyConfigConfig.cmake.in fbdea78 staging/knotifyconfig/src/CMakeLists.txt 9be9ba4 staging/knotifyconfig/tests/CMakeLists.txt 1ed0360 Diff: http://git.reviewboard.kde.org/r/113248/diff/ Testing --- builds, teh test seems to work still. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112730: add CMake changes to knewstuff
On Oct. 12, 2013, 10:43 a.m., David Faure wrote: knewstuff/KNewStuffConfig.cmake.in, line 4 http://git.reviewboard.kde.org/r/112730/diff/3/?file=200166#file200166line4 why is kjs listed as a dependency here but not in the cmakelists.txt? Ah, the Config.cmake.in I copied from had KJS, so should I list the public dependencies in the Config.cmake or the private ones? or both? - Jeremy --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/#review41599 --- On Oct. 9, 2013, 2:24 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/ --- (Updated Oct. 9, 2013, 2:24 p.m.) Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Chusslove Illich. Repository: kdelibs Description --- This makes it so I can mkdir build; cd build; cmake ../; make install from knewstuff sources. It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio libraries have been split out apparently. I'm not sure why sources had to be changed, but I had to add includes of klocalizedstring where we didn't need them before somehow. Diffs - knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a knewstuff/KNewStuffConfig.cmake.in PRE-CREATION knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 knewstuff/src/ui/entrydetailsdialog.cpp 65b75d79941d9026f368f82c7b6df91d754e0925 knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 Diff: http://git.reviewboard.kde.org/r/112730/diff/ Testing --- It builds and installs. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_stable #858
See http://build.kde.org/job/kdelibs_stable/858/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Bring kdewin back?
Hi, While trying to get KDE Frameworks to build on Windows, I found the codebase of KDirWatch is full of Unixisms. I did a few improvements towards getting it to build on Windows, but I'm now getting several errors related to the lack of symbolic links (such as no lstat). It's clear this code couldn't have possibly worked on Windows directly, and the only way it ever worked is through the use of kdewin to provide Unix-like compatibility headers. Other libraries have similar problems. It seems to me that someone removed the dependency on kdewin without making the code actually work without it. Why was it removed? Where can I find the discussion about it, if there was any? If the intention is getting rid of the kdewin dependency, can we *temporarily* bring it back to get things to work again, and then remove it *progressively* as things get fixed? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112730: add CMake changes to knewstuff
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/ --- (Updated Oct. 14, 2013, 10:56 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Chusslove Illich. Repository: kdelibs Description --- This makes it so I can mkdir build; cd build; cmake ../; make install from knewstuff sources. It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio libraries have been split out apparently. I'm not sure why sources had to be changed, but I had to add includes of klocalizedstring where we didn't need them before somehow. Diffs - knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a knewstuff/KNewStuffConfig.cmake.in PRE-CREATION knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 knewstuff/src/ui/entrydetailsdialog.cpp 65b75d79941d9026f368f82c7b6df91d754e0925 knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 Diff: http://git.reviewboard.kde.org/r/112730/diff/ Testing --- It builds and installs. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112730: add CMake changes to knewstuff
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/#review41760 --- This review has been submitted with commit cf319d371bf211e63d865db11b189c2cfb0e5883 by Jeremy Whiting to branch frameworks. - Commit Hook On Oct. 9, 2013, 8:24 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112730/ --- (Updated Oct. 9, 2013, 8:24 p.m.) Review request for KDE Frameworks, Albert Astals Cid, David Faure, and Chusslove Illich. Repository: kdelibs Description --- This makes it so I can mkdir build; cd build; cmake ../; make install from knewstuff sources. It's still using KDE4_KIO_LIBS and find_package(KIO) since not all of the kio libraries have been split out apparently. I'm not sure why sources had to be changed, but I had to add includes of klocalizedstring where we didn't need them before somehow. Diffs - knewstuff/CMakeLists.txt 8ee3653c92692d606a2ff6d1fa69d0d8deb5439a knewstuff/KNewStuffConfig.cmake.in PRE-CREATION knewstuff/src/CMakeLists.txt 5bdf0f6ee619751d66ec48dc7516a73cfe89a8c0 knewstuff/src/downloaddialog.cpp 3294c7c04c7879320fc0949db0310868bd6fa4fa knewstuff/src/downloadwidget.cpp 64b7673d67b4e2f15007fc1a3f57d3da844d1dc0 knewstuff/src/ui/entrydetailsdialog.cpp 65b75d79941d9026f368f82c7b6df91d754e0925 knewstuff/src/uploaddialog.cpp dbde573e8c3a477755c8c866d0ca1fccd1a35729 Diff: http://git.reviewboard.kde.org/r/112730/diff/ Testing --- It builds and installs. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Bring kdewin back?
On Mon, Oct 14, 2013 at 11:42 PM, Nicolás Alvarez nicolas.alva...@gmail.com wrote: Hi, While trying to get KDE Frameworks to build on Windows, I found the codebase of KDirWatch is full of Unixisms. I did a few improvements towards getting it to build on Windows, but I'm now getting several errors related to the lack of symbolic links (such as no lstat). It's clear this code couldn't have possibly worked on Windows directly, and the only way it ever worked is through the use of kdewin to provide Unix-like compatibility headers. Other libraries have similar problems. It seems to me that someone removed the dependency on kdewin without making the code actually work without it. Why was it removed? Where can I find the discussion about it, if there was any? If the intention is getting rid of the kdewin dependency, can we *temporarily* bring it back to get things to work again, and then remove it *progressively* as things get fixed? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Nicolás, It's good to know that there's somebody out there taking care of kf5 on windows. I'm unsure of what to say, though. Maybe you can come up with a list of issues so that we can fix them? At least some output log could be useful... We'll be working on making the different frameworks compilable separately soon enough (actually this should already be the case, although I've seen problems coming up), maybe it will be easier then to try to compile them one by one and come up with something easier to digest. There are things in kdelibs/frameworks that are of no use on windows (thinking of frameworksintegration, for example). Hope this helps :) Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Bring kdewin back?
2013/10/14 Aleix Pol aleix...@kde.org: It's good to know that there's somebody out there taking care of kf5 on windows. I'm unsure of what to say, though. Maybe you can come up with a list of issues so that we can fix them? At least some output log could be useful... I'm now working on http://community.kde.org/Frameworks/Windows We'll be working on making the different frameworks compilable separately soon enough (actually this should already be the case, although I've seen problems coming up), maybe it will be easier then to try to compile them one by one and come up with something easier to digest. There are things in kdelibs/frameworks that are of no use on windows (thinking of frameworksintegration, for example). frameworksintegration is faaar away. Currently only half the tier1 libraries build, the rest of the tiers aren't even enabled. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Bring kdewin back?
Hello, On Monday 14 October 2013 18:42:02 Nicolás Alvarez wrote: While trying to get KDE Frameworks to build on Windows, I found the codebase of KDirWatch is full of Unixisms. I did a few improvements towards getting it to build on Windows, but I'm now getting several errors related to the lack of symbolic links (such as no lstat). It's clear this code couldn't have possibly worked on Windows directly, and the only way it ever worked is through the use of kdewin to provide Unix-like compatibility headers. Other libraries have similar problems. It seems to me that someone removed the dependency on kdewin without making the code actually work without it. Why was it removed? Where can I find the discussion about it, if there was any? Yes it has been discussed, I don't have the thread handy. The point was that it wasn't really acceptable to have that extra-dependency in the tier scheme. We've been working on removing as many unixisms as possible, apparently not enough but we didn't get many people looking at how it was building on windows. I'm glad someone finally does. If the intention is getting rid of the kdewin dependency, can we *temporarily* bring it back to get things to work again, and then remove it *progressively* as things get fixed? If that makes your job easier, I don't see any problem at reintroducing it temporarily and fix it progressively. It needs someone to actively monitor the progress in that direction though, I'm not well equipped to do that ATM. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks 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
