Re: How do we want to ship framework translations
Am Donnerstag, 10. April 2014, 22:58:29 schrieb Chusslove Illich: [: 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? In stable (KDE SC +extragear) modules/apps usually have to be build only once (exept in case of i18n fixes) to be able to check/test/proofread all translations. In master this is of course slightly different, for new translations the apps need to be rebuild. But even in SC master, extragear + playground the i18n related code does not change so often except for new apps like kst or labplot coming into kde. For my use cases and especially playing with an app GUI while translating the documentation I do not need the latest build. Rebuilding once a week or even less often is usually sufficient, except in cases hunting down / trying to fix i18n issues. -- Burkhard Lück ___ 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 8:43, Burkhard Lück wrote: 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. OK. Just did this. If I am not mistaken there should not be any conflicting catalog files left. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
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. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. Aurélien ___ 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
On Thu, Apr 10, 2014, at 14:17, Albert Astals Cid wrote: 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? Works for me. This suffix would remove the need to check for the X-Qt-Contexts: true flag, right? Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: 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. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? 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 Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote: On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: 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. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? We used to have an unmaintained svn dir, but it seems we don't have a git equivalent :/ Aurélien ___ 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/ --- (Updated April 11, 2014, 9:27 a.m.) Status -- This change has been marked as submitted. 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: Review Request 117486: Rewrite kiosk documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117486/#review55434 --- This review has been submitted with commit bc157c1bb768c5b8c7a72c8f6ef29ba313c465b0 by Alex Merry to branch master. - Commit Hook On April 10, 2014, 4: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, 4: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: 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/#review55435 --- Ship it! Ship It! - Kevin Ottens On April 10, 2014, 12:08 p.m., Àlex Fiestas wrote: --- 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. 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
Re: Kioslave repos
Am Freitag, 11. April 2014, 02:21:22 schrieb Aurélien Gâteau: On Fri, Apr 11, 2014, at 1:51, Àlex Fiestas wrote: On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: 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. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. I'm all for dead code cemetery, but where is it? We used to have an unmaintained svn dir, but it seems we don't have a git equivalent :/ Of course we have that: https://projects.kde.org/projects/unmaintained -- 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
On Thu, Apr 10, 2014, at 14:12, Albert Astals Cid wrote: 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. OK, but we still want to support installing all translations for your language via l10n-kf5, right? In this case I propose the following set up: - The tarball creation script must create a po/ directory, which contains catalogname-lang.po files (similar to what the releaseme script does) - l10n-kf5 remain the same: lang/messages/frameworks/catalog.po - The CMake code in the root directory of a framework repository checks if the po/ directory is there. If po/ exists, it builds the .po files (either as .mo or .qm) and installs them in install-prefix/share/locale/langLC_MESSAGES - The CMake code generated by l10n-kf5/scripts/autogen.sh does the same as the CMake code in the root directory of framework repositories, except it works on catalogs grouped by languages instead of grouped by frameworks. I am confident I can modify the current .qm handling code in ECM to provide support for the two use-cases, and then do the same for i18n-based frameworks. Is this OK for everybody? Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117125: start_kdeinit: Use capabilities instead of SUID
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/#review55438 --- Ship it! Ship It! - David Faure On April 7, 2014, 7:05 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/ --- (Updated April 7, 2014, 7:05 p.m.) Review request for KDE Frameworks and David Faure. Bugs: https://bugzilla.novell.com/show_bug.cgi?id=862953 https://bugs.kde.org/show_bug.cgi?id=https://bugzilla.novell.com/show_bug.cgi?id=862953 Repository: kinit Description --- The issue came up on security review of kinit package (yes, same is valid for kdelibs4...) SUSE security team is not happy with kdeinit being SUID helper, thus capabilities are utilized first (if available) I've just tried to integrate the suggested patch (from the report) with the CMake bits Diffs - CMakeLists.txt 8bd43d8 cmake/FindLibcap.cmake PRE-CREATION src/config-kdeinit.h.cmake c89c713 src/start_kdeinit/CMakeLists.txt 6bfc496 src/start_kdeinit/start_kdeinit.c 3c733e7 Diff: https://git.reviewboard.kde.org/r/117125/diff/ Testing --- Built: with setcap libcap present - installed as advertised; without one/both of them - the old procedure is in place (using SUID for the helper) I am not sure how to test the OOM killer, fortunately it never kicked in kdelibs4 variant, so can't also say did it work as planned before... Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Kioslave repos
Hello, On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote: 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) For the record, it works in 4 that particular one, I use it... 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. I agree with your analysis of the problem but not with your solution. If it's broken, should not be shipped and is unmaintained then be bold and either delete it or move it to our dead code cemetery. ... and that's why I disagree with both the analysis and the solution. Because it seems the analysis is very weak in the first place. The fact that from one mail to the next we shift in different exhibited examples avoiding general rules is telling IMO. I'm concerned there's no criteria set but feelings (I don't want to maintain it because of its ugly face)[*]. That's the best way to create problems like our previous major workspace release. And I agree with what was previously said of not rubbing stuff under the carpet. I'm not saying nothing should be moved to the dead code area of course. It is justified to move code in such an area if it's broken *and* not causing important user regressions on removal. If it's just broken it should be repaired and eventually obsoleted responsibly later on. Regards. PS: Of course I could be totally wrong and there's been a strong analysis where general rules got set and you're in fact following that. Then it's just that I see no real evidence of it (which could be worsened by the way we structured our wikis). PPS: And obviously, even if I'm right, the product can turn out OK in the end by chance. That would still be taking a huge risk with one of the main community assets though, I'm all for reducing this kind of risks. [*] I admit we had it easier in kdelibs as lxr could help reduce the part of feelings and check our criteria... and even there we stumbled and screwed up a few times. -- 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: Kioslave repos
On Thursday 10 April 2014 19:52:34 Àlex Fiestas wrote: 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). A problem i'm seeing now in this thread, is that in january at the sprint not everybody was present. and the parts of the workspace, especially those dreaded (uhm, hystoric?;) ones are of interest really of everybody. So is reasonable some of the things decided there come as a surprise, or that many potential maintainers just completely missed thins. in an ideal world(tm) would probably had to be done in a breakout session at akademy, as in the only configuration most of the people that should be there are there. But since that wasn't possible, I'm proposing the following: On frameworks tuesdays (just to piggyback a day many people already have reserved to be on irc, another day may be planned if needed) we again go over the pieces, one by one, like we did at the sprint, and again search for maintainers for things that don't have yet. More important thing would be doing a priority list for things that really must be there and is vital they cannot regress and having those assigned to somebody first (obvious example, global shortcut editor) This of course makes sense if enough people are interested doing it. maybe i'm talking shit, i don't know ;) does it make sense? would somebody be interested in this adopt-a-pet thing? -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117125: start_kdeinit: Use capabilities instead of SUID
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/ --- (Updated April 11, 2014, 4:46 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Bugs: https://bugzilla.novell.com/show_bug.cgi?id=862953 https://bugs.kde.org/show_bug.cgi?id=https://bugzilla.novell.com/show_bug.cgi?id=862953 Repository: kinit Description --- The issue came up on security review of kinit package (yes, same is valid for kdelibs4...) SUSE security team is not happy with kdeinit being SUID helper, thus capabilities are utilized first (if available) I've just tried to integrate the suggested patch (from the report) with the CMake bits Diffs - CMakeLists.txt 8bd43d8 cmake/FindLibcap.cmake PRE-CREATION src/config-kdeinit.h.cmake c89c713 src/start_kdeinit/CMakeLists.txt 6bfc496 src/start_kdeinit/start_kdeinit.c 3c733e7 Diff: https://git.reviewboard.kde.org/r/117125/diff/ Testing --- Built: with setcap libcap present - installed as advertised; without one/both of them - the old procedure is in place (using SUID for the helper) I am not sure how to test the OOM killer, fortunately it never kicked in kdelibs4 variant, so can't also say did it work as planned before... Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117125: start_kdeinit: Use capabilities instead of SUID
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/#review55468 --- This review has been submitted with commit e898d13b430692e775060d49342181192e122fdf by Hrvoje Senjan to branch master. - Commit Hook On April 7, 2014, 7:05 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/ --- (Updated April 7, 2014, 7:05 p.m.) Review request for KDE Frameworks and David Faure. Bugs: https://bugzilla.novell.com/show_bug.cgi?id=862953 https://bugs.kde.org/show_bug.cgi?id=https://bugzilla.novell.com/show_bug.cgi?id=862953 Repository: kinit Description --- The issue came up on security review of kinit package (yes, same is valid for kdelibs4...) SUSE security team is not happy with kdeinit being SUID helper, thus capabilities are utilized first (if available) I've just tried to integrate the suggested patch (from the report) with the CMake bits Diffs - CMakeLists.txt 8bd43d8 cmake/FindLibcap.cmake PRE-CREATION src/config-kdeinit.h.cmake c89c713 src/start_kdeinit/CMakeLists.txt 6bfc496 src/start_kdeinit/start_kdeinit.c 3c733e7 Diff: https://git.reviewboard.kde.org/r/117125/diff/ Testing --- Built: with setcap libcap present - installed as advertised; without one/both of them - the old procedure is in place (using SUID for the helper) I am not sure how to test the OOM killer, fortunately it never kicked in kdelibs4 variant, so can't also say did it work as planned before... Thanks, Hrvoje Senjan ___ 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
On April 11, 2014, 5:37 a.m., Martin Gräßlin wrote: 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. Yep, that's the idea :-) - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117490/#review55426 --- On April 10, 2014, 6: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, 6: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 117125: start_kdeinit: Use capabilities instead of SUID
On April 11, 2014, 4:46 p.m., Commit Hook wrote: This review has been submitted with commit e898d13b430692e775060d49342181192e122fdf by Hrvoje Senjan to branch master. i've reverted the commit now. capabilities break LD_LIBRARY_PATH, so this is a no-go. apologies for potentially caused troubles =( - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/#review55468 --- On April 11, 2014, 4:46 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117125/ --- (Updated April 11, 2014, 4:46 p.m.) Review request for KDE Frameworks and David Faure. Bugs: https://bugzilla.novell.com/show_bug.cgi?id=862953 https://bugs.kde.org/show_bug.cgi?id=https://bugzilla.novell.com/show_bug.cgi?id=862953 Repository: kinit Description --- The issue came up on security review of kinit package (yes, same is valid for kdelibs4...) SUSE security team is not happy with kdeinit being SUID helper, thus capabilities are utilized first (if available) I've just tried to integrate the suggested patch (from the report) with the CMake bits Diffs - CMakeLists.txt 8bd43d8 cmake/FindLibcap.cmake PRE-CREATION src/config-kdeinit.h.cmake c89c713 src/start_kdeinit/CMakeLists.txt 6bfc496 src/start_kdeinit/start_kdeinit.c 3c733e7 Diff: https://git.reviewboard.kde.org/r/117125/diff/ Testing --- Built: with setcap libcap present - installed as advertised; without one/both of them - the old procedure is in place (using SUID for the helper) I am not sure how to test the OOM killer, fortunately it never kicked in kdelibs4 variant, so can't also say did it work as planned before... Thanks, Hrvoje Senjan ___ 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/ --- (Updated April 11, 2014, 8:21 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Changes --- Update to new documentation format. 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 (updated) - find-modules/FindEGL.cmake 765b6692a23486afa36c9c92adad7cb294756a30 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
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- (Updated April 11, 2014, 8:28 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Changes --- Update to new documentation format. Repository: extra-cmake-modules Description --- Rework FindX11_XCB.cmake Imported target, version handling, package description etc. Diffs (updated) - find-modules/FindX11_XCB.cmake 687a4f3d57f67aa2e35a8bcfe201e0324e84204e 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 117491: Rework FindX11_XCB.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- (Updated April 11, 2014, 8:32 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, and Martin Gräßlin. Changes --- KIdleTime is the only thing that uses this. Repository: extra-cmake-modules Description --- Rework FindX11_XCB.cmake Imported target, version handling, package description etc. Diffs - find-modules/FindX11_XCB.cmake 687a4f3d57f67aa2e35a8bcfe201e0324e84204e Diff: https://git.reviewboard.kde.org/r/117491/diff/ Testing (updated) --- Configured and build KIdleTime 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, 5: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. Martin Gräßlin wrote: 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. KIdleTime still uses it. LXR suggests it's the only user. I'd be for removing it if the beta version hadn't already been released. While not technically part of frameworks, I think ECM should still stick with the SC after beta thing. In this case, I'm not too bothered about leaving it in. It provides a sort of completeness with FindXCB and CMake's FindX11. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/#review55425 --- On April 11, 2014, 8:32 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117491/ --- (Updated April 11, 2014, 8:32 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 687a4f3d57f67aa2e35a8bcfe201e0324e84204e Diff: https://git.reviewboard.kde.org/r/117491/diff/ Testing --- Configured and build KIdleTime 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 117454: Implement KUser::faceIconPath for Windows XP
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117454/ --- (Updated April 12, 2014, 1:47 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- The undocuented API we're using has a different ordinal and parameters on Windows XP vs Vista/7. I refactored the code to use a template and structs encapsulating the differences, as otherwise the code became too redundant. Feedback welcome on identifier names, that's a known hard problem :) Diffs - src/lib/util/kuser_win.cpp aa48c04 Diff: https://git.reviewboard.kde.org/r/117454/diff/ Testing --- Ran faceicontest on Windows 7 and on XP. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117454: Implement KUser::faceIconPath for Windows XP
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117454/#review55482 --- This review has been submitted with commit d9c0408dd0acf9dc7da43fed8cb81c4f9d397fbd by Nicolás Alvarez to branch master. - Commit Hook On April 9, 2014, 5:06 p.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117454/ --- (Updated April 9, 2014, 5:06 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- The undocuented API we're using has a different ordinal and parameters on Windows XP vs Vista/7. I refactored the code to use a template and structs encapsulating the differences, as otherwise the code became too redundant. Feedback welcome on identifier names, that's a known hard problem :) Diffs - src/lib/util/kuser_win.cpp aa48c04 Diff: https://git.reviewboard.kde.org/r/117454/diff/ Testing --- Ran faceicontest on Windows 7 and on XP. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
