Re: kf5 alpha 1 : attica?
On Thu, Feb 6, 2014 at 12:21 AM, David Faure fa...@kde.org wrote:
[resent with Frederik's correct email address]
On Thursday 06 February 2014 00:53:53 Frederik Gladhorn wrote:
Thanks a lot, I really appreciate it.
Some issues left:
- who do we write down as maintainer for attica?
- can I run astyle on the code to make it consistent with all other
frameworks? ('kdelibs' coding style, almost like the qt one)
Yes.
- does it have a component on bugs.kde.org?
Yes.
- does it exist on reviewboard.kde.org?
Yes.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Taking over maintainer role for KConfig/KDNSSD
Hi all, Just to let everyone know, I'm taking over the role of maintainer for both KConfig and KDNSSD. I'm most contactable at this email address ( matt...@mjdsystems.ca ). I'm usually idling on IRC with a nick of MJD, but I'm not always watching IRC. I'll do my best to watch over the frameworks, but I'm not sure how much I'll be able to push them forward in the near future. At the very least I'll keep an eye on any review requests that come in on either framework, and keep an eye on Jenkins for both of them. I've already discussed my situation with Kévin Ottens, and he confirmed this was ok. Thanks, -- Matthew smime.p7s Description: S/MIME cryptographic signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Integration Plugin not picked on Wayland
Hi frameworkers, I just did the ultimate test of running Kate on Wayland (Weston) [1] and noticed that our integration plugin seems not to get picked. At least Oxygen is not used as the widget style and icons in menus are missing, etc. See screenshot in [2]. Does anyone have an idea why that might be the case and how to properly investigate this? Cheers Martin [1] WAYLAND_DISPLAY=wayland-0 kate -platform wayland [2] https://picasaweb.google.com/lh/photo/fnxesWgi24ekyFqNaPjrXNMTjNZETYmyPJy0liipFm0 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 115459: Introduce runtime platform support in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/ --- (Updated Feb. 6, 2014, 10:19 a.m.) Review request for KDE Frameworks, kdewin and Alexander Richardson. Changes --- changed to pure virtual class as agateau suggested to get rid of compiler dependent macro Repository: kwindowsystem Description --- Introduce runtime platform support in KWindowSystem This is a change similar to the one in KWindowInfo, but with variation to the pattern due to the static container. There is now a generic implementation of KWindowSystem which is completely windowing system platform independent. This implementation delegates all methods into a KWindowSystemPrivate class. Each windowing system platform implementation needs to provide a subclass (e.g. KWindowSystemPrivateX11) and provide all the methods which are delegated. Note that there are no virtual methods defined, instead the d-pointer gets casted into the proper type. Thus if a method is not provided it will end in a compile error. To make use of a platform implementation it needs to be included in the ctor of KWindowSystemStaticContainer and the PlatformImplementation enum needs to be extended by a value for the platform. This is used in the D macro to cast and delegate correctly. There is a dummy implementation for all not supported windowing system platforms. This change also includes some API changes: * KWindowSystem::windows() returns a copy instead of const-ref * All methods are provided, there is no longer X11 specific methods * private methods and enums are removed NOTE: This change breaks the implementation for Windows and Mac OS! They are currently excluded from build. Diffs (updated) - src/CMakeLists.txt 23133d581944a8373b9b753b300d97054b7d6f18 src/kwindowinfo.cpp c706b29b306b65c992a178d490819b76e1aeca84 src/kwindowsystem.h d288e1ab7c49f68482c94285c2aab695f08f3524 src/kwindowsystem.cpp PRE-CREATION src/kwindowsystem_p.h PRE-CREATION src/kwindowsystem_p_x11.h PRE-CREATION src/kwindowsystem_x11.cpp 8d841cbcec41dc2d4df381338803902badf3f35e Diff: https://git.reviewboard.kde.org/r/115459/diff/ Testing --- Unit tests still succeed for X11, but they are not complete, though the most important aspects are tested. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Integration Plugin not picked on Wayland
Hello, On Thursday 06 February 2014 09:37:39 Martin Gräßlin wrote: Does anyone have an idea why that might be the case and how to properly investigate this? Guessing: Does the platform plugin for wayland reimplement QPlatformIntegration::themeNames()? Ideally it should provide the same list than QGenericUnixTheme::themeNames() which is used by QXcbIntegration::themeNames(). 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: Re: Integration Plugin not picked on Wayland
On Thursday 06 February 2014 10:40:06 Kevin Ottens wrote: Hello, On Thursday 06 February 2014 09:37:39 Martin Gräßlin wrote: Does anyone have an idea why that might be the case and how to properly investigate this? Guessing: Does the platform plugin for wayland reimplement QPlatformIntegration::themeNames()? Ideally it should provide the same list than QGenericUnixTheme::themeNames() which is used by QXcbIntegration::themeNames(). Yes could be: // Ignore X11 desktop environments Let's see whether changing that fixes it. 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: Review Request 115485: Porting KTranscript from KJS to QtScript
On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote: Wow, great work! I attempted doing this some time ago, and all I managed to produce was two unit tests :). Looks good to me and works fine here. Just two (really minor) nitpicks. Kevin Krammer wrote: Thanks :) Good to hear that it works properly, I guess we should try to increase the test coverage before we merge a change like that. I'll see what I can contribute to that effort but ideally someone who really understands how this is used can contribute a couple of advanced test cases :) Chusslove Illich wrote: I don't see any place where a change in semantics could have been introduced, so I expect it to work if it worked for the existing tests. But I'll try to add more test cases over the weekend, for the piece of mind. Side note (repeating myself for the record): I don't see significant benefit in ki18n being tier 1, and I'm not happy about switching to a JavaScript engine with strong ambitions in the Web world (overmaintained). But porting work has been done, and that trumps my fuzzy uneasiness. Thanks for checking. I tried to change as little as possible, but running a couple of actual usages can't hurt. My motivation was mainly that I promised ervin to look into this at Akademy ;-) Didn't get around to it sooner - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review49036 --- On Feb. 5, 2014, 4:08 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 5, 2014, 4:08 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - CMakeLists.txt 3e099d5 src/CMakeLists.txt 55fa512 src/ktranscript.cpp 2fde5c2 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: Integration Plugin not picked on Wayland
Martin GräßlinOn Thursday 06 February 2014 10:49:36 wrote: On Thursday 06 February 2014 10:40:06 Kevin Ottens wrote: Hello, On Thursday 06 February 2014 09:37:39 Martin Gräßlin wrote: Does anyone have an idea why that might be the case and how to properly investigate this? Guessing: Does the platform plugin for wayland reimplement QPlatformIntegration::themeNames()? Ideally it should provide the same list than QGenericUnixTheme::themeNames() which is used by QXcbIntegration::themeNames(). Yes could be: // Ignore X11 desktop environments Let's see whether changing that fixes it. Yes, fixes it with the result that app crashes on startup, because Oxygen uses xcb unconditionally. /me goes fixing Oxygen :-) 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: Re: Re: Re: Integration Plugin not picked on Wayland
Martin GräßlinOn Thursday 06 February 2014 10:54:42 wrote: Yes, fixes it with the result that app crashes on startup, because Oxygen uses xcb unconditionally. /me goes fixing Oxygen :-) and the screenshot of Kate with Oxygen on Wayland: https://picasaweb.google.com/lh/photo/lKMMLhvhaez0Vv-XQCqU3tMTjNZETYmyPJy0liipFm0?feat=directlink sorry for the spam :-P 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: Splitting kde-workspace and kde-runtime proposal
On Tue, Jan 28, 2014 at 6:34 PM, Aleix Pol aleix...@kde.org wrote: On Mon, Jan 27, 2014 at 3:21 PM, David Edmundson da...@davidedmundson.co.uk wrote: There is an existing page about slitting runtime here: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization linked to from http://community.kde.org/Frameworks/Epics Alex's wiki page looks far more populated. We should make sure we avoid wiki duplication. David ___ Plasma-devel mailing list plasma-de...@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I merged all the notes about kde-runtime from last Plasma sprint into the old page: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization I'd suggest to remove the notes from the sprint and keep the old one as the official one to keep track of the state. Aleix Since nobody said anything, I decided to remove the new one, removing the duplication. I'll start working on that splitting this week, hopefully. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
On Feb. 5, 2014, 6:52 p.m., Michael Palimaka wrote: CMakeLists.txt, lines 28-30 https://git.reviewboard.kde.org/r/115504/diff/1/?file=242131#file242131line28 Curious, what's the advantage to having a new variable vs. checking Qt5PrintSupport_FOUND later? Well, the relationship between, say OpenEXR_FOUND and the exr plugin is pretty obvious, but the EPS plugin technically depends on (Qt5PrintSupport_FOUND AND UNIX) (although, as you note, as long as no other part of the code uses Qt5PrintSupport, just checking Qt5PrintSupport_FOUND is sufficient). I just figured this would be easier to follow in src/ and autotests/, and avoid duplicating non-obvious tests. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/#review49066 --- On Feb. 5, 2014, 5:41 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 5, 2014, 5:41 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 2b88843e677163d8229d2a3b9055a540f7fb5961 autotests/CMakeLists.txt 0192636c3617bf37264a3895e61ecd837e228c4a src/imageformats/CMakeLists.txt 242753e0b2c493bbf1da9654967494415e8249d8 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. 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 115502: Fix math function checks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115502/ --- (Updated Feb. 6, 2014, 12:05 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Bernd Buschinski and Harald Fernengel. Repository: kjs Description --- Fix math function checks Between things being in the std:: namespace and math.h and cmath interfering with each other (at least for glibc), the configure checks for math functions do not actually perform the checks they claim to. This tests that the functions (in whatever form) can reasonably be called from C++ code that includes both math.h and cmath. Diffs - src/kjs/ConfigureChecks.cmake 473da1c19c9e8788e3ac407d382f8bcf4882a10f src/kjs/global.h.cmake d821a7264f0e2b46b422a8d68d397799a288bde9 src/kjs/operations.h a54f366330b937a027d478cbe018a7c1c21c1625 Diff: https://git.reviewboard.kde.org/r/115502/diff/ Testing --- Configures, builds and installs with gcc 4.8.2 and glibc 2.18 (Archlinux). The configure checks report the results you would expect (providing you are aware that cmath undefs signbit). 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 115502: Fix math function checks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115502/#review49110 --- This review has been submitted with commit a668187d82ec1f129ed9608a2d71fb5d20730b98 by Alex Merry to branch master. - Commit Hook On Feb. 5, 2014, 5:03 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115502/ --- (Updated Feb. 5, 2014, 5:03 p.m.) Review request for KDE Frameworks, Bernd Buschinski and Harald Fernengel. Repository: kjs Description --- Fix math function checks Between things being in the std:: namespace and math.h and cmath interfering with each other (at least for glibc), the configure checks for math functions do not actually perform the checks they claim to. This tests that the functions (in whatever form) can reasonably be called from C++ code that includes both math.h and cmath. Diffs - src/kjs/ConfigureChecks.cmake 473da1c19c9e8788e3ac407d382f8bcf4882a10f src/kjs/global.h.cmake d821a7264f0e2b46b422a8d68d397799a288bde9 src/kjs/operations.h a54f366330b937a027d478cbe018a7c1c21c1625 Diff: https://git.reviewboard.kde.org/r/115502/diff/ Testing --- Configures, builds and installs with gcc 4.8.2 and glibc 2.18 (Archlinux). The configure checks report the results you would expect (providing you are aware that cmath undefs signbit). 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 115459: Introduce runtime platform support in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/#review49113 --- Ship it! Ship It! - Alexander Richardson On Feb. 6, 2014, 10:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/ --- (Updated Feb. 6, 2014, 10:19 a.m.) Review request for KDE Frameworks, kdewin and Alexander Richardson. Repository: kwindowsystem Description --- Introduce runtime platform support in KWindowSystem This is a change similar to the one in KWindowInfo, but with variation to the pattern due to the static container. There is now a generic implementation of KWindowSystem which is completely windowing system platform independent. This implementation delegates all methods into a KWindowSystemPrivate class. Each windowing system platform implementation needs to provide a subclass (e.g. KWindowSystemPrivateX11) and provide all the methods which are delegated. Note that there are no virtual methods defined, instead the d-pointer gets casted into the proper type. Thus if a method is not provided it will end in a compile error. To make use of a platform implementation it needs to be included in the ctor of KWindowSystemStaticContainer and the PlatformImplementation enum needs to be extended by a value for the platform. This is used in the D macro to cast and delegate correctly. There is a dummy implementation for all not supported windowing system platforms. This change also includes some API changes: * KWindowSystem::windows() returns a copy instead of const-ref * All methods are provided, there is no longer X11 specific methods * private methods and enums are removed NOTE: This change breaks the implementation for Windows and Mac OS! They are currently excluded from build. Diffs - src/CMakeLists.txt 23133d581944a8373b9b753b300d97054b7d6f18 src/kwindowinfo.cpp c706b29b306b65c992a178d490819b76e1aeca84 src/kwindowsystem.h d288e1ab7c49f68482c94285c2aab695f08f3524 src/kwindowsystem.cpp PRE-CREATION src/kwindowsystem_p.h PRE-CREATION src/kwindowsystem_p_x11.h PRE-CREATION src/kwindowsystem_x11.cpp 8d841cbcec41dc2d4df381338803902badf3f35e Diff: https://git.reviewboard.kde.org/r/115459/diff/ Testing --- Unit tests still succeed for X11, but they are not complete, though the most important aspects are tested. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115459: Introduce runtime platform support in KWindowSystem
On Feb. 6, 2014, 2:14 a.m., Alexander Richardson wrote: src/kwindowsystem.cpp, line 342 https://git.reviewboard.kde.org/r/115459/diff/2-3/?file=242085#file242085line342 The non-MSVC macro has a return statement, I think this one needs it as well Andrius da Costa Ribas wrote: Why is this conditioned to Q_CC_MSVC in first place? if it's because of the variadic macros, gcc accepts __VA_ARGS__ too (the other way is a gcc extension), otherwise if it's because of the Xcb case, then it should be conditioned to the OS, not the compiler. Martin Gräßlin wrote: I'm tempted to change to pure virtual methods just to get rid of the define :-) Ah of course, the empty macro expansion doesn't matter here, since there are no commas previously. I thought we need the GCC/MSVC extension to get rid of the previous comma, but it's not needed here. Both should work fine with variadic macros - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/#review49088 --- On Feb. 6, 2014, 10:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/ --- (Updated Feb. 6, 2014, 10:19 a.m.) Review request for KDE Frameworks, kdewin and Alexander Richardson. Repository: kwindowsystem Description --- Introduce runtime platform support in KWindowSystem This is a change similar to the one in KWindowInfo, but with variation to the pattern due to the static container. There is now a generic implementation of KWindowSystem which is completely windowing system platform independent. This implementation delegates all methods into a KWindowSystemPrivate class. Each windowing system platform implementation needs to provide a subclass (e.g. KWindowSystemPrivateX11) and provide all the methods which are delegated. Note that there are no virtual methods defined, instead the d-pointer gets casted into the proper type. Thus if a method is not provided it will end in a compile error. To make use of a platform implementation it needs to be included in the ctor of KWindowSystemStaticContainer and the PlatformImplementation enum needs to be extended by a value for the platform. This is used in the D macro to cast and delegate correctly. There is a dummy implementation for all not supported windowing system platforms. This change also includes some API changes: * KWindowSystem::windows() returns a copy instead of const-ref * All methods are provided, there is no longer X11 specific methods * private methods and enums are removed NOTE: This change breaks the implementation for Windows and Mac OS! They are currently excluded from build. Diffs - src/CMakeLists.txt 23133d581944a8373b9b753b300d97054b7d6f18 src/kwindowinfo.cpp c706b29b306b65c992a178d490819b76e1aeca84 src/kwindowsystem.h d288e1ab7c49f68482c94285c2aab695f08f3524 src/kwindowsystem.cpp PRE-CREATION src/kwindowsystem_p.h PRE-CREATION src/kwindowsystem_p_x11.h PRE-CREATION src/kwindowsystem_x11.cpp 8d841cbcec41dc2d4df381338803902badf3f35e Diff: https://git.reviewboard.kde.org/r/115459/diff/ Testing --- Unit tests still succeed for X11, but they are not complete, though the most important aspects are tested. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115495: Make kgenframeworksapidox generate dependency diagrams
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/#review49120 --- Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... Third thing: have you tested with python3? - Alex Merry On Feb. 5, 2014, 2:43 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/ --- (Updated Feb. 5, 2014, 2:43 p.m.) Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau. Repository: kapidox Description --- This big patch moves code from depdiagram-prepare and depdiagram-generate to Python modules and make kgenframeworksapidox use those modules to generate the dependency frameworks. This only happens when it is called with the --dependency-diagrams option. Since the patch is going to be painful to review here, I also uploaded the patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration Diffs - src/depdiagram-generate adabe27 src/depdiagram-prepare 3d133d9 src/kapidox/__init__.py 0024723 src/kapidox/data/dependencies.md 5e30d09 src/kapidox/data/dependencies.md.mustache PRE-CREATION src/kapidox/depdiagram/__init__.py e69de29 src/kapidox/depdiagram/frameworkdb.py 9b63c8b src/kapidox/depdiagram/generate.py PRE-CREATION src/kapidox/depdiagram/prepare.py PRE-CREATION src/kgenframeworksapidox ac34f2c Diff: https://git.reviewboard.kde.org/r/115495/diff/ Testing --- Generated the whole thing, works as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115495: Make kgenframeworksapidox generate dependency diagrams
On Feb. 6, 2014, 1:56 p.m., Alex Merry wrote: Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... Third thing: have you tested with python3? Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Good point. Will fix. Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this. Third thing: have you tested with python3? No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter. - Aurélien --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/#review49120 --- On Feb. 5, 2014, 3:43 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/ --- (Updated Feb. 5, 2014, 3:43 p.m.) Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau. Repository: kapidox Description --- This big patch moves code from depdiagram-prepare and depdiagram-generate to Python modules and make kgenframeworksapidox use those modules to generate the dependency frameworks. This only happens when it is called with the --dependency-diagrams option. Since the patch is going to be painful to review here, I also uploaded the patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration Diffs - src/depdiagram-generate adabe27 src/depdiagram-prepare 3d133d9 src/kapidox/__init__.py 0024723 src/kapidox/data/dependencies.md 5e30d09 src/kapidox/data/dependencies.md.mustache PRE-CREATION src/kapidox/depdiagram/__init__.py e69de29 src/kapidox/depdiagram/frameworkdb.py 9b63c8b src/kapidox/depdiagram/generate.py PRE-CREATION src/kapidox/depdiagram/prepare.py PRE-CREATION src/kgenframeworksapidox ac34f2c Diff: https://git.reviewboard.kde.org/r/115495/diff/ Testing --- Generated the whole thing, works as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115517: Do not crash if there is no QMimeData in decodeIsCutSelection
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/ --- Review request for KDE Frameworks and David Faure. Repository: kio Description --- Do not crash if there is no QMimeData in decodeIsCutSelection On Wayland the QMimeData is null and thus the Open File dialog crashed when trying to enter a directory. Diffs - src/filewidgets/kfilepreviewgenerator.cpp cdc18a18508eceb58b9fbcad9b68b47bf534996c Diff: https://git.reviewboard.kde.org/r/115517/diff/ Testing --- Kate on Wayland can open files now: http://paste.opensuse.org/79557635 Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115495: Make kgenframeworksapidox generate dependency diagrams
On Feb. 6, 2014, 12:56 p.m., Alex Merry wrote: Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... Third thing: have you tested with python3? Aurélien Gâteau wrote: Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Good point. Will fix. Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this. Third thing: have you tested with python3? No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter. I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this. Fair enough, although did you look at pygraphviz as an alternative? That appears to mostly interface with the tools. No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter. Currently, I believe it's running under Python 3 on the EBN (although Python 2 is available there). So... that's something to consider. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/#review49120 --- On Feb. 5, 2014, 2:43 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/ --- (Updated Feb. 5, 2014, 2:43 p.m.) Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau. Repository: kapidox Description --- This big patch moves code from depdiagram-prepare and depdiagram-generate to Python modules and make kgenframeworksapidox use those modules to generate the dependency frameworks. This only happens when it is called with the --dependency-diagrams option. Since the patch is going to be painful to review here, I also uploaded the patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration Diffs - src/depdiagram-generate adabe27 src/depdiagram-prepare 3d133d9 src/kapidox/__init__.py 0024723 src/kapidox/data/dependencies.md 5e30d09 src/kapidox/data/dependencies.md.mustache PRE-CREATION src/kapidox/depdiagram/__init__.py e69de29 src/kapidox/depdiagram/frameworkdb.py 9b63c8b src/kapidox/depdiagram/generate.py PRE-CREATION src/kapidox/depdiagram/prepare.py PRE-CREATION src/kgenframeworksapidox ac34f2c Diff: https://git.reviewboard.kde.org/r/115495/diff/ Testing --- Generated the whole thing, works as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115517: Do not crash if there is no QMimeData in decodeIsCutSelection
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/#review49126 --- I think the tests would make more sense at the calling sites. KFilePreviewGenerator::Private::applyCutItemEffect, in particular, also passes the mimeData to KUrlMimeData::urlsFromMimeData later in the function (which must not be 0). It then depends on decodeIsCutSelection always returning false when passed 0 to not crash later. I mean, your way works, but I think moving the test to the calling sites is more resilient to future code changes. - Alex Merry On Feb. 6, 2014, 1:18 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/ --- (Updated Feb. 6, 2014, 1:18 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- Do not crash if there is no QMimeData in decodeIsCutSelection On Wayland the QMimeData is null and thus the Open File dialog crashed when trying to enter a directory. Diffs - src/filewidgets/kfilepreviewgenerator.cpp cdc18a18508eceb58b9fbcad9b68b47bf534996c Diff: https://git.reviewboard.kde.org/r/115517/diff/ Testing --- Kate on Wayland can open files now: http://paste.opensuse.org/79557635 Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115481: Improve knotifyconfig dependencies
On Feb. 5, 2014, 11:58 a.m., Alex Merry wrote: tests/CMakeLists.txt, lines 7-20 https://git.reviewboard.kde.org/r/115481/diff/2/?file=241988#file241988line7 These should all be PURPOSE, not DESCRIPTION. Also, Qt5Test should have its PURPOSE set as well. Michael Palimaka wrote: It looks like there's a couple of other frameworks that need this change too. True, that. Somewhere low on my list of CMake-related tasks :-) - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115481/#review49017 --- On Feb. 5, 2014, 1:04 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115481/ --- (Updated Feb. 5, 2014, 1:04 p.m.) Review request for KDE Frameworks and David Edmundson. Repository: knotifyconfig Description --- - Remove transitive dependencies - Make test dependencies optional Diffs - CMakeLists.txt 78b3c717ee0eb9a4de4ebef95094f0bda00e6ef2 tests/CMakeLists.txt 26a78de9e6052f650e5f6a95812dccd272dd8c4e Diff: https://git.reviewboard.kde.org/r/115481/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115517: Do not crash if there is no QMimeData in decodeIsCutSelection
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/ --- (Updated Feb. 6, 2014, 2:37 p.m.) Review request for KDE Frameworks and David Faure. Changes --- added an additional check to the calling side. Repository: kio Description --- Do not crash if there is no QMimeData in decodeIsCutSelection On Wayland the QMimeData is null and thus the Open File dialog crashed when trying to enter a directory. Diffs (updated) - src/filewidgets/kfilepreviewgenerator.cpp cdc18a18508eceb58b9fbcad9b68b47bf534996c Diff: https://git.reviewboard.kde.org/r/115517/diff/ Testing --- Kate on Wayland can open files now: http://paste.opensuse.org/79557635 Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115517: Do not crash if there is no QMimeData in decodeIsCutSelection
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/#review49128 --- Ship it! OK, that works. - Alex Merry On Feb. 6, 2014, 1:37 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115517/ --- (Updated Feb. 6, 2014, 1:37 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- Do not crash if there is no QMimeData in decodeIsCutSelection On Wayland the QMimeData is null and thus the Open File dialog crashed when trying to enter a directory. Diffs - src/filewidgets/kfilepreviewgenerator.cpp cdc18a18508eceb58b9fbcad9b68b47bf534996c Diff: https://git.reviewboard.kde.org/r/115517/diff/ Testing --- Kate on Wayland can open files now: http://paste.opensuse.org/79557635 Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115495: Make kgenframeworksapidox generate dependency diagrams
On Feb. 6, 2014, 1:56 p.m., Alex Merry wrote: Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... Third thing: have you tested with python3? Aurélien Gâteau wrote: Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb). You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams). Good point. Will fix. Second thing: why call dot directly instead of using yapgvb to render to PNG? Although it looks like tred might not be an option in that case... I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this. Third thing: have you tested with python3? No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter. Alex Merry wrote: I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this. Fair enough, although did you look at pygraphviz as an alternative? That appears to mostly interface with the tools. No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter. Currently, I believe it's running under Python 3 on the EBN (although Python 2 is available there). So... that's something to consider. Fair enough, although did you look at pygraphviz as an alternative? That appears to mostly interface with the tools. I did: the problem with pygraphviz is that it does not extract enough information: a node is just a string, which is not enough because we need to know the node shape to determine the target kind (see TARGET_SHAPES in frameworkdb.py). Currently, I believe it's running under Python 3 on the EBN (although Python 2 is available there). So... that's something to consider. Oh, I did not know that. That would be a problem: right now yapgvb does not build with Python 3, and since the project is quite inactive, I doubt it is going to change anytime soon. - Aurélien --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/#review49120 --- On Feb. 5, 2014, 3:43 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115495/ --- (Updated Feb. 5, 2014, 3:43 p.m.) Review request for KDE Frameworks, Alex Merry and Aurélien Gâteau. Repository: kapidox Description --- This big patch moves code from depdiagram-prepare and depdiagram-generate to Python modules and make kgenframeworksapidox use those modules to generate the dependency frameworks. This only happens when it is called with the --dependency-diagrams option. Since the patch is going to be painful to review here, I also uploaded the patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration Diffs - src/depdiagram-generate adabe27 src/depdiagram-prepare 3d133d9 src/kapidox/__init__.py 0024723 src/kapidox/data/dependencies.md 5e30d09 src/kapidox/data/dependencies.md.mustache PRE-CREATION src/kapidox/depdiagram/__init__.py e69de29 src/kapidox/depdiagram/frameworkdb.py 9b63c8b src/kapidox/depdiagram/generate.py PRE-CREATION src/kapidox/depdiagram/prepare.py PRE-CREATION src/kgenframeworksapidox ac34f2c Diff: https://git.reviewboard.kde.org/r/115495/diff/ Testing --- Generated the whole thing, works as expected. Thanks, Aurélien Gâteau ___
Re: Review Request 115459: Introduce runtime platform support in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/#review49135 --- This review has been submitted with commit 58d46fc44abb73d96056fecad0c88f8cf450f58e by Martin Gräßlin to branch master. - Commit Hook On Feb. 6, 2014, 9:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/ --- (Updated Feb. 6, 2014, 9:19 a.m.) Review request for KDE Frameworks, kdewin and Alexander Richardson. Repository: kwindowsystem Description --- Introduce runtime platform support in KWindowSystem This is a change similar to the one in KWindowInfo, but with variation to the pattern due to the static container. There is now a generic implementation of KWindowSystem which is completely windowing system platform independent. This implementation delegates all methods into a KWindowSystemPrivate class. Each windowing system platform implementation needs to provide a subclass (e.g. KWindowSystemPrivateX11) and provide all the methods which are delegated. Note that there are no virtual methods defined, instead the d-pointer gets casted into the proper type. Thus if a method is not provided it will end in a compile error. To make use of a platform implementation it needs to be included in the ctor of KWindowSystemStaticContainer and the PlatformImplementation enum needs to be extended by a value for the platform. This is used in the D macro to cast and delegate correctly. There is a dummy implementation for all not supported windowing system platforms. This change also includes some API changes: * KWindowSystem::windows() returns a copy instead of const-ref * All methods are provided, there is no longer X11 specific methods * private methods and enums are removed NOTE: This change breaks the implementation for Windows and Mac OS! They are currently excluded from build. Diffs - src/CMakeLists.txt 23133d581944a8373b9b753b300d97054b7d6f18 src/kwindowinfo.cpp c706b29b306b65c992a178d490819b76e1aeca84 src/kwindowsystem.h d288e1ab7c49f68482c94285c2aab695f08f3524 src/kwindowsystem.cpp PRE-CREATION src/kwindowsystem_p.h PRE-CREATION src/kwindowsystem_p_x11.h PRE-CREATION src/kwindowsystem_x11.cpp 8d841cbcec41dc2d4df381338803902badf3f35e Diff: https://git.reviewboard.kde.org/r/115459/diff/ Testing --- Unit tests still succeed for X11, but they are not complete, though the most important aspects are tested. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115459: Introduce runtime platform support in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115459/ --- (Updated Feb. 6, 2014, 2:22 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kdewin and Alexander Richardson. Repository: kwindowsystem Description --- Introduce runtime platform support in KWindowSystem This is a change similar to the one in KWindowInfo, but with variation to the pattern due to the static container. There is now a generic implementation of KWindowSystem which is completely windowing system platform independent. This implementation delegates all methods into a KWindowSystemPrivate class. Each windowing system platform implementation needs to provide a subclass (e.g. KWindowSystemPrivateX11) and provide all the methods which are delegated. Note that there are no virtual methods defined, instead the d-pointer gets casted into the proper type. Thus if a method is not provided it will end in a compile error. To make use of a platform implementation it needs to be included in the ctor of KWindowSystemStaticContainer and the PlatformImplementation enum needs to be extended by a value for the platform. This is used in the D macro to cast and delegate correctly. There is a dummy implementation for all not supported windowing system platforms. This change also includes some API changes: * KWindowSystem::windows() returns a copy instead of const-ref * All methods are provided, there is no longer X11 specific methods * private methods and enums are removed NOTE: This change breaks the implementation for Windows and Mac OS! They are currently excluded from build. Diffs - src/CMakeLists.txt 23133d581944a8373b9b753b300d97054b7d6f18 src/kwindowinfo.cpp c706b29b306b65c992a178d490819b76e1aeca84 src/kwindowsystem.h d288e1ab7c49f68482c94285c2aab695f08f3524 src/kwindowsystem.cpp PRE-CREATION src/kwindowsystem_p.h PRE-CREATION src/kwindowsystem_p_x11.h PRE-CREATION src/kwindowsystem_x11.cpp 8d841cbcec41dc2d4df381338803902badf3f35e Diff: https://git.reviewboard.kde.org/r/115459/diff/ Testing --- Unit tests still succeed for X11, but they are not complete, though the most important aspects are tested. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115481: Improve knotifyconfig dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115481/ --- (Updated Feb. 6, 2014, 3:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Edmundson. Repository: knotifyconfig Description --- - Remove transitive dependencies - Make test dependencies optional Diffs - CMakeLists.txt 78b3c717ee0eb9a4de4ebef95094f0bda00e6ef2 tests/CMakeLists.txt 26a78de9e6052f650e5f6a95812dccd272dd8c4e Diff: https://git.reviewboard.kde.org/r/115481/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115481: Improve knotifyconfig dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115481/#review49138 --- This review has been submitted with commit b5ffdfc5d9c16deadfb2c64ca01e722a890b2d3e by Michael Palimaka to branch master. - Commit Hook On Feb. 5, 2014, 1:04 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115481/ --- (Updated Feb. 5, 2014, 1:04 p.m.) Review request for KDE Frameworks and David Edmundson. Repository: knotifyconfig Description --- - Remove transitive dependencies - Make test dependencies optional Diffs - CMakeLists.txt 78b3c717ee0eb9a4de4ebef95094f0bda00e6ef2 tests/CMakeLists.txt 26a78de9e6052f650e5f6a95812dccd272dd8c4e Diff: https://git.reviewboard.kde.org/r/115481/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115520: Remove kded transitive dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115520/#review49145 --- Ship it! Ship It! - Alex Merry On Feb. 6, 2014, 4:41 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115520/ --- (Updated Feb. 6, 2014, 4:41 p.m.) Review request for KDE Frameworks and Àlex Fiestas. Repository: kded Description --- Remove transitive dependencies, I can't find any references to them. Diffs - CMakeLists.txt f1d3f880e83052a87be8301f17cae8394fa2e42f KDEDConfig.cmake.in ce98892d9de04c8e0d613fb71b224944e24c78f2 Diff: https://git.reviewboard.kde.org/r/115520/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115520: Remove kded transitive dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115520/ --- (Updated Feb. 6, 2014, 5:41 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Àlex Fiestas. Repository: kded Description --- Remove transitive dependencies, I can't find any references to them. Diffs - CMakeLists.txt f1d3f880e83052a87be8301f17cae8394fa2e42f KDEDConfig.cmake.in ce98892d9de04c8e0d613fb71b224944e24c78f2 Diff: https://git.reviewboard.kde.org/r/115520/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115520: Remove kded transitive dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115520/#review49146 --- This review has been submitted with commit 73c43143c9c18ce4e63c1470bbc0c70e779f2899 by Michael Palimaka to branch master. - Commit Hook On Feb. 6, 2014, 4:41 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115520/ --- (Updated Feb. 6, 2014, 4:41 p.m.) Review request for KDE Frameworks and Àlex Fiestas. Repository: kded Description --- Remove transitive dependencies, I can't find any references to them. Diffs - CMakeLists.txt f1d3f880e83052a87be8301f17cae8394fa2e42f KDEDConfig.cmake.in ce98892d9de04c8e0d613fb71b224944e24c78f2 Diff: https://git.reviewboard.kde.org/r/115520/diff/ Testing --- Builds. Inspected source. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kf5 alpha 1 : attica?
On Thursday 06 February 2014 07:23:30 Kevin Ottens wrote: On Thursday 06 February 2014 01:15:15 David Faure wrote: Some issues left: - who do we write down as maintainer for attica? Good question, let's mark it TBD until someone dares to step up for it. That said, obviously, if there's someone who feels responsible for Attica, please speak up now! I don't really need yet another framework for which I've to hunt a maintainer. :-) Of course, if you're in CC of that email, it's likely that I've some hopes about you, yes I'm looking at YOU. Cheers. -- 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: kf5 alpha 1 : attica?
On Thursday 06 February 2014 07:23:30 Kevin Ottens wrote: On Thursday 06 February 2014 01:15:15 David Faure wrote: Some issues left: - who do we write down as maintainer for attica? Good question, let's mark it TBD until someone dares to step up for it. That said, obviously, if there's someone who feels responsible for Attica, please speak up now! I don't really need yet another framework for which I've to hunt a maintainer. :-) Of course, if you're in CC of that email, it's likely that I've some hopes about you, yes I'm looking at YOU. Cheers. -- 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
alpha1 release
I have packaged up KF5 alpha 1 and uploaded it for packagers. Can we consider KF5 frozen all of tomorrow (Friday 7) ? This way if there's any showstopper bugfix I can redo the tarballs without bringing in unrelated changes which might create other problems. Sorry for the productivity loss :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115524: Hide a private method and a private slot of KComboBox behind the d-pointer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115524/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Hide a private method and a private slot of KComboBox behind the d-pointer Also: --Change lineEdit() for isEditable() for checking whether the kcombobox is editable. Diffs - src/kcombobox.h e59d72b src/kcombobox.cpp 2cfe6e7 Diff: https://git.reviewboard.kde.org/r/115524/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115524: Hide a private method and a private slot of KComboBox behind the d-pointer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115524/ --- (Updated Feb. 6, 2014, 10:35 p.m.) Review request for KDE Frameworks. Changes --- Uncomment line. Repository: kcompletion Description --- Hide a private method and a private slot of KComboBox behind the d-pointer Also: --Change lineEdit() for isEditable() for checking whether the kcombobox is editable. Diffs (updated) - src/kcombobox.h e59d72b src/kcombobox.cpp 2cfe6e7 Diff: https://git.reviewboard.kde.org/r/115524/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115525: Deprecate slots in KCompletion and convert into slots the methods they call
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115525/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Deprecate three slots (slotFoo()) that the only thing they do is call another method (foo()) Diffs - src/kcompletion.h 2104f1b Diff: https://git.reviewboard.kde.org/r/115525/diff/ Testing --- It builds and tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Taking over maintainer role for KConfig/KDNSSD
On February 6, 2014 12:12:18 PM Alex Merry wrote: On 06/02/14 07:38, Matthew Dawson wrote: I'll do my best to watch over the frameworks, but I'm not sure how much I'll be able to push them forward in the near future. At the very least I'll keep an eye on any review requests that come in on either framework, and keep an eye on Jenkins for both of them. I've already discussed my situation with Kévin Ottens, and he confirmed this was ok. Does that mean that someone else will need to take on the bulk of the work of merging the kdnssd repositories? I assume this merging the frameworks repository with the one from network module? I probably wont be able to do the merge myself. Is there any documentation started on what has to be done for it? -- Matthew smime.p7s Description: S/MIME cryptographic signature ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115526: Refactor private class member variables of KCompletionBase for readability
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115526/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Refactor private class member variables of KCompletionBase for readability Diffs - src/kcompletionbase.h 1c1f23f src/kcompletionbase.cpp 44d05cb Diff: https://git.reviewboard.kde.org/r/115526/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115525: Deprecate slots in KCompletion and convert into slots the methods they call
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115525/#review49161 --- Ship it! Looks good to me - Aleix Pol Gonzalez On Feb. 6, 2014, 11:09 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115525/ --- (Updated Feb. 6, 2014, 11:09 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Deprecate three slots (slotFoo()) that the only thing they do is call another method (foo()) Diffs - src/kcompletion.h 2104f1b Diff: https://git.reviewboard.kde.org/r/115525/diff/ Testing --- It builds and tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: alpha1 release
Hey, On Thu, Feb 6, 2014 at 11:30 PM, David Faure fa...@kde.org wrote: I have packaged up KF5 alpha 1 and uploaded it for packagers. Can we consider KF5 frozen all of tomorrow (Friday 7) ? I have quite some extensive changes for KNotifications (basically merging KNotify daemon to KNotificationManager and repurposing KNotifyConfig a bit). Part of KNotifications is now also KNotifyConfig and the NotifyByPopup KNotify plugin while all the other plugins should follow afterwards. How should I handle this? Merge for 5.0beta (I think that would be done in time minus all the other plugins)? Leave it for 5.1? However I'd like to base the notifications rework of Plasma Next on this and that's due in June, so probably 5.1 will come little bit too late for that. Please advise. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: alpha1 release
Hello, On Friday 07 February 2014 06:25:46 Martin Klapetek wrote: On Thu, Feb 6, 2014 at 11:30 PM, David Faure fa...@kde.org wrote: I have packaged up KF5 alpha 1 and uploaded it for packagers. Can we consider KF5 frozen all of tomorrow (Friday 7) ? I have quite some extensive changes for KNotifications (basically merging KNotify daemon to KNotificationManager and repurposing KNotifyConfig a bit). Part of KNotifications is now also KNotifyConfig and the NotifyByPopup KNotify plugin while all the other plugins should follow afterwards. How should I handle this? Merge for 5.0beta (I think that would be done in time minus all the other plugins)? Leave it for 5.1? However I'd like to base the notifications rework of Plasma Next on this and that's due in June, so probably 5.1 will come little bit too late for that. No chance to aim it for alpha 2? That'd be the preferred option. 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
