Re: kcoreaddons: is src/mimetypes/kde.xml still in use?
On Wed, Apr 9, 2014, at 9:57, Burkhard Lück wrote: Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau: Hi, I am trying to figure out which code is responsible for loading xml_mimetypes.po. This file is produced by scripty when running on kcoreaddons, but I can't find any code actually loading the catalog. Is my git grep fu too weak? No, this is just a intermediate file, not loaded directly, of an only half finished solution to translate MIME type entries, see http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html What do you recommend we do for it then? Rename it to xml_mimetypes5.po or just remove it? Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons: is src/mimetypes/kde.xml still in use?
On Wed, Apr 9, 2014, at 9:57, Burkhard Lück wrote: Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau: Hi, I am trying to figure out which code is responsible for loading xml_mimetypes.po. This file is produced by scripty when running on kcoreaddons, but I can't find any code actually loading the catalog. Is my git grep fu too weak? No, this is just a intermediate file, not loaded directly, of an only half finished solution to translate MIME type entries, see http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html What do you recommend we do for it then? Rename it to xml_mimetypes5.po or just remove it? Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Writing a Frameworks book at Randa
On Wed, Apr 9, 2014, at 6:05, Kevin Funk wrote: On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote: Hello folks, I know that August is months away, but if you want your Frameworks book, now is the time to step forward. Here are some things to think about: Most of this book is already written somewhere. When the words have already been written down, all we need do is gather and arrange them. When you think of such an email, dot story, blog post or have eloquent thoughts in your head, please make a note. If you are on this list, you are an expert. You know what the Frameworks will do for KDE, and you know what they *can* do for others. Our book will present that case. A good book will help grow the Frameworks team; I'm sure of it. And a good book will make your work more widely used. Oh, and you'll be a published author! While in Randa, none of us will be writing full-time. In fact, I hope that *all* of the Frameworks people will stop by the writing room, or log into Booki and review, add, re-arrange, correct, or make the text more graceful. To make this work a few people must volunteer to take on the writing of the book as their most important task at Randa. It will be mine, and our goal is to have a book by the end of the week. We've done it before, and I know we can do it again. This is a valuable work. We need to know the core members of this team, soon. Please step forward, and also add yourself to the Spints page for planning and funding. Valorie Hey, I'm wondering if we should rather try spending the time in making our KF5 apidocs shine. You could spend plenty of time on writing introductory parts for the individual modules, writing tutorials and examples, and make sure they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an integral part for the docs on qt-project.org, too. Just have a look at the first hit for qt docs: [1] I agree with this. I think api docs have a higher chance of remaining relevant than a book. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Writing a Frameworks book at Randa
On Thu, Apr 10, 2014 at 1:26 AM, Aurélien Gâteau agat...@kde.org wrote: On Wed, Apr 9, 2014, at 6:05, Kevin Funk wrote: On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote: Hello folks, I know that August is months away, but if you want your Frameworks book, now is the time to step forward. Here are some things to think about: Most of this book is already written somewhere. When the words have already been written down, all we need do is gather and arrange them. When you think of such an email, dot story, blog post or have eloquent thoughts in your head, please make a note. If you are on this list, you are an expert. You know what the Frameworks will do for KDE, and you know what they *can* do for others. Our book will present that case. A good book will help grow the Frameworks team; I'm sure of it. And a good book will make your work more widely used. Oh, and you'll be a published author! While in Randa, none of us will be writing full-time. In fact, I hope that *all* of the Frameworks people will stop by the writing room, or log into Booki and review, add, re-arrange, correct, or make the text more graceful. To make this work a few people must volunteer to take on the writing of the book as their most important task at Randa. It will be mine, and our goal is to have a book by the end of the week. We've done it before, and I know we can do it again. This is a valuable work. We need to know the core members of this team, soon. Please step forward, and also add yourself to the Spints page for planning and funding. Valorie Hey, I'm wondering if we should rather try spending the time in making our KF5 apidocs shine. You could spend plenty of time on writing introductory parts for the individual modules, writing tutorials and examples, and make sure they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an integral part for the docs on qt-project.org, too. Just have a look at the first hit for qt docs: [1] I agree with this. I think api docs have a higher chance of remaining relevant than a book. Aurélien There is no denying that apidox are crucially important. And I hope that some of what we write can contribute to that, perhaps. But I am in no way qualified to write those, while I am qualified to help this team write a book. Members of the team spoke up and felt that that was a useful thing to do. Obviously the audience we'd write for would be heading for the apidox once they got interested enough to investigate the frameworks for their projects. A book can only be introductory, for the reasons you all have stated. Valorie -- http://about.me/valoriez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we will end up like in kde-workspace form KDE4 with a bunch of code nobody even knows what it does. We need to sort the house and do spring cleaning and this is our chance to do so. 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: Re: Writing a Frameworks book at Randa
On Thursday 10 April 2014 01:42:13 Valorie Zimmerman wrote: On Thu, Apr 10, 2014 at 1:26 AM, Aurélien Gâteau agat...@kde.org wrote: On Wed, Apr 9, 2014, at 6:05, Kevin Funk wrote: On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote: Hello folks, I know that August is months away, but if you want your Frameworks book, now is the time to step forward. Here are some things to think about: Most of this book is already written somewhere. When the words have already been written down, all we need do is gather and arrange them. When you think of such an email, dot story, blog post or have eloquent thoughts in your head, please make a note. If you are on this list, you are an expert. You know what the Frameworks will do for KDE, and you know what they *can* do for others. Our book will present that case. A good book will help grow the Frameworks team; I'm sure of it. And a good book will make your work more widely used. Oh, and you'll be a published author! While in Randa, none of us will be writing full-time. In fact, I hope that *all* of the Frameworks people will stop by the writing room, or log into Booki and review, add, re-arrange, correct, or make the text more graceful. To make this work a few people must volunteer to take on the writing of the book as their most important task at Randa. It will be mine, and our goal is to have a book by the end of the week. We've done it before, and I know we can do it again. This is a valuable work. We need to know the core members of this team, soon. Please step forward, and also add yourself to the Spints page for planning and funding. Valorie Hey, I'm wondering if we should rather try spending the time in making our KF5 apidocs shine. You could spend plenty of time on writing introductory parts for the individual modules, writing tutorials and examples, and make sure they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an integral part for the docs on qt-project.org, too. Just have a look at the first hit for qt docs: [1] I agree with this. I think api docs have a higher chance of remaining relevant than a book. Aurélien There is no denying that apidox are crucially important. And I hope that some of what we write can contribute to that, perhaps. But I am in no way qualified to write those, while I am qualified to help this team write a book. Members of the team spoke up and felt that that was a useful thing to do. we might have here a chicken-egg problem. Good API documentation would significantly help for writing the book. That is if the API documentation is good someone without deep domain knowledge will be able to write a book about it. But if the API documentation is not good enough it needs domain knowledge to write those. Now what I read out of the thread is that developers think that the time of the domain experts would be better spent writing the API documentation than writing a book. The question now is whether our API documentation is already good enough to write a book without domain experts or if we need to improve the documentation first, whether we could do this at the sprint instead of (or in addition) to writing a book. 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
Re: KDE(Libs)4Support rename
On 10/04/14 06:21, Kevin Ottens wrote: Are there any objections to me pushing this (along with relevant changes - mostly to CMake code and comments - in other repos, of course)? Good to go from my side. The earlier the better for that one. I've got some compatbility CMake code written. I'll push once I've run kdesrc-build to check it does actually work. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
On April 7, 2014, 3:37 p.m., Kevin Ottens wrote: src/ioslaves/http/http.cpp, line 1900 https://git.reviewboard.kde.org/r/117333/diff/3/?file=262392#file262392line1900 What about doing it? :-) Àlex Fiestas wrote: I can do that but in another review if that is ok, this is blocking the merge of apiCleanup (solid) and I would like to do that asap. Kevin Ottens wrote: Then update ASAP. :-) To me it looks like the right point in time to fix it and that looks like a one liner even seeing what else you wrote. Oks, will do today. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/#review55175 --- On April 2, 2014, 2:40 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 2, 2014, 2:40 p.m.) Review request for KDE Frameworks. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/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: Figuring out kde-runtime: localization
On Sun, Feb 23, 2014 at 4:59 PM, Albert Astals Cid aa...@kde.org wrote: El Divendres, 21 de febrer de 2014, a les 13:17:58, Aleix Pol va escriure: Hi, Going through the information we have in kde-runtime [1] we found there are two subdirectories related to localization (localization and l10n) that we couldn't find a correct place to move to. Who is we? Why are you asking the documentation list about this? Can anybody give us a hand and help us figure those out? - localization: has plenty of information regarding different currencies. Yes, used in kcurrencycode.cpp at least (which by the way says see KLocale, which is weird in the kunitconversion framework), I guess you could move it to the kunitconversion framework - l10n: has information about different countries. Yes, the existance of those entry.desktop files is checked by ./kio/src/core/global.cpp ./kconfigwidgets/src/klanguagebutton.cpp ./kxmlgui/src/khelpmenu.cpp ./kde4support/src/kdecore/klocale_kde.cpp If you want to deprecate those files you'll have to fix kio, kconfigwidgets and kxmlgui to use whatever localization system KF5 is planning to use and then move these files to kde4support. Should these go to KI18n? What do those files have to do with translations of strings? Qt? Anybody has plans for those? Cheers, Albert Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization I think that those uses were removed already. Can somebody confirm? If everybody agrees, I'll move kde-runtime/l10n to kde4support. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 10:40:04 Àlex Fiestas wrote: On Wednesday 09 April 2014 11:57:37 Marco Martin wrote: On Wednesday 09 April 2014, Àlex Fiestas wrote: I'm against having anything in plasma-* without maintainer and even less if it is something that is known to have bugs (many) in KDE4. So we wither split it and hope somebody will give love to it or remove it. Not talking about that repo in particular, but... on the other hand, putting stuff in own micro repositories is as swiping under the carpet as leaving them in one of the main ones, if anything it ensures even more that it will go abandoned and unnoticed. If it's stuff that really nobody is even using and is safe to drop, that's ok (would be even ok to just delete it tough) but if is something that the user needs anyways and potentially causes regressions in the experience, it has to stay, and in the place that goes the least unnoticed. Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, Huh? I hope you realize that's the same than putting it in a micro-repository no one builds... I think that Marco meant stay in the least unnoticed place *and* built by default (seemed obvious to me, although it was implicit). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 10, 2014, 12:08 p.m.) Review request for KDE Frameworks. Changes --- Implemented todo. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs (updated) - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.h 2a29a15 src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/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 117333: Remove Solid::Networking usage from KIO
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117333/ --- (Updated April 10, 2014, 12:08 p.m.) Review request for KDE Frameworks. Changes --- Implemented todo. Repository: kio Description --- Replace usage of Solid::Networking with QNetworkConfigurationManager which does everything we want. Diffs - src/filewidgets/kstatusbarofflineindicator.h 0210eb0 src/filewidgets/kstatusbarofflineindicator.cpp b19e42c src/ioslaves/http/http.h 2a29a15 src/ioslaves/http/http.cpp de1a1dd src/kpac/CMakeLists.txt 97bb6b6 src/kpac/config-kpac.h.cmake 440d082 src/kpac/proxyscout.h 3338587 src/kpac/proxyscout.cpp 9574d94 Diff: https://git.reviewboard.kde.org/r/117333/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117475: kmimeassociationstest: remove kde4- prefix from desktop file names
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117475/ --- Review request for KDE Frameworks. Repository: kservice Description --- kmimeassociationstest: remove kde4- prefix from desktop file names The code path this tested no longer exists. Diffs - autotests/kmimeassociationstest.cpp d7b3ac29ca7292c0250286b241f20891c988bab6 Diff: https://git.reviewboard.kde.org/r/117475/diff/ Testing --- Test still passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014, you wrote: in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. one concrete thing that may be done is to do a (yet another) sweep of the things that are from workspace/runtime and being move around, like was done in the sprint, but do it in this mailinglist with more people interested involved. so, the central thing this time will be is it necessary or will it cause significant regressions In this way we can make sure no stuff that has still valid use case (yes, even if all of the people working in the framework hate such component, that's irrelevant :p) is left unported (like a good example is the automounter, i would never use such a thing ever, never the less that's irrelevant and is an important component of a base workspace for too many users, no matter how buggy or unmaintained is) -- Marco Martin ___ 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
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- (Updated April 10, 2014, 1:14 p.m.) Status -- This change has been marked as submitted. 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 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp d1f7381a1e1d10fa1fdcd4b498a8ff007b8789e8 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 116881: Fix KUser::groups() and KUser::groupNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/#review55374 --- This review has been submitted with commit 801544210718d01ef535047482acdd49c53175d6 by Alex Richardson to branch master. - Commit Hook On April 8, 2014, 8:30 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- (Updated April 8, 2014, 8:30 a.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 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp d1f7381a1e1d10fa1fdcd4b498a8ff007b8789e8 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 117078: Allow compiling kio on windows
On March 28, 2014, 4:19 p.m., David Faure wrote: src/core/kioglobal_p.h, line 93 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257279#file257279line93 How is this different from QFileInfo::symLinkTarget()? Why not just port to that? From a quick look through the Qt sources it looks like it does the same thing. On March 28, 2014, 4:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 83 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line83 Why not QFileInfo::isSymLink()? This only works for .lnk files, for real symbolic links it returns false. Guess that needs some more work in Qt. On March 28, 2014, 4:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 61 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line61 Bonus points for contributing this to Qt... There is QFile::link(), but that only creates .lnk files (and doesn't add the .lnk suffix automatically, so they usually don't work). I guess I could let it create a symbolic link first and if that fails fall back to the .lnk files. Same questiong here as with isProcessAlive() On March 28, 2014, 4:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 27 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line27 Bonus points for contributing a static method to QProcess... Makes sense, will try to contribute that. Can it be added here or is that a problem for contributing it to Qt? - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/#review54455 --- On April 4, 2014, 9:20 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/ --- (Updated April 4, 2014, 9:20 p.m.) Review request for KDE Frameworks. Repository: kio Description --- A series of commits (can submit separately if necessary): --- Add S_IXUSR, IRUSR, etc. definitions for Windows --- Add KIOPrivate::isProcessAlive() and KIOPrivate::sendTerminateSignal() kill() does not work on Windows, therefore a WIN32 implementation is needed in order to compile slave.cpp --- Add KIOPrivate::changeOwnership() to avoid directly calling chown() Additionally use KUserId/KGroupId instead of uid_t/gid_t. This allows compiling chmodjob.cpp on Windows. KIOPrivate::changeOwnership is a stub on Windows. However, it has always been like that with the kdewin chmod() implementation, so this is not a regression from kdelibs4. --- Add KIOPrivate::createSymlink() to avoid using symlink() directly --- Minor Windows compile fixes --- Use KUser in KPropertiesDialog This means no more need for getpwent(), etc - works on Windows --- Export the KIOPrivate functions --- Fix kio_http build on Windows --- No longer use uid_t/gid_t in kio_file --- Allow compiling kurlcompletion.cpp on windows --- Add a fake QT_LSTAT for Windows This just calls QT_STAT and adds QT_STAT_LNK flag to st_mode if it is a symlink --- Use KUser in kpropertiesdialog.cpp - no more getgrouplist Diffs - autotests/fileundomanagertest.cpp 3f209f89cc0e2ac48d8eaef7ee73ec18abca9a4c autotests/globaltest.cpp 4367e53b44e077c566316081e21f429ac15b74a0 autotests/kdirlistertest.cpp 10a970416b8874f1e136b460d05378f8f3a86810 autotests/kfileitemtest.h dc1808e726cf6af1605cfda520c7df3832225cc1 autotests/kfileitemtest.cpp 38bd87f4e9facd8e52e9e5fbd98b16011c866b5a autotests/kiotesthelper.h eb9f0f3019deb63506c2a173d700b78daa95ae10 src/core/CMakeLists.txt d897e370baedbe06b267934c123acee7a149adff src/core/chmodjob.cpp 271869bc2a643d715670560b7920efdbc948e560 src/core/job_error.cpp 1551959b6a3cf7060736bea361e840f82651a332 src/core/kfileitem.cpp 7364f87257b5d7dfb760b1c6e5b5d04e1d15a19d src/core/kioglobal_p.h PRE-CREATION src/core/kioglobal_p_unix.cpp PRE-CREATION src/core/kioglobal_p_win.cpp PRE-CREATION src/core/slave.cpp 787ffcf3cc97a73fb29c2172ed6b8df19ac016fc src/ioslaves/file/file.h 6477df7cf0d26bf4f581151e1ce8e6c1115a221c src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/file/file_win.cpp b0e433e5438e3c45f2f021bf073cb3cca8f4f923 src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb src/widgets/CMakeLists.txt 61e4db3566bad08baaa2e7e90b862ddfc8b957f7 src/widgets/config-getgrouplist.h.cmake 6847a19d60be4eb5c2b65fb86258f7368848e6ab src/widgets/getgrouplist-fake.c dbe77067371dcedb80cea684fb3cd5f42ed72805 src/widgets/kpropertiesdialog.cpp
Re: kcoreaddons: is src/mimetypes/kde.xml still in use?
Am Donnerstag, 10. April 2014, 00:25:21 schrieb Aurélien Gâteau: On Wed, Apr 9, 2014, at 9:57, Burkhard Lück wrote: Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau: Hi, I am trying to figure out which code is responsible for loading xml_mimetypes.po. This file is produced by scripty when running on kcoreaddons, but I can't find any code actually loading the catalog. Is my git grep fu too weak? No, this is just a intermediate file, not loaded directly, of an only half finished solution to translate MIME type entries, see http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html What do you recommend we do for it then? Rename it to xml_mimetypes5.po or just remove it? Rename or remove does not work, the template xml_mimetypes.pot will be recreated on Scripty's next run via function po_for_file in XmlMessages.sh xml_mimetypes.po[t] is an intermediate file only used by Scripty and the translators. So far we have two files xml_mimetypes.po in the trunk translation branch, which tracks frameworks + kde4 master. But this duplication for translators will disappear soon, the third translation branch for frameworks in trunk/l10n-kf5 is nearly ready to get started. kde.xml (kdelibs) + kde5.xml (frameworks/kcoreaddons) are the files used at build time to update xdg mimetypes translations. But this does not work so far, the mimetype translations from lang/xml_mimetypes.po are not added into kde[5].xml. There is already a distinction (kde.xml + kde5.xml), therefore nothing has to be changed from my pov. Thanks. -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117078: Allow compiling kio on windows
On March 28, 2014, 3:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 27 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line27 Bonus points for contributing a static method to QProcess... Alexander Richardson wrote: Makes sense, will try to contribute that. Can it be added here or is that a problem for contributing it to Qt? You can contribute the same code to both places. What can't be done is someone taking your KDE code and trying to submit it to Qt. But if it's your own, you can relicense it as many times as you want. So make sure it's not too buggy, otherwise if people fix non-trivial bugs in the KDE version, you won't be able to submit the result to Qt :-) On March 28, 2014, 3:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 83 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line83 Why not QFileInfo::isSymLink()? Alexander Richardson wrote: This only works for .lnk files, for real symbolic links it returns false. Guess that needs some more work in Qt. Fixing Qt sounds good :) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/#review54455 --- On April 4, 2014, 7:20 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/ --- (Updated April 4, 2014, 7:20 p.m.) Review request for KDE Frameworks. Repository: kio Description --- A series of commits (can submit separately if necessary): --- Add S_IXUSR, IRUSR, etc. definitions for Windows --- Add KIOPrivate::isProcessAlive() and KIOPrivate::sendTerminateSignal() kill() does not work on Windows, therefore a WIN32 implementation is needed in order to compile slave.cpp --- Add KIOPrivate::changeOwnership() to avoid directly calling chown() Additionally use KUserId/KGroupId instead of uid_t/gid_t. This allows compiling chmodjob.cpp on Windows. KIOPrivate::changeOwnership is a stub on Windows. However, it has always been like that with the kdewin chmod() implementation, so this is not a regression from kdelibs4. --- Add KIOPrivate::createSymlink() to avoid using symlink() directly --- Minor Windows compile fixes --- Use KUser in KPropertiesDialog This means no more need for getpwent(), etc - works on Windows --- Export the KIOPrivate functions --- Fix kio_http build on Windows --- No longer use uid_t/gid_t in kio_file --- Allow compiling kurlcompletion.cpp on windows --- Add a fake QT_LSTAT for Windows This just calls QT_STAT and adds QT_STAT_LNK flag to st_mode if it is a symlink --- Use KUser in kpropertiesdialog.cpp - no more getgrouplist Diffs - autotests/fileundomanagertest.cpp 3f209f89cc0e2ac48d8eaef7ee73ec18abca9a4c autotests/globaltest.cpp 4367e53b44e077c566316081e21f429ac15b74a0 autotests/kdirlistertest.cpp 10a970416b8874f1e136b460d05378f8f3a86810 autotests/kfileitemtest.h dc1808e726cf6af1605cfda520c7df3832225cc1 autotests/kfileitemtest.cpp 38bd87f4e9facd8e52e9e5fbd98b16011c866b5a autotests/kiotesthelper.h eb9f0f3019deb63506c2a173d700b78daa95ae10 src/core/CMakeLists.txt d897e370baedbe06b267934c123acee7a149adff src/core/chmodjob.cpp 271869bc2a643d715670560b7920efdbc948e560 src/core/job_error.cpp 1551959b6a3cf7060736bea361e840f82651a332 src/core/kfileitem.cpp 7364f87257b5d7dfb760b1c6e5b5d04e1d15a19d src/core/kioglobal_p.h PRE-CREATION src/core/kioglobal_p_unix.cpp PRE-CREATION src/core/kioglobal_p_win.cpp PRE-CREATION src/core/slave.cpp 787ffcf3cc97a73fb29c2172ed6b8df19ac016fc src/ioslaves/file/file.h 6477df7cf0d26bf4f581151e1ce8e6c1115a221c src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/file/file_win.cpp b0e433e5438e3c45f2f021bf073cb3cca8f4f923 src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb src/widgets/CMakeLists.txt 61e4db3566bad08baaa2e7e90b862ddfc8b957f7 src/widgets/config-getgrouplist.h.cmake 6847a19d60be4eb5c2b65fb86258f7368848e6ab src/widgets/getgrouplist-fake.c dbe77067371dcedb80cea684fb3cd5f42ed72805 src/widgets/kpropertiesdialog.cpp 8e0a9ba0a806fdb1c9e92de00dfb1c8a1449978c src/widgets/kurlcompletion.cpp 3f309257c187358de0fd66f9d67f09a712fdf7d6 Diff: https://git.reviewboard.kde.org/r/117078/diff/ Testing --- compiles, tests still the same as before (i.e. not passing) Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Re: Review Request 117078: Allow compiling kio on windows
On March 28, 2014, 4:19 p.m., David Faure wrote: src/core/kioglobal_p_win.cpp, line 27 https://git.reviewboard.kde.org/r/117078/diff/2/?file=257281#file257281line27 Bonus points for contributing a static method to QProcess... Alexander Richardson wrote: Makes sense, will try to contribute that. Can it be added here or is that a problem for contributing it to Qt? David Faure wrote: You can contribute the same code to both places. What can't be done is someone taking your KDE code and trying to submit it to Qt. But if it's your own, you can relicense it as many times as you want. So make sure it's not too buggy, otherwise if people fix non-trivial bugs in the KDE version, you won't be able to submit the result to Qt :-) Okay good, I'll add it here first, add some tests and then try to get it into Qt - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/#review54455 --- On April 4, 2014, 9:20 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/ --- (Updated April 4, 2014, 9:20 p.m.) Review request for KDE Frameworks. Repository: kio Description --- A series of commits (can submit separately if necessary): --- Add S_IXUSR, IRUSR, etc. definitions for Windows --- Add KIOPrivate::isProcessAlive() and KIOPrivate::sendTerminateSignal() kill() does not work on Windows, therefore a WIN32 implementation is needed in order to compile slave.cpp --- Add KIOPrivate::changeOwnership() to avoid directly calling chown() Additionally use KUserId/KGroupId instead of uid_t/gid_t. This allows compiling chmodjob.cpp on Windows. KIOPrivate::changeOwnership is a stub on Windows. However, it has always been like that with the kdewin chmod() implementation, so this is not a regression from kdelibs4. --- Add KIOPrivate::createSymlink() to avoid using symlink() directly --- Minor Windows compile fixes --- Use KUser in KPropertiesDialog This means no more need for getpwent(), etc - works on Windows --- Export the KIOPrivate functions --- Fix kio_http build on Windows --- No longer use uid_t/gid_t in kio_file --- Allow compiling kurlcompletion.cpp on windows --- Add a fake QT_LSTAT for Windows This just calls QT_STAT and adds QT_STAT_LNK flag to st_mode if it is a symlink --- Use KUser in kpropertiesdialog.cpp - no more getgrouplist Diffs - autotests/fileundomanagertest.cpp 3f209f89cc0e2ac48d8eaef7ee73ec18abca9a4c autotests/globaltest.cpp 4367e53b44e077c566316081e21f429ac15b74a0 autotests/kdirlistertest.cpp 10a970416b8874f1e136b460d05378f8f3a86810 autotests/kfileitemtest.h dc1808e726cf6af1605cfda520c7df3832225cc1 autotests/kfileitemtest.cpp 38bd87f4e9facd8e52e9e5fbd98b16011c866b5a autotests/kiotesthelper.h eb9f0f3019deb63506c2a173d700b78daa95ae10 src/core/CMakeLists.txt d897e370baedbe06b267934c123acee7a149adff src/core/chmodjob.cpp 271869bc2a643d715670560b7920efdbc948e560 src/core/job_error.cpp 1551959b6a3cf7060736bea361e840f82651a332 src/core/kfileitem.cpp 7364f87257b5d7dfb760b1c6e5b5d04e1d15a19d src/core/kioglobal_p.h PRE-CREATION src/core/kioglobal_p_unix.cpp PRE-CREATION src/core/kioglobal_p_win.cpp PRE-CREATION src/core/slave.cpp 787ffcf3cc97a73fb29c2172ed6b8df19ac016fc src/ioslaves/file/file.h 6477df7cf0d26bf4f581151e1ce8e6c1115a221c src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/file/file_win.cpp b0e433e5438e3c45f2f021bf073cb3cca8f4f923 src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb src/widgets/CMakeLists.txt 61e4db3566bad08baaa2e7e90b862ddfc8b957f7 src/widgets/config-getgrouplist.h.cmake 6847a19d60be4eb5c2b65fb86258f7368848e6ab src/widgets/getgrouplist-fake.c dbe77067371dcedb80cea684fb3cd5f42ed72805 src/widgets/kpropertiesdialog.cpp 8e0a9ba0a806fdb1c9e92de00dfb1c8a1449978c src/widgets/kurlcompletion.cpp 3f309257c187358de0fd66f9d67f09a712fdf7d6 Diff: https://git.reviewboard.kde.org/r/117078/diff/ Testing --- compiles, tests still the same as before (i.e. not passing) Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[kdelibs4support] /: Add a compatibility CMake config file
Git commit 7f707a8c28b92b1ad79b31dc74f0978255eaee9a by Alex Merry.
Committed on 09/04/2014 at 21:55.
Pushed by alexmerry into branch 'master'.
Add a compatibility CMake config file
This allows projects to continue using find_package(KF5KDE4Suport) and
KF5::KDE4Support in CMake files, keeping source compatibility with
beta1.
CCMAIL: kde-frameworks-devel@kde.org
M +31 -0CMakeLists.txt
A +33 -0KF5KDE4SupportConfig.cmake.in
http://commits.kde.org/kde4support/7f707a8c28b92b1ad79b31dc74f0978255eaee9a
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ad26ee4..1cbf68b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -106,6 +106,37 @@ install(FILES
${CMAKE_CURRENT_BINARY_DIR}/kdelibs4support_version.h
DESTINATION ${INCLUDE_INSTALL_DIR}
COMPONENT Devel)
+
+
+#
+# Compatibility file
+#
+set(CMAKECONFIG_COMPAT_INSTALL_DIR
${CMAKECONFIG_INSTALL_PREFIX}/KF5KDE4Support)
+if(BUILD_SHARED_LIBS)
+set(KDELibs4Support_LIB_TYPE SHARED)
+else()
+set(KDELibs4Support_LIB_TYPE STATIC)
+endif()
+ecm_configure_package_config_file(
+${CMAKE_CURRENT_SOURCE_DIR}/KF5KDE4SupportConfig.cmake.in
+${CMAKE_CURRENT_BINARY_DIR}/KF5KDE4SupportConfig.cmake
+INSTALL_DESTINATION ${CMAKECONFIG_COMPAT_INSTALL_DIR}
+)
+write_basic_package_version_file(
+${CMAKE_CURRENT_BINARY_DIR}/KF5KDE4SupportConfigVersion.cmake
+VERSION ${KF5_VERSION}
+COMPATIBILITY AnyNewerVersion
+)
+install(
+FILES
+${CMAKE_CURRENT_BINARY_DIR}/KF5KDE4SupportConfig.cmake
+${CMAKE_CURRENT_BINARY_DIR}/KF5KDE4SupportConfigVersion.cmake
+DESTINATION ${CMAKECONFIG_COMPAT_INSTALL_DIR}
+COMPONENT Devel
+)
+
+
+
add_subdirectory(cmake)
add_subdirectory(docs)
add_subdirectory(src)
diff --git a/KF5KDE4SupportConfig.cmake.in b/KF5KDE4SupportConfig.cmake.in
new file mode 100644
index 000..d4488d5
--- /dev/null
+++ b/KF5KDE4SupportConfig.cmake.in
@@ -0,0 +1,33 @@
+@PACKAGE_INIT@
+
+find_dependency(KF5KDELibs4Support @KF5_VERSION@)
+
+if(NOT TARGET KF5::KDE4Support)
+add_library(KF5::KDE4Support @KDELibs4Support_LIB_TYPE@ IMPORTED)
+
+# Because CMake won't let us alias an imported target, we have to
+# create a new imported target and copy the properties we care about
+set(_copy_props
+INTERFACE_INCLUDE_DIRECTORIES
+INTERFACE_LINK_LIBRARIES
+IMPORTED_CONFIGURATIONS
+)
+get_target_property(_configs KF5::KDELibs4Support IMPORTED_CONFIGURATIONS)
+foreach(_config ${_configs})
+set(_copy_props
+${_copy_props}
+IMPORTED_LINK_DEPENDENT_LIBRARIES_${_config}
+IMPORTED_LOCATION_${_config}
+IMPORTED_SONAME_${_config}
+)
+endforeach()
+foreach(_prop ${_copy_props})
+get_target_property(_temp_prop KF5::KDELibs4Support ${_prop})
+set_target_properties(KF5::KDE4Support PROPERTIES ${_prop}
${_temp_prop})
+endforeach()
+
+message(AUTHOR_WARNING
+ The KF5KDE4Support package is deprecated: use
+ find_package(KF5KDELibs4Support) or
+ find_package(KF5 COMPONENTS KDELibs4Support) instead.)
+endif()
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons: is src/mimetypes/kde.xml still in use?
On Thu, Apr 10, 2014, at 6:36, Burkhard Lück wrote: Am Donnerstag, 10. April 2014, 00:25:21 schrieb Aurélien Gâteau: On Wed, Apr 9, 2014, at 9:57, Burkhard Lück wrote: Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau: Hi, I am trying to figure out which code is responsible for loading xml_mimetypes.po. This file is produced by scripty when running on kcoreaddons, but I can't find any code actually loading the catalog. Is my git grep fu too weak? No, this is just a intermediate file, not loaded directly, of an only half finished solution to translate MIME type entries, see http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html What do you recommend we do for it then? Rename it to xml_mimetypes5.po or just remove it? Rename or remove does not work, the template xml_mimetypes.pot will be recreated on Scripty's next run via function po_for_file in XmlMessages.sh Actually I meant either remove XmlMessages.sh (since this translation is not used) or change the catalog name in XmlMessages.sh. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons: is src/mimetypes/kde.xml still in use?
Am Donnerstag, 10. April 2014, 08:28:51 schrieb Aurélien Gâteau: On Thu, Apr 10, 2014, at 6:36, Burkhard Lück wrote: Am Donnerstag, 10. April 2014, 00:25:21 schrieb Aurélien Gâteau: On Wed, Apr 9, 2014, at 9:57, Burkhard Lück wrote: Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau: Hi, I am trying to figure out which code is responsible for loading xml_mimetypes.po. This file is produced by scripty when running on kcoreaddons, but I can't find any code actually loading the catalog. Is my git grep fu too weak? No, this is just a intermediate file, not loaded directly, of an only half finished solution to translate MIME type entries, see http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html What do you recommend we do for it then? Rename it to xml_mimetypes5.po or just remove it? Rename or remove does not work, the template xml_mimetypes.pot will be recreated on Scripty's next run via function po_for_file in XmlMessages.sh Actually I meant either remove XmlMessages.sh (since this translation is not used) or change the catalog name in XmlMessages.sh. Please do not remove XmlMessages.sh, it is used to extract the messages properly and I am working on a solution to add the translated entries back into kde[5].xml similar as with our .desktop files. Feel free to change catalog name in function po_for_file in XmlMessages.sh to xml_mimetypes5.po. -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
How do we want to ship framework translations
Hi, Until now, kdelibs translations have always been released as part of the kde-l10n-$lang tarballs. I was wondering whether it should still be the case with frameworks, or if each frameworks should instead ship with its own translations. The work I have been been doing assumed the later because I did not realize kdelibs tarball does not ship its own translations. I already have the changes to go back to separate tarballs for translations, but would like to confirm this is the way we want to go before applying the changes. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117485: Add note about Kiosk to docs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117485/ --- Review request for KDE Frameworks. Repository: kbookmarks Description --- Add note about Kiosk to docs Related: https://git.reviewboard.kde.org/r/117486/ https://git.reviewboard.kde.org/r/117487/ https://git.reviewboard.kde.org/r/117488/ Diffs - src/kbookmarkmenu.h 017fc96193c04e85e06c161b6becda2bf659d8bf Diff: https://git.reviewboard.kde.org/r/117485/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 117488: Improve Kiosk documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117488/ --- Review request for KDE Frameworks. Repository: kio Description --- Improve Kiosk documentation Based on the README.kiosk file that was in KConfig. Related: https://git.reviewboard.kde.org/r/117485/ https://git.reviewboard.kde.org/r/117486/ https://git.reviewboard.kde.org/r/117487/ Diffs - src/core/kurlauthorized.h 10048fc97eef6334d779946d023651e440b48962 src/widgets/kfileitemactions.h 1c2410fcdc9160c468e2644d5f998968520fc7eb src/widgets/kopenwithdialog.h 9ff214cfabce28784a188ced8d70abffa139f631 src/widgets/kpropertiesdialog.h 53018e6bff296b99652910e9c0e28b1b7297db61 src/widgets/krun.h 3ded003297ef1ff2c78945b956417ed4f5628ae3 Diff: https://git.reviewboard.kde.org/r/117488/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 117487: Add Kiosk documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117487/ --- Review request for KDE Frameworks. Repository: kxmlgui Description --- Add Kiosk documentation This is partly drawn from the old README.kiosk documentation that was in the KConfig framework, but is mostly determined by looking at the source code. Related: https://git.reviewboard.kde.org/r/117485/ https://git.reviewboard.kde.org/r/117486/ https://git.reviewboard.kde.org/r/117488/ Diffs - README.md 41c3b8bdfd0c01d980cb86ac4dd67116e69b692c src/kactioncollection.h 5a2cae0787d1f4d8673b213a97cc36c90ab211e3 src/khelpmenu.h f03149ac4fc1d4c0e17f100d413d83f46074de60 src/ktoolbar.h df6132ad349750473afd5544cfb4b66debab4927 Diff: https://git.reviewboard.kde.org/r/117487/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 117486: Rewrite kiosk documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117486/ --- Review request for KDE Frameworks. Repository: kconfig Description --- Rewrite kiosk documentation A lot of kiosk stuff is actually in other frameworks, from the point of view of applications, but KConfig provides the core functionality. Make the docs here describe KConfig's role, rather than KIO's or KXMLGui's. Related: https://git.reviewboard.kde.org/r/117485/ https://git.reviewboard.kde.org/r/117487/ https://git.reviewboard.kde.org/r/117488/ Diffs - README.md 87cb2a0590700f08d9abcc931fe2860ba308497b docs/README.kiosk b89f731c3c20d09bfe8e26fd45964c5d0fc47e19 docs/options.md PRE-CREATION src/core/kauthorized.h 45dd828448be24cf3108a7ef042ca07e4e98d74a src/core/kauthorized.cpp c9b14f5033a9e4aa117b3fd5ba298d85eee65062 Diff: https://git.reviewboard.kde.org/r/117486/diff/ Testing --- Generated and visually inspected apidox. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How do we want to ship framework translations
On 10/04/14 17:06, Aurélien Gâteau wrote: Hi, Until now, kdelibs translations have always been released as part of the kde-l10n-$lang tarballs. I was wondering whether it should still be the case with frameworks, or if each frameworks should instead ship with its own translations. The work I have been been doing assumed the later because I did not realize kdelibs tarball does not ship its own translations. I already have the changes to go back to separate tarballs for translations, but would like to confirm this is the way we want to go before applying the changes. I thought the consensus was to change it so that they were distributed on a framework-by-framework basis. Certainly that's what makes most sense to me. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117489: Remove the old tutorial
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117489/ --- Review request for KDE Frameworks. Repository: knewstuff Description --- Remove the old tutorial The contents are for the previous version of the library, and no longer relevant (eg: the API it suggests you use no longer exists as public API). Diffs - docs/tutorial.txt 084bc478bb02d6739a418ac2d5b262f7f226b0fe Diff: https://git.reviewboard.kde.org/r/117489/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Thursday 10 April 2014 13:43:37 Marco Martin wrote: On Thursday 10 April 2014, Àlex Fiestas wrote: Developers being confortable with it, or even (gasp!) being actively maintained goes completely secondary behind the causing as less regressions as possible for the users. I guess you can leave the code there and just not add it to cmake, then we no, even that is the same problem (i did not explain enough), ie there are two cases: * it's not built and ported yet, likely noone will miss it * it's not built and ported yet, causes regressions in the first case, it can either be just killed or is fine the micro repo if someone steps up for maintainership in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. Thing is, in KDE4 it is broken, the model is all fucked up, some times it mounts the incorrect things or things that are already mounted (causing annoying dialogs) etc. So like I said in the sprint is it is something nice to have but it has to be maintained, fixed and polished and that won't happen before 2.0 and there is no reason to believe it will ever happen (since nobody at the sprint even knew what it was). 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: Kioslave repos
On Thursday 10 April 2014 14:42:37 Marco Martin wrote: On Thursday 10 April 2014, you wrote: in the second case, it's just a release blocker, and has to be enabled and ported, *even if* there won't be anyone maintaining it after that, it's a part of the workspace and needs to be released, (and yes, preferably in the plasma- workspace repo) if it's not yet, there will be no release until is ported and built. one concrete thing that may be done is to do a (yet another) sweep of the things that are from workspace/runtime and being move around, like was done in the sprint, but do it in this mailinglist with more people interested involved. so, the central thing this time will be is it necessary or will it cause significant regressions In this way we can make sure no stuff that has still valid use case (yes, even if all of the people working in the framework hate such component, that's irrelevant :p) is left unported (like a good example is the automounter, i would never use such a thing ever, never the less that's irrelevant and is an important component of a base workspace for too many users, no matter how buggy or unmaintained is) Even though going offtopic I will use this thread to say my mind since it seems that your PoV diverges from mine. The problem is manpower, we do not have the manpwoer to maintain half o the things we have in the workspace, most of the things in there are half-cooked or they do not even work (kglobalaccel kcm) and instead of taking a breath and decide what we want and what we do not want (like we did in the sprint) we are just blindly moving forward and making things compile that no developers care about. This has to stop. This must stop. This mess, this lack of quality is what makes KDE4 unpolished even after 6 years of development, we have plenty of features more than we can handle and we need to puts things in order. This video shows a bit of the things I feel: http://www.youtube.com/watch?v=CqY9l9qiFoA And this feeling is a constant while using kde4, some kde4 apps etc. 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: kdeinit5 binary and man page in different repos
On 09/04/14 19:08, Michael Palimaka wrote: Hi, I noticed that kdeinit5 is in kinit, and its man page appears to be in kservice. I guess the man page should be moved, but I'm not sure of the best procedure with regards to preserving history etc. I've done this now. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KDE4 references task status
Update on the KDE4 references task[0]: This is mostly done. There are some review requests still open, some things for translators to do in kdoctools, a couple of things I've asked David to look at and src/kwrapper/kwrapper_win.cpp in kinit, which needs a Windows person to look at it. Basically, I've reached the point where I'm waiting on other people. Reviews on the RRs would be appreciated :-) Alex [0]: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/KDE4_References ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117491: Rework FindX11_XCB.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Repository: extra-cmake-modules Description --- Rework FindX11_XCB.cmake Imported target, version handling, package description etc. Diffs - find-modules/FindX11_XCB.cmake e2c18a99873dc6db572c9761e5b15bddc3505fea Diff: https://git.reviewboard.kde.org/r/117491/diff/ Testing --- Configured and build KWindowSystem successfully. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117490: Improve FindEGL.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117490/ --- Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Repository: extra-cmake-modules Description --- Improve FindEGL.cmake - Add version handling - Improve the docs - mark cache variables as advanced - make the pkg-config call actually work Diffs - find-modules/FindEGL.cmake 6237f5cb42268993ba56f4a4ae29d8864c220b95 Diff: https://git.reviewboard.kde.org/r/117490/diff/ Testing --- Configured and built KWin successfully. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How do we want to ship framework translations
Am Donnerstag, 10. April 2014, 09:06:40 schrieb Aurélien Gâteau: Hi, Until now, kdelibs translations have always been released as part of the kde-l10n-$lang tarballs. I was wondering whether it should still be the case with frameworks, or if each frameworks should instead ship with its own translations. The work I have been been doing assumed the later because I did not realize kdelibs tarball does not ship its own translations. To be sure, your question is only about the translation catalog in frameworks repos, not in anythings else like workspace, kate, konsole etc? What about the translated docbooks for the frameworks repos? How / who imports the translations (GUI/Docs) into frameworks repos? Keep in mind that many teams do not have a source code checkout of frameworks repos, so the translations would have to be pulled in via anonsvn at build time, but anonsvn is not always available. In case lang docbooks are pulled into frameworks repos there has to be a check if docbooks are valid and compile or a frameworks repo will be broken. I already have the changes to go back to separate tarballs for translations, but would like to confirm this is the way we want to go before applying the changes. For my daily work (proofreading translations of de, check i18n errors from devels via x-test, check translation bugs reported on b.k.o) I build + install the complete translations (gui + docs) of several languages each day via l10n- kde4/scripts/autogen.sh, so need that for frameworks as well. -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
workspace/khelpcenter which branch is frameworks, branch master or frameworks?
Hi, I am really confused about the branches which are really frameworks. E.g workspace/khelpcenter has branches master and frameworks. But Aleix imported the khelpcenter docbooks to branch 'master', not into branch 'frameworks'. So what is the correct branch for the frameworks in workspace/khelpcenter, master or frameworks? Btw the docu in workspace/khelpcenter/doc need to be moved to workspace/khelpcenter/doc/khelpcenter, because fundamentals, onlinehelp and glossary docus should be added in workspace/khelpcenter/doc as well? Where do I find a list of branches for each workspace module which are in fact frameworks? -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How do we want to ship framework translations
[: Burkhard Lück :] For my daily work (proofreading translations of de, check i18n errors from devels via x-test, check translation bugs reported on b.k.o) I build + install the complete translations (gui + docs) of several languages each day via l10n- kde4/scripts/autogen.sh, so need that for frameworks as well. How does this work out for you with extragear and playground programs? Same as with KDE SC stuff, or there are some differences? -- Chusslove Illich (Часлав Илић) 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: How do we want to ship framework translations
El Dijous, 10 d'abril de 2014, a les 21:10:36, Burkhard Lück va escriure: Am Donnerstag, 10. April 2014, 09:06:40 schrieb Aurélien Gâteau: Hi, Until now, kdelibs translations have always been released as part of the kde-l10n-$lang tarballs. I was wondering whether it should still be the case with frameworks, or if each frameworks should instead ship with its own translations. The work I have been been doing assumed the later because I did not realize kdelibs tarball does not ship its own translations. To be sure, your question is only about the translation catalog in frameworks repos, not in anythings else like workspace, kate, konsole etc? What about the translated docbooks for the frameworks repos? How / who imports the translations (GUI/Docs) into frameworks repos? Noone, it just works like now. Cheers, Albert Keep in mind that many teams do not have a source code checkout of frameworks repos, so the translations would have to be pulled in via anonsvn at build time, but anonsvn is not always available. In case lang docbooks are pulled into frameworks repos there has to be a check if docbooks are valid and compile or a frameworks repo will be broken. I already have the changes to go back to separate tarballs for translations, but would like to confirm this is the way we want to go before applying the changes. For my daily work (proofreading translations of de, check i18n errors from devels via x-test, check translation bugs reported on b.k.o) I build + install the complete translations (gui + docs) of several languages each day via l10n- kde4/scripts/autogen.sh, so need that for frameworks as well. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How do we want to ship framework translations
El Dijous, 10 d'abril de 2014, a les 09:06:40, Aurélien Gâteau va escriure: Hi, Until now, kdelibs translations have always been released as part of the kde-l10n-$lang tarballs. I was wondering whether it should still be the case with frameworks, or if each frameworks should instead ship with its own translations. The work I have been been doing assumed the later because I did not realize kdelibs tarball does not ship its own translations. Every framework ships the needed l10n inside its tarball. Cheers, Albert I already have the changes to go back to separate tarballs for translations, but would like to confirm this is the way we want to go before applying the changes. Aurélien ___ 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
Re: How do we want to ship framework translations
El Dijous, 10 d'abril de 2014, a les 20:57:20, Alexander Potashev va escriure: 2014-04-10 20:31 GMT+04:00 Alex Merry alex.me...@kde.org: I thought the consensus was to change it so that they were distributed on a framework-by-framework basis. Hello Alex, The words framework-by-framework basis may be understood in three different ways: 1. Translations to all languages are shipped in a single tarball together with the framework's source code, e.g. ktexteditor-5.0.0.tar.xz. This one. Cheers, Albert 2. Translations to all languages are shipped in a single tarball, separately from the source code, e.g. ktexteditor-l10n-5.0.0.tar.xz. 3. Translations to each language are shipped in separate tarballs, (also separately from the source code), e.g. ktexteditor-l10n-fr-5.0.0.tar.xz. However, this would lead to tens thousand of tarballs. Could you please tell which of these three options you meant? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Postfixing .po that come from Qt::tr() with a _qt.po
Hi, do you think it makes sense to use that postfix? We are using this currently for stuff like marble and trojita so our translators know they can't use advanced stuff like JS scripting for the translations. What do you think? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Postfixing .po that come from Qt::tr() with a _qt.po
[: Albert Astals Cid :] Hi, do you think it makes sense to use that postfix? We are using this currently for stuff like marble and trojita so our translators know they can't use advanced stuff like JS scripting for the translations. For this particular reason, the better solution is to make sure all PO messages from i18n() calls get the kde-format flag. This is in fact how it should have been all along, since consistency of argument placeholders is always checked for at runtime. E.g. if the source text has no placeholders but translation contains %1 (can be unfuzzying error), without the format flat nothing will signal this error. However, since tr() messages don't enforce placeholder consistency (no placeholder in source means also no .arg(), so stray placecholder in translation is not syntax error), they cannot get qt-format flag unconditionally. So positive identification (this is Qt message as opposed to this is not KI18n message) is not possible by format flag alone. And positive identification is sometimes useful, e.g. for applying Qt markup checks. From this standpoint, it would be nice to add the postfix. In summary, I'd go for the postfix. If there were an enormous amount of tr() -derived PO files, I'd think harder, but given they are expected in low-tier frameworks and few elsewhere, not. -- Chusslove Illich (Часлав Илић) 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 117132: Use QLocale for figuring out what languages we're translated into
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/#review55418 --- Ship it! Ship It! - Chusslove Illich On April 9, 2014, 6 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/ --- (Updated April 9, 2014, 6 p.m.) Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich. Repository: kxmlgui Description --- Instead of asking the file-system what languages the application is translated into, ask QLocale what languages we have available instead. Diffs - src/khelpmenu.cpp 4f6ce7b Diff: https://git.reviewboard.kde.org/r/117132/diff/ Testing --- 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 117132: Use QLocale for figuring out what languages we're translated into
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/ --- (Updated April 10, 2014, 10:36 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich. Repository: kxmlgui Description --- Instead of asking the file-system what languages the application is translated into, ask QLocale what languages we have available instead. Diffs - src/khelpmenu.cpp 4f6ce7b Diff: https://git.reviewboard.kde.org/r/117132/diff/ Testing --- 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 117132: Use QLocale for figuring out what languages we're translated into
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/#review55419 --- This review has been submitted with commit 44cbe33fb8c9bf3ebf25e6b6eeedbf4668cea688 by Aleix Pol to branch master. - Commit Hook On April 9, 2014, 4 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117132/ --- (Updated April 9, 2014, 4 p.m.) Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich. Repository: kxmlgui Description --- Instead of asking the file-system what languages the application is translated into, ask QLocale what languages we have available instead. Diffs - src/khelpmenu.cpp 4f6ce7b Diff: https://git.reviewboard.kde.org/r/117132/diff/ Testing --- 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 117486: Rewrite kiosk documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117486/#review55422 --- Ship it! Ship It! - Matthew Dawson On April 10, 2014, 12:29 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117486/ --- (Updated April 10, 2014, 12:29 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- Rewrite kiosk documentation A lot of kiosk stuff is actually in other frameworks, from the point of view of applications, but KConfig provides the core functionality. Make the docs here describe KConfig's role, rather than KIO's or KXMLGui's. Related: https://git.reviewboard.kde.org/r/117485/ https://git.reviewboard.kde.org/r/117487/ https://git.reviewboard.kde.org/r/117488/ Diffs - README.md 87cb2a0590700f08d9abcc931fe2860ba308497b docs/README.kiosk b89f731c3c20d09bfe8e26fd45964c5d0fc47e19 docs/options.md PRE-CREATION src/core/kauthorized.h 45dd828448be24cf3108a7ef042ca07e4e98d74a src/core/kauthorized.cpp c9b14f5033a9e4aa117b3fd5ba298d85eee65062 Diff: https://git.reviewboard.kde.org/r/117486/diff/ Testing --- Generated and visually inspected apidox. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: workspace/khelpcenter which branch is frameworks, branch master or frameworks?
On Fri, April 11, 2014 00:33:07 Aleix Pol wrote: You can see the used branches in this file, between brackets (see Qt5): http://quickgit.kde.org/?p=kde-build-metadata.git snip Well, that gives the dependencies but not always the branches. To see which branch is considered the frameworks branch for a git module you'd want to look at the file logical-module-structure in the same kde-build- metadata git repository (git clone kde:kde-build-metadata). Due to wildcard dependencies and sheer size, what you probably *really* want to do is to use the script list_preferred_repo_branch in the tools/ subdirectory of the same module. E.g. (run from the tools/ directory): tools $ ./list_preferred_repo_branch kf5-qt5 frameworks/kconfig output is: master In this case kf5-qt5 is the branch group used for our KF5 modules. You can use latest-qt4 for development KDE4, or stable-qt4 for release KDE4 branches. The git repository name must be the full virtual project path as well (converting module names to paths is doable for motivated hackers who want to improve the script, but you'd need the kde_projects.xml as well). If you have a lot of repositories to check you can pass them as additional parameters (you might want to add -p as well to print out the module name as part of the output). Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117491: Rework FindX11_XCB.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/#review55425 --- I'm wondering whether it's still needed in kwindowsystem at all. So the test might not be telling much. - Martin Gräßlin On April 10, 2014, 8:40 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- (Updated April 10, 2014, 8:40 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Repository: extra-cmake-modules Description --- Rework FindX11_XCB.cmake Imported target, version handling, package description etc. Diffs - find-modules/FindX11_XCB.cmake e2c18a99873dc6db572c9761e5b15bddc3505fea Diff: https://git.reviewboard.kde.org/r/117491/diff/ Testing --- Configured and build KWindowSystem successfully. 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 117490: Improve FindEGL.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117490/#review55426 --- oh do I get this right? I can now do a find for EGL version 1.4 and it's not the MESA version? That's just awesome. Will try to build KWin with that change and verify that it works as expected. - Martin Gräßlin On April 10, 2014, 8:40 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117490/ --- (Updated April 10, 2014, 8:40 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Repository: extra-cmake-modules Description --- Improve FindEGL.cmake - Add version handling - Improve the docs - mark cache variables as advanced - make the pkg-config call actually work Diffs - find-modules/FindEGL.cmake 6237f5cb42268993ba56f4a4ae29d8864c220b95 Diff: https://git.reviewboard.kde.org/r/117490/diff/ Testing --- Configured and built KWin successfully. 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 117491: Rework FindX11_XCB.cmake
On April 11, 2014, 7:32 a.m., Martin Gräßlin wrote: I'm wondering whether it's still needed in kwindowsystem at all. So the test might not be telling much. my task to remove the dependency from kwindowsystem failed: it's already no longer used. I'm just wondering where we have code which still uses this X11_XCB, it might be possible to delete it. It's in fact only needed for Qt4 as with Qt5 one gets the xcb_connection_t* through QX11Info. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/#review55425 --- On April 10, 2014, 8:40 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- (Updated April 10, 2014, 8:40 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Repository: extra-cmake-modules Description --- Rework FindX11_XCB.cmake Imported target, version handling, package description etc. Diffs - find-modules/FindX11_XCB.cmake e2c18a99873dc6db572c9761e5b15bddc3505fea Diff: https://git.reviewboard.kde.org/r/117491/diff/ Testing --- Configured and build KWindowSystem successfully. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117495: Fix doc of KWindowInfo::clientMachine()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117495/ --- Review request for KDE Frameworks. Repository: kwindowsystem Description --- Fix doc of KWindowInfo::clientMachine() It belongs to properties2. Diffs - src/kwindowinfo.h 579ba6d61a4453c717c5b3d492c138592a9e0610 Diff: https://git.reviewboard.kde.org/r/117495/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
