Re: Review Request 116848: Add KWindowSystem::windowChanged(WId, NET::Properties, NET::Properties2) signal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116848/ --- (Updated March 19, 2014, 7:19 a.m.) Review request for KDE Frameworks. Changes --- Added QT_MOC_COMPAT to deprecated signals Repository: kwindowsystem Description --- Add KWindowSystem::windowChanged(WId, NET::Properties, NET::Properties2) signal This signal replaces the existing signal carrying either just the NET::Properties as an uint or both as an const unsigned long*. Accordingly the previous signal gets deprecated, but is still emitted. Question: what's the correct way of deprecating signals, so that one gets a compile warning? Diffs (updated) - src/kwindowsystem.h e10f7c1cdd7b8c1fb1c6472c1f64a2ac71965534 src/kwindowsystem_x11.cpp 8a411008717b27ec8439f6ffebe0113fdad2fd45 Diff: https://git.reviewboard.kde.org/r/116848/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
On March 19, 2014, 3:56 a.m., Michael Pyne wrote: src/lib/util/kuser_unix.cpp, line 349 https://git.reviewboard.kde.org/r/116883/diff/1/?file=255233#file255233line349 Does this need to be a template, or would std::function be sufficient? Templates have a poor reputation amongst some of our devs so I wouldn't make them the first answer unless they cleanly fit the problem. I think std::function is much nicer as well, because it allows specifying the argument list. However I think the compiler won't inline the std::function. Probably not that important, since this code will rarely be called, but I'll check that first. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/#review53382 --- On March 18, 2014, 10:20 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- (Updated March 18, 2014, 10:20 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs - src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ File Attachments Before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/871c8bc5-4631-4759-8103-eb7ac817d698__groupmembers_before.txt After https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/4295e719-acb8-495f-907b-5a93d2d8b64f__groupmembers_after.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116881: Fix KUser::groups() and KUser::groupNames() on UNIX
On March 19, 2014, 4:11 a.m., Michael Pyne wrote: I think I'd argue against bothering with getgrouplist at all if we have to maintain a backup to it either way, it just makes the code messier. But I'll leave that part up to you (maybe it's that much faster). Still a couple of other comments though. Well I think it should be available everywhere: Linux, Mac, *BSD. Maybe non-glibc Linux systems haven't got it. I just left the fallback because we basically had that code already. Maybe leave it there inside an #if 0 block should the need arise? On March 19, 2014, 4:11 a.m., Michael Pyne wrote: src/lib/util/kuser_unix.cpp, line 197 https://git.reviewboard.kde.org/r/116881/diff/1/?file=255229#file255229line197 Same comment about callback as from my other review. I read that the compiler won't inline std::function, will check that later. On March 19, 2014, 4:11 a.m., Michael Pyne wrote: src/lib/util/kuser_unix.cpp, line 217 https://git.reviewboard.kde.org/r/116881/diff/1/?file=255229#file255229line217 Not sure what you mean with the comment here. Shouldn't gid_buffer[i] be just as safe (if not more) than obtaining the gid_t* and then dereferencing that as an array? I only used reserve() and not resize(), but I guess that was a premature optimization. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/#review53383 --- On March 18, 2014, 9:14 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- (Updated March 18, 2014, 9:14 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUser::groups() and KUser::groupNames() on UNIX If available we use getgrouplist() which returns all group IDs. Otherwise we fall back to using getgrent() and checking whether gr_mem contains the user. For some reason gr_mem doesn't usally contain the users primary gid, so we add the corresponding struct group for that gid as well. Diffs - src/lib/CMakeLists.txt 73f28a8a3acda8449a3aee3b025e2b165722b998 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116881/diff/ Testing --- Returns more groups now, should fix KUserTest::testKUser() on build.kde.org File Attachments old user-groups result (getgrent) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/86c5e986-8098-4c50-809c-bc3e7851447a__grouplist_getgrent_old.txt new user-groups result (getgrouplist) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/59f4ecda-5c1d-4bdc-a8ec-850de761e3a3__grouplist_getgrouplist.txt new user-groups result (getgrent + current gid) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/39d0172d-f6c8-400e-8af0-0c4aace8f7a1__grouplist_getgrent_new.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 17, 2014, 8:33 p.m., Thomas Lübking wrote: src/kwindowsystem_x11.cpp, line 102 https://git.reviewboard.kde.org/r/116787/diff/5/?file=254570#file254570line102 Is this compensated anywhere? Is it actually an issue (since the constructor should operate in the GUI thread)? I commented this out to see if it resulted in any difference in function with Qt5; I didn't notice any difference, but did mean to comment it back in as I did not do a full examination of the code behind the scenes. I've put this line back in here locally. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review53254 --- On March 17, 2014, 9:09 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 17, 2014, 9:09 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - autotests/CMakeLists.txt 073b6dd autotests/kwindowsystem_threadtest.cpp PRE-CREATION src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- (Updated March 19, 2014, 9:20 a.m.) Review request for KDE Frameworks. Changes --- Changed from shouldStop function to maxCount parameter since std::function is always an indirect call Use std::function for the callback (indirect call doesn't matter that much there). Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs (updated) - autotests/kusertest.cpp 369bd56cbba4554b04c03847b74fb023a426f5eb src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ File Attachments Before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/871c8bc5-4631-4759-8103-eb7ac817d698__groupmembers_before.txt After https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/4295e719-acb8-495f-907b-5a93d2d8b64f__groupmembers_after.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
On March 19, 2014, 2:56 a.m., Michael Pyne wrote: src/lib/util/kuser_unix.cpp, line 349 https://git.reviewboard.kde.org/r/116883/diff/1/?file=255233#file255233line349 Does this need to be a template, or would std::function be sufficient? Templates have a poor reputation amongst some of our devs so I wouldn't make them the first answer unless they cleanly fit the problem. Alexander Richardson wrote: I think std::function is much nicer as well, because it allows specifying the argument list. However I think the compiler won't inline the std::function. Probably not that important, since this code will rarely be called, but I'll check that first. Not voting for anything, but Michael: Templates have a poor reputation amongst some of our devs - Then it's our job to educate these developers. std::function is also a template with additional type erasure on top. If at all, it's more complicated than passing a functor directly. Considering that this function is internal (in a .cpp file), I don't see why this should be a std::function. - Milian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/#review53382 --- On March 19, 2014, 8:20 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- (Updated March 19, 2014, 8:20 a.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs - autotests/kusertest.cpp 369bd56cbba4554b04c03847b74fb023a426f5eb src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ File Attachments Before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/871c8bc5-4631-4759-8103-eb7ac817d698__groupmembers_before.txt After https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/4295e719-acb8-495f-907b-5a93d2d8b64f__groupmembers_after.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 17, 2014, 9:33 p.m., Thomas Lübking wrote: src/kwindowsystem_x11.cpp, line 102 https://git.reviewboard.kde.org/r/116787/diff/5/?file=254570#file254570line102 Is this compensated anywhere? Is it actually an issue (since the constructor should operate in the GUI thread)? Aaron J. Seigo wrote: I commented this out to see if it resulted in any difference in function with Qt5; I didn't notice any difference, but did mean to comment it back in as I did not do a full examination of the code behind the scenes. I've put this line back in here locally. I'm pretty sure it's not needed. We get the root window without having called qApp-desktop(). Quite sure about it, because I migrated QX11Info::appRootWindow() away from doing exactly what this line of code was doing. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review53254 --- On March 17, 2014, 10:09 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 17, 2014, 10:09 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - autotests/CMakeLists.txt 073b6dd autotests/kwindowsystem_threadtest.cpp PRE-CREATION src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QML Bindings for KDE frameworks, take 2
On Tuesday 18 March 2014, Kevin Ottens wrote: On Tuesday 18 March 2014 19:37:59 Marco Martin wrote: what we currently have is: * dirmodel: is a binding to kdirmodel - KIO? (i would probably not release it yet but waiting to have folderview done so needed features are more clear) Would make sense in a KIO import indeed. About that one, it will probably be delayed (so would be for frameworks 5.1 or later) Since Eike did another one for folderview that has more features, we'll factor it out and make a public plugin out of that binding, will take a bit more time tough. Since there aren't plasmoids in plasma next using that dirmodel at the moment, i'll not release it at first. -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Plasma Next + Apps view on build.kde.org
Just a quick note to let you know I created a new view on build.kde.org which groups the jobs from Plasma Next and the available KF5 applications. You can find it here: http://build.kde.org/view/Plasma%20Next%20+%20Apps/ I hope it helps you tracking the state of our code. Feel free to extend it with other jobs as they become available. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next + Apps view on build.kde.org
On Wednesday 19 March 2014, Aurélien Gâteau wrote: Just a quick note to let you know I created a new view on build.kde.org which groups the jobs from Plasma Next and the available KF5 applications. You can find it here: http://build.kde.org/view/Plasma%20Next%20+%20Apps/ I hope it helps you tracking the state of our code. Feel free to extend it with other jobs as they become available. dude, that's awesome :D -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next + Apps view on build.kde.org
On Wednesday, March 19, 2014 03:07:27 Aurélien Gâteau wrote: Just a quick note to let you know I created a new view on build.kde.org which groups the jobs from Plasma Next and the available KF5 applications. You can find it here: http://build.kde.org/view/Plasma%20Next%20+%20Apps/ I hope it helps you tracking the state of our code. Feel free to extend it with other jobs as they become available. Nice. :) Could you also add plasma-framework and perhaps krunner and kactivities? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Plasma Next + Apps view on build.kde.org
On Wed, Mar 19, 2014, at 3:29, Sebastian Kügler wrote: On Wednesday, March 19, 2014 03:07:27 Aurélien Gâteau wrote: Just a quick note to let you know I created a new view on build.kde.org which groups the jobs from Plasma Next and the available KF5 applications. You can find it here: http://build.kde.org/view/Plasma%20Next%20+%20Apps/ I hope it helps you tracking the state of our code. Feel free to extend it with other jobs as they become available. Nice. :) Could you also add plasma-framework and perhaps krunner and kactivities? Just did so. Note that those are already in http://build.kde.org/view/Frameworks/ (a good one to have in your bookmarks as well), but it doesn't hurt to have a job in multiple views. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116894: Clean up comments that reference kde4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116894/ --- Review request for KDE Frameworks. Repository: kservice Description --- Clean up comments about removed syscoca type numbers Remove explanation of why the desktoptojson target is exported The explanation was wrong, and it doesn't really need any justification anyway. Remove comment about test finding kmailservice from KDE4 It won't find the wrong kmailservice, because the desktop file is now called kmailservice5. Diffs - autotests/kservicetest.cpp 711fb9b649e580ad474b0cdecd26dcdbfdc302a2 src/desktoptojson/CMakeLists.txt f106d254e015fc4eccf12fb4437ec221fb64ba1b src/sycoca/ksycocatype.h 54276a6bc04d8a48be8c4022250453e4c9993279 Diff: https://git.reviewboard.kde.org/r/116894/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116895: Break ksycoca binary compatibility
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/ --- Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Break ksycoca binary compatibility Resolve the KDE5 todo by removing a dummy field. Also update the related comments. Diffs - src/services/kservice.cpp 874ec66ea5ba8d50bfb82441644ba94295b2361a src/sycoca/ksycoca.cpp 6c67bb4f07f3f80aa2821fb5efe702259f1163b3 Diff: https://git.reviewboard.kde.org/r/116895/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/#review53410 --- src/kcompletion_p.h https://git.reviewboard.kde.org/r/116886/#comment37578 This is not strictly related to your changes, but it looks a bit unusual to have one plain bool and two bool bitfields next to each other. Making all bools a bitfield won't make much difference now though because the compiler will always use more memory for this class in order to preserve the 4-byte or 8-byte alignment. Another alignment-related issue is caused by your patch though: on a 64-bit system, moving the int member away from the bools will most likely increase sizeof(KCompletionPrivate) by 8 bytes because the compiler will add some padding to both in order to preserve the alignment of the neigbouring pointers. It might not make a big difference because it's probably unusual to create thousands of KCompletionPrivate instances, but still, it seems unnecessary. If one really wanted to make use of bitfields to save memory here, one could make 'order' a bitfield and move it next to the bools. - Frank Reininghaus On March 18, 2014, 11:01 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 18, 2014, 11:01 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs - src/kcompletion_p.h e3fad26 src/kcompletion.cpp 7396029 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116899: Remove unused QtWidgets dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/ --- Review request for KDE Frameworks. Repository: kinit Description --- It looks to be unused currently, so remove it. Diffs - CMakeLists.txt b5ec044da270bda4536d31e021d11f2a89c838d9 Diff: https://git.reviewboard.kde.org/r/116899/diff/ Testing --- Inspected source. A build test is difficult since some of kinit's dependencies have QtWidgets as a public dependency. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 17, 2014, 8:33 p.m., Thomas Lübking wrote: src/kwindowsystem_x11.cpp, line 102 https://git.reviewboard.kde.org/r/116787/diff/5/?file=254570#file254570line102 Is this compensated anywhere? Is it actually an issue (since the constructor should operate in the GUI thread)? Aaron J. Seigo wrote: I commented this out to see if it resulted in any difference in function with Qt5; I didn't notice any difference, but did mean to comment it back in as I did not do a full examination of the code behind the scenes. I've put this line back in here locally. Martin Gräßlin wrote: I'm pretty sure it's not needed. We get the root window without having called qApp-desktop(). Quite sure about it, because I migrated QX11Info::appRootWindow() away from doing exactly what this line of code was doing. Ah, great. When I tested without that line, everything seemed to work exactly as expected. I just didn't have time to delve into the code further to confirm the anecdotal evidence ;) So... can I push? :) - Aaron J. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review53254 --- On March 17, 2014, 9:09 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 17, 2014, 9:09 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - autotests/CMakeLists.txt 073b6dd autotests/kwindowsystem_threadtest.cpp PRE-CREATION src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116895: Break ksycoca binary compatibility
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/#review53413 --- Ship it! Ship It! - David Faure On March 19, 2014, 11:40 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/ --- (Updated March 19, 2014, 11:40 a.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Break ksycoca binary compatibility Resolve the KDE5 todo by removing a dummy field. Also update the related comments. Diffs - src/services/kservice.cpp 874ec66ea5ba8d50bfb82441644ba94295b2361a src/sycoca/ksycoca.cpp 6c67bb4f07f3f80aa2821fb5efe702259f1163b3 Diff: https://git.reviewboard.kde.org/r/116895/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116895: Break ksycoca binary compatibility
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/#review53414 --- This review has been submitted with commit acee7859819b939f92072a7c765626f088681e8c by Alex Merry to branch master. - Commit Hook On March 19, 2014, 11:40 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/ --- (Updated March 19, 2014, 11:40 a.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Break ksycoca binary compatibility Resolve the KDE5 todo by removing a dummy field. Also update the related comments. Diffs - src/services/kservice.cpp 874ec66ea5ba8d50bfb82441644ba94295b2361a src/sycoca/ksycoca.cpp 6c67bb4f07f3f80aa2821fb5efe702259f1163b3 Diff: https://git.reviewboard.kde.org/r/116895/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116895: Break ksycoca binary compatibility
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116895/ --- (Updated March 19, 2014, 1:41 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Break ksycoca binary compatibility Resolve the KDE5 todo by removing a dummy field. Also update the related comments. Diffs - src/services/kservice.cpp 874ec66ea5ba8d50bfb82441644ba94295b2361a src/sycoca/ksycoca.cpp 6c67bb4f07f3f80aa2821fb5efe702259f1163b3 Diff: https://git.reviewboard.kde.org/r/116895/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kservice_master_qt5 #69
See http://build.kde.org/job/kservice_master_qt5/69/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
On March 17, 2014, 9:33 p.m., Thomas Lübking wrote: src/kwindowsystem_x11.cpp, line 102 https://git.reviewboard.kde.org/r/116787/diff/5/?file=254570#file254570line102 Is this compensated anywhere? Is it actually an issue (since the constructor should operate in the GUI thread)? Aaron J. Seigo wrote: I commented this out to see if it resulted in any difference in function with Qt5; I didn't notice any difference, but did mean to comment it back in as I did not do a full examination of the code behind the scenes. I've put this line back in here locally. Martin Gräßlin wrote: I'm pretty sure it's not needed. We get the root window without having called qApp-desktop(). Quite sure about it, because I migrated QX11Info::appRootWindow() away from doing exactly what this line of code was doing. Aaron J. Seigo wrote: Ah, great. When I tested without that line, everything seemed to work exactly as expected. I just didn't have time to delve into the code further to confirm the anecdotal evidence ;) So... can I push? :) yes, looks good to me. Just remove the commented line (I assume you have already done so, given that you resolved the issue). - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/#review53254 --- On March 17, 2014, 10:09 a.m., Aaron J. Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 17, 2014, 10:09 a.m.) Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - autotests/CMakeLists.txt 073b6dd autotests/kwindowsystem_threadtest.cpp PRE-CREATION src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ 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 : kservice_master_qt5 #71
See http://build.kde.org/job/kservice_master_qt5/71/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KLibrary: what is it good for?
While trying to clean up KDE 4 references in KService, I've been looking
at KLibrary.
This basically does two things: it has a factory() method that has been
deprecated since before kdelibs 4.0.0, and it does some extra lookup magic.
KLibrary::factory() is used by KPluginLoader for compatibility magic
(this has been compatiblity code since 4.0.0, I think, and has a KDE5:
remove comment).
As far as I can tell, the library lookup magic was originally to look
for plugins in a module directory specified by KComponentData. Now that
this has been removed, it appears to just messily duplicate QLibrary's
own internal lookup logic, except that it looks in kf5 subdirectories
of QCoreApplication::libraryPaths() (and prints a -- misleadingly worded
-- warning if a library starting with libkdeinit5_ was not in this kf5
subdirectory).
With this in mind, I would suggest ditching the (pre-KDE-4) compatiblity
stuff and putting KLibrary into kde4support as essentially a typedef for
QLibrary. KPluginLoader might still want to check the kf5 subdirectory,
since that's the value of ${PLUGIN_INSTALL_DIR} in KDEInstallDirs.cmake.
Alternatively, we could keep KLibrary where it is, but remove everything
except for the lookup magic (which probably wants cleaning up).
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: plasma-framework_master_qt5 » All,LINBUILDER #161
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/161/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLibrary: what is it good for?
On 19/03/14 14:29, Alex Merry wrote:
While trying to clean up KDE 4 references in KService, I've been looking
at KLibrary.
This basically does two things: it has a factory() method that has been
deprecated since before kdelibs 4.0.0, and it does some extra lookup magic.
KLibrary::factory() is used by KPluginLoader for compatibility magic
(this has been compatiblity code since 4.0.0, I think, and has a KDE5:
remove comment).
As far as I can tell, the library lookup magic was originally to look
for plugins in a module directory specified by KComponentData. Now that
this has been removed, it appears to just messily duplicate QLibrary's
own internal lookup logic, except that it looks in kf5 subdirectories
of QCoreApplication::libraryPaths() (and prints a -- misleadingly worded
-- warning if a library starting with libkdeinit5_ was not in this kf5
subdirectory).
With this in mind, I would suggest ditching the (pre-KDE-4) compatiblity
stuff and putting KLibrary into kde4support as essentially a typedef for
QLibrary. KPluginLoader might still want to check the kf5 subdirectory,
since that's the value of ${PLUGIN_INSTALL_DIR} in KDEInstallDirs.cmake.
Alternatively, we could keep KLibrary where it is, but remove everything
except for the lookup magic (which probably wants cleaning up).
Note that KSocks and KLibLoader in kde4support both use
KLibrary::factory(). KSocks could be removed, as LXR says nothing uses
it. KLibLoader is used by a depressing number of things, given it has
been deprecated since kdelibs 4.0 (KLibrary is also used by quite a few
things, but that was never totally deprecated).
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116787: Always create NETEventFilter (a QWidget subclass) in the main application thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116787/ --- (Updated March 19, 2014, 3:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kwin and Martin Gräßlin. Repository: kwindowsystem Description --- When using KWindowInfo from a thread other than the main application thread, the application fails on an assert triggered by creating a QWidget in another thread. This is due to NETEventFilter being a QWidget. This patch addresses the issue by using a QObject to create the NETEventFilter, which is itself first moved to the main application thread. Diffs - autotests/CMakeLists.txt 073b6dd autotests/kwindowsystem_threadtest.cpp PRE-CREATION src/kwindowsystem.cpp 4c17baa src/kwindowsystem_p_x11.h 75f3028 src/kwindowsystem_x11.cpp 95c396b Diff: https://git.reviewboard.kde.org/r/116787/diff/ Testing --- Used in the Sprinter Windows plugin and works lovely to find desktops, windows, etc. Thanks, Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLibrary: what is it good for?
On Wednesday 19 March 2014 15:19:12 Alex Merry wrote:
On 19/03/14 14:29, Alex Merry wrote:
While trying to clean up KDE 4 references in KService, I've been looking
at KLibrary.
This basically does two things: it has a factory() method that has been
deprecated since before kdelibs 4.0.0, and it does some extra lookup
magic.
KLibrary::factory() is used by KPluginLoader for compatibility magic
(this has been compatiblity code since 4.0.0, I think, and has a KDE5:
remove comment).
As far as I can tell, the library lookup magic was originally to look
for plugins in a module directory specified by KComponentData. Now that
this has been removed, it appears to just messily duplicate QLibrary's
own internal lookup logic, except that it looks in kf5 subdirectories
of QCoreApplication::libraryPaths() (and prints a -- misleadingly worded
-- warning if a library starting with libkdeinit5_ was not in this kf5
subdirectory).
With this in mind, I would suggest ditching the (pre-KDE-4) compatiblity
stuff and putting KLibrary into kde4support as essentially a typedef for
QLibrary. KPluginLoader might still want to check the kf5 subdirectory,
since that's the value of ${PLUGIN_INSTALL_DIR} in KDEInstallDirs.cmake.
Alternatively, we could keep KLibrary where it is, but remove everything
except for the lookup magic (which probably wants cleaning up).
Note that KSocks and KLibLoader in kde4support both use
KLibrary::factory(). KSocks could be removed, as LXR says nothing uses
it. KLibLoader is used by a depressing number of things, given it has
been deprecated since kdelibs 4.0 (KLibrary is also used by quite a few
things, but that was never totally deprecated).
That sounds like moving KLibrary as it is to kdelibs4support and not using a
typedef.
/me puts removing KLibrary in KWin to number 1 item on tomorrow's TODO list.
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
Jenkins build is still unstable: plasma-framework_master_qt5 » All,LINBUILDER #162
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: plasma-framework_master_qt5 » NoX11,LINBUILDER #161
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/161/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QML Bindings for KDE frameworks, take 2
On Tuesday 18 March 2014, Kevin Ottens wrote: * QtExtracomponents: qt only except kiconthemes (i would go into making it less pretty and remove the kiconthemes dependency) Yes, please make it independent of KIconThemes, and then could be renamed into KQuickControlsAddons? so, in the end kdeclarative or kquickcontrols repository? for plasma people: would be ok for you renaming QtExtracomponents to KQuickControlsAddons? may be cleaner even tough work and danger ;) -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 alpha2
On Wednesday 12 March 2014 12:21:36 Christoph Cullmann wrote: David Faure wrote: On Wednesday 05 March 2014 19:29:34 Michael Palimaka wrote: Hi, KTextEditor is listed as tier 3, but is missing from this (and previous) releases. It is not part of the KF 5.0 release, it targets 5.1. Hi, is there any reason for that? Would delay us from releasing some KF 5 port of Kate for common consumption after the KF 5.0 release. No idea, please ask the KTextEditor maintainers. Wait, that's you... I thought this was a request from you, because it wouldn't be ready for 5.0? I'm confused. What made me think so is that it's under 5.1 in the wiki page http://community.kde.org/Frameworks/Epics and that it still has many SIC changes TODO there. So I thought this was intentional. If it's not, let's fix that quickly. Hi, most SIC stuff now done. Some small things remain and are either done until 28th or they will stay in that shape for KF 5.x, which would be ok, too. Removed some completely unrealistic items like split out the highlighting stuff, which is a long term goal and can be done SC/BC later. I would appreciate any hint on what is needed more to have ktexteditor in the KF 5.0 release as I think it would give applications like Kate/KDevelop/Kile/... the possibility to have KF 5.0 ports available. Kate/KWrite itself is really KF 5 ready ;) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworksintegration of QFileDialog::getExistingDirectory (was: add test for QFileDialog::getExistingDirectory / bug?)
n Tue, Mar 18, 2014 at 9:11 PM, Dominik Haumann dhaum...@kde.org wrote: Hi, getting an existing directory is still broken with current frameworks integration. A call of: QString dir = QFileDialog::getExistingDirectory(); results in this image: http://wstaw.org/m/2014/03/18/plasma-desktopdF1903.png Whereas what you actually want is this: http://wstaw.org/m/2014/03/18/plasma-desktopdI1903.png (This was obtained with the KF5 version of: kdialog --getexistingdirectory ~ Would be cool, if someone with more knowledge in frameworks integration could have a look here. Greetings, Dominik On Sunday 26 January 2014 17:15:08 Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Dominik, I've been looking though it and it seems like in this case we should be showing KDirSelectDialog instead of a QDialog+KFileWidget, depending on the result of options()-testOption(QFileDialogOptions::ShowDirsOnly). I don't really have the time of doing it this week, but I'd certainly would like to have it. If you want to work on it I can review and give you a hand, if you can't this will have to be done before frameworksintegration is released. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: plasma-framework_master_qt5 » NoX11,LINBUILDER #162
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[knotifications] src: Relicense the KNotify parts from GPL to LGPLv2.1+
Git commit db9b5ac8e13491ad6d8cb5a5e9c897be4aa68429 by Martin Klapetek. Committed on 19/03/2014 at 11:49. Pushed by mklapetek into branch 'master'. Relicense the KNotify parts from GPL to LGPLv2.1+ Copyright holders and contributors (from git log svn log) were contacted and asked for permission to change the license from GPL to LGPLv2.1+. CC'ing the frameworks list so this can serve as a public record of the relicensing; below is a list of the copyright holders that gave the permission to relicense their contributions. Patrick von Rethpatrick.vonr...@gmail.com Aaron J. Seigo ase...@kde.org Jeffery MacEachern j.maceach...@gmail.com Sjors Gielendazj...@dazjorz.com David Faure fa...@kde.org Olivier Goffart ogoff...@kde.org Dirk Muellermuel...@kde.org Luboš Luňák l.lu...@kde.org Lamarque V. Souza lamar...@gmail.com Aurélien Gâteau agat...@kde.org Matthias Kretz kr...@kde.org Dmitry Suzdalev dim...@gmail.com Oswald Buddenhagen o...@kde.org Chusslove Illichcaslav.i...@gmx.net Rob Scheepmaker r.scheepma...@student.utwente.nl Jacopo De Simoi wilder...@gmail.com Laurent Montel mon...@kde.org Thiago Macieira thi...@kde.org Roman Jaroszkedge...@gmail.com Loic Marteauloic.mart...@gmail.com Charles Samuels char...@kde.org Stefan Schimanski 1st...@gmx.de Matthias Ettrichettr...@kde.org Waldo Bastian bast...@kde.org Carsten Pfeifferpfeif...@kde.org Stephan Kulow co...@kde.org Hans Petter Bieker bie...@kde.org Simon Hausmann hausm...@kde.org Malte Starostik ma...@kde.org Richard Moore r...@kde.org Stefan Westerfeld ste...@space.twc.de Allan Sandfeld Jensen k...@carewolf.com CCMAIL: kde-frameworks-devel@kde.org M +13 -12 src/knotifyconfig.cpp M +13 -12 src/knotifyconfig.h M +13 -12 src/knotifyplugin.cpp M +13 -12 src/knotifyplugin.h M +10 -9src/notifybyaudio.cpp M +10 -9src/notifybyaudio.h M +13 -12 src/notifybyexecute.cpp M +13 -12 src/notifybyexecute.h M +13 -12 src/notifybyktts.cpp M +13 -11 src/notifybyktts.h M +13 -12 src/notifybylogfile.cpp M +13 -12 src/notifybylogfile.h M +13 -11 src/notifybypopup.cpp M +13 -12 src/notifybypopup.h M +12 -10 src/notifybypopupgrowl.cpp M +13 -11 src/notifybypopupgrowl.h M +13 -12 src/notifybytaskbar.cpp M +13 -12 src/notifybytaskbar.h http://commits.kde.org/knotifications/db9b5ac8e13491ad6d8cb5a5e9c897be4aa68429 diff --git a/src/knotifyconfig.cpp b/src/knotifyconfig.cpp index e2e5799..4a7ecc8 100644 --- a/src/knotifyconfig.cpp +++ b/src/knotifyconfig.cpp @@ -1,20 +1,21 @@ /* Copyright (C) 2005-2009 by Olivier Goffart ogoffart at kde.org - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2, or (at your option) - any later version. - - This program is distributed in the hope that it will be useful, + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) version 3, or any + later version accepted by the membership of KDE e.V. (or its + successor approved by the membership of KDE e.V.), which shall + act as a proxy defined in Section 6 of version 3 of the license. + + This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + You should have received a copy of the GNU Lesser General Public + License along with this library. If not, see http://www.gnu.org/licenses/. */ diff --git a/src/knotifyconfig.h b/src/knotifyconfig.h index d6b1770..fae17cb 100644 --- a/src/knotifyconfig.h +++ b/src/knotifyconfig.h @@ -1,20 +1,21 @@ /* Copyright (C) 2005-2009 by Olivier Goffart ogoffart at kde.org - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2, or (at your option) - any later version. - - This program is distributed in the hope that it will be useful, + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free
Re: Query: Possible code contribution
On 3/16/14, Kevin Krammer kram...@kde.org wrote: On Sunday, 2014-03-16, 00:16:45, Lydia Pintscher wrote: On Fri, Mar 14, 2014 at 2:40 PM, Ganesh Kumar gp29111...@gmail.com wrote: Hi. This is Ganesh P Kumar, doing my B.Tech in Computer Science and Engineering in IIT Madras. As part of our curriculum we must contribute code to an open source project. There is a deadline of 40 days for the project submission. Given this small deadline, I would like to ask for suggestions from the KDE Developer group about what would be a viable project during this time. We are ok with working either with the KDE UI as such, or with any KDE subproject. Also, I would like to add that none of us have any dev experience in KDE before. Would a project to fix several small little issues be viable? Then you could maybe work with the designers/usability team and help them out a bit. 40 days is really not much. One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. CCing the frameworks development list. Cheers, Kevin [1] https://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out [2] http://community.kde.org/Frameworks -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring Hi Kevin, I can write some examples as I have some time want to contribute. However, I will need some guidance. I found a examples directory in karchive. Is that what is required? Can someone please suggest a framework which is simple with which I can start creating examples? -- Harsh Kumar harshkumar.in ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116886: Refactor private variables of KCompletion
On March 19, 2014, 11:55 a.m., Frank Reininghaus wrote: src/kcompletion_p.h, line 338 https://git.reviewboard.kde.org/r/116886/diff/2/?file=255262#file255262line338 This is not strictly related to your changes, but it looks a bit unusual to have one plain bool and two bool bitfields next to each other. Making all bools a bitfield won't make much difference now though because the compiler will always use more memory for this class in order to preserve the 4-byte or 8-byte alignment. Another alignment-related issue is caused by your patch though: on a 64-bit system, moving the int member away from the bools will most likely increase sizeof(KCompletionPrivate) by 8 bytes because the compiler will add some padding to both in order to preserve the alignment of the neigbouring pointers. It might not make a big difference because it's probably unusual to create thousands of KCompletionPrivate instances, but still, it seems unnecessary. If one really wanted to make use of bitfields to save memory here, one could make 'order' a bitfield and move it next to the bools. This is not strictly related to your changes, but it looks a bit unusual to have one plain bool and two bool bitfields next to each other. I know, but I can't change it without changing the method 'void findAllCompletions(const QString , KCompletionMatchesWrapper *matches, bool hasMultipleMatches) const' in kcompletion_p.h. The boolean parameter is passed as a reference and therefore the compiler complains it can't be a bitfield. That method is doomed to be moved elsewhere. Then I will change that bool to bitfield. If one really wanted to make use of bitfields to save memory here, one could make 'order' a bitfield and move it next to the bools. Ok, let's see if I do it well :-) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/#review53410 --- On March 18, 2014, 11:01 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 18, 2014, 11:01 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs - src/kcompletion_p.h e3fad26 src/kcompletion.cpp 7396029 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 19, 2014, 10:52 p.m.) Review request for KDE Frameworks. Changes --- Add TODO item for hasMultipleMatches variable. Convert order variable to bitfield, following Frank's suggestion. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs (updated) - src/kcompletion.cpp 7396029 src/kcompletion_p.h e3fad26 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 19, 2014, 11:01 p.m.) Review request for KDE Frameworks. Changes --- Reduce order variable bitfield. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs (updated) - src/kcompletion.cpp 7396029 src/kcompletion_p.h e3fad26 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116912: Remove KSocks and KSocksSocketDevice
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116912/ --- Review request for KDE Frameworks. Repository: kde4support Description --- Remove KSocks and KSocksSocketDevice LXR says these are entirely unused, they have been deprecated since 4.0 and k3socks.cpp makes use of the long-deprecated KLibrary::factory() method. Diffs - src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/kdecore/k3socks.h 51f8a4f2443b510b530c2afaa192271b6a6f00aa src/kdecore/k3socks.cpp 920340b14899b56b300607326e5da6fc810095b8 src/kdecore/k3sockssocketdevice.h 2197ce63f2d96415da5949bdaff83a4f694eef53 src/kdecore/k3sockssocketdevice.cpp dae2f75fbafbd4f1d91fb8503669220f6bf7475e Diff: https://git.reviewboard.kde.org/r/116912/diff/ Testing --- Built, installed, ran tests. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116913: Remove KParts::ComponentFactory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116913/ --- Review request for KDE Frameworks. Repository: kde4support Description --- Remove KParts::ComponentFactory All the methods in this namespace have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says the only users are a couple of projects that haven't even made it onto projects.kde.org. Diffs - src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/includes/CMakeLists.txt 048d474583a1ce9e5f142ad3ffb4d4ccb7f3 src/includes/KParts/ComponentFactory 5d7c2f1f9a2ba02e19517c727f06ce3e7bf057b0 src/kparts/componentfactory.h 8fba1c667144e47f6645c7830c459a1dbb0a926e Diff: https://git.reviewboard.kde.org/r/116913/diff/ Testing --- Built and installed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116912: Remove KSocks and KSocksSocketDevice
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116912/ --- (Updated March 20, 2014, 12:33 a.m.) Review request for KDE Frameworks. Changes --- Failed to remove some files/references. Repository: kde4support Description --- Remove KSocks and KSocksSocketDevice LXR says these are entirely unused, they have been deprecated since 4.0 and k3socks.cpp makes use of the long-deprecated KLibrary::factory() method. Diffs (updated) - src/includes/CMakeLists.txt 048d474583a1ce9e5f142ad3ffb4d4ccb7f3 src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/includes/KNetwork/KSocksSocketDevice f2b7cea900c73545d751f8b03fdcd0e46e51c659 src/includes/KSocks bf29d0350fe1241820efffbdb39f72f353123a15 src/kdecore/k3socketdevice.cpp da772b0196f35870ee1d87b43e4941519bcb661b src/kdecore/k3socks.h 51f8a4f2443b510b530c2afaa192271b6a6f00aa src/kdecore/k3socks.cpp 920340b14899b56b300607326e5da6fc810095b8 src/kdecore/k3sockssocketdevice.h 2197ce63f2d96415da5949bdaff83a4f694eef53 src/kdecore/k3sockssocketdevice.cpp dae2f75fbafbd4f1d91fb8503669220f6bf7475e Diff: https://git.reviewboard.kde.org/r/116912/diff/ Testing (updated) --- Built, installed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116914: Remove KLibLoader::createInstance methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/ --- Review request for KDE Frameworks. Repository: kde4support Description --- Remove KLibLoader::createInstance methods These have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says there is a single user: jovie (in kdeaccessibility). Depends on 116913, because KParts::ComponentFactory methods make use of KLibLoader error codes. Diffs - autotests/klibloadertest.h 7307fea0ef69b302eb64aa121e4af54e034c24ab autotests/klibloadertest.cpp a6aebd278ea8e7121ccbb91422d08964d8dcf07a src/kdecore/klibloader.h 07d0c1c4bd4747b394745d9b7af0765874c4d6e3 src/kdecore/klibloader.cpp b9d0625025445f7c200608be06433bd19ec6ead0 Diff: https://git.reviewboard.kde.org/r/116914/diff/ Testing --- Builds, compiles, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: plasma-framework_master_qt5 » All,LINBUILDER #163
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
