Re: Review Request 117275: Deprecate the catalog name stuff from KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/#review55486 --- Ship it! Ship It! - David Faure On April 1, 2014, 10:09 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/ --- (Updated April 1, 2014, 10:09 a.m.) Review request for KDE Frameworks, David Faure, Kevin Ottens, and Michael Pyne. Repository: kcoreaddons Description --- This is another thing on the if only we'd spotted it before beta1 list. I went with not allowing any optional arguments to the constructor, to encourage users of the class to use setters, which makes for more readable code. I deliberated giving it just one argument, but in the end went with the formerly-required arguments. The organizationDomain is not automatically set from the home page with this new usage style, as that only happened in the constructor and not in the setter. It could be set if the organizationDomain has not been explicitly set. However, the organizationDomain is not passed to QCoreApplication as I assumed it would be - it that intentional? Deprecate the catalog name stuff from KAboutData This is pretty useless - the translation catalog has to be set before KAboutData is constructed in order to translate its arguments. Diffs - src/lib/kaboutdata.h cff1e3f67e33657fdd265a82166ef2a04cbcc3d1 src/lib/kaboutdata.cpp ce64a13aaa89bb4bc077f05e5f8e175d6a441ead Diff: https://git.reviewboard.kde.org/r/117275/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117275: Deprecate the catalog name stuff from KAboutData
On April 12, 2014, 9:16 a.m., David Faure wrote: Ship It! Well, I guess the first diff minimizes the porting effort indeed. Also: the domain name can only be passed to QCoreApp if this is the main aboutdata (we also have a KAboutData per plugin). But yeah, that seems to be missing in KAboutData::setApplicationData. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/#review55486 --- On April 1, 2014, 10:09 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/ --- (Updated April 1, 2014, 10:09 a.m.) Review request for KDE Frameworks, David Faure, Kevin Ottens, and Michael Pyne. Repository: kcoreaddons Description --- This is another thing on the if only we'd spotted it before beta1 list. I went with not allowing any optional arguments to the constructor, to encourage users of the class to use setters, which makes for more readable code. I deliberated giving it just one argument, but in the end went with the formerly-required arguments. The organizationDomain is not automatically set from the home page with this new usage style, as that only happened in the constructor and not in the setter. It could be set if the organizationDomain has not been explicitly set. However, the organizationDomain is not passed to QCoreApplication as I assumed it would be - it that intentional? Deprecate the catalog name stuff from KAboutData This is pretty useless - the translation catalog has to be set before KAboutData is constructed in order to translate its arguments. Diffs - src/lib/kaboutdata.h cff1e3f67e33657fdd265a82166ef2a04cbcc3d1 src/lib/kaboutdata.cpp ce64a13aaa89bb4bc077f05e5f8e175d6a441ead Diff: https://git.reviewboard.kde.org/r/117275/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117275: Deprecate the catalog name stuff from KAboutData
On April 12, 2014, 9:16 a.m., David Faure wrote: Ship It! David Faure wrote: Well, I guess the first diff minimizes the porting effort indeed. Also: the domain name can only be passed to QCoreApp if this is the main aboutdata (we also have a KAboutData per plugin). But yeah, that seems to be missing in KAboutData::setApplicationData. I could also combine them and add both the short-form and long-form constructors. I guess the question is: do we want to push users towards a particular style? The short constructors and setters is what Qt has been moving towards, on the basis it makes more readable code; do we want to do the same with this class? The organization domain stuff has a fallback to kde.org; currently this doesn't really matter, as we don't actually do anything with it. But if we're passing it to QCoreApplication, we should think about in the frameworks world (with a hopefully wider audience for these frameworks) we really want that default there. It's easy enough to make the homepage setter change the organization domain if the org dom was never explicitly set (a bool flag would do the trick). - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/#review55486 --- On April 1, 2014, 10:09 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/ --- (Updated April 1, 2014, 10:09 a.m.) Review request for KDE Frameworks, David Faure, Kevin Ottens, and Michael Pyne. Repository: kcoreaddons Description --- This is another thing on the if only we'd spotted it before beta1 list. I went with not allowing any optional arguments to the constructor, to encourage users of the class to use setters, which makes for more readable code. I deliberated giving it just one argument, but in the end went with the formerly-required arguments. The organizationDomain is not automatically set from the home page with this new usage style, as that only happened in the constructor and not in the setter. It could be set if the organizationDomain has not been explicitly set. However, the organizationDomain is not passed to QCoreApplication as I assumed it would be - it that intentional? Deprecate the catalog name stuff from KAboutData This is pretty useless - the translation catalog has to be set before KAboutData is constructed in order to translate its arguments. Diffs - src/lib/kaboutdata.h cff1e3f67e33657fdd265a82166ef2a04cbcc3d1 src/lib/kaboutdata.cpp ce64a13aaa89bb4bc077f05e5f8e175d6a441ead Diff: https://git.reviewboard.kde.org/r/117275/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55490 --- Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves? That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO). Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit? - Alex Merry On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
On April 12, 2014, 10:11 a.m., Alex Merry wrote: Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves? That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO). Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit? Interesting idea, but yeah, this is rather rarely used metadata, so hacking the central method for it makes me uneasy in terms of performance and maintenance (there are 4 methods: set, add, add, and merge). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55490 --- On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117275: Deprecate the catalog name stuff from KAboutData
On April 12, 2014, 9:16 a.m., David Faure wrote: Ship It! David Faure wrote: Well, I guess the first diff minimizes the porting effort indeed. Also: the domain name can only be passed to QCoreApp if this is the main aboutdata (we also have a KAboutData per plugin). But yeah, that seems to be missing in KAboutData::setApplicationData. Alex Merry wrote: I could also combine them and add both the short-form and long-form constructors. I guess the question is: do we want to push users towards a particular style? The short constructors and setters is what Qt has been moving towards, on the basis it makes more readable code; do we want to do the same with this class? The organization domain stuff has a fallback to kde.org; currently this doesn't really matter, as we don't actually do anything with it. But if we're passing it to QCoreApplication, we should think about in the frameworks world (with a hopefully wider audience for these frameworks) we really want that default there. It's easy enough to make the homepage setter change the organization domain if the org dom was never explicitly set (a bool flag would do the trick). Right, let's have both. Domain name: if unset by app, whether it's kde.org or empty string will be wrong for apps that should get something else, so I would leave the default as is, it caters to the current majority of users of this code, and others have to set something anyway. Getting it from the homepage setter is probably fine though. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/#review55486 --- On April 1, 2014, 10:09 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117275/ --- (Updated April 1, 2014, 10:09 a.m.) Review request for KDE Frameworks, David Faure, Kevin Ottens, and Michael Pyne. Repository: kcoreaddons Description --- This is another thing on the if only we'd spotted it before beta1 list. I went with not allowing any optional arguments to the constructor, to encourage users of the class to use setters, which makes for more readable code. I deliberated giving it just one argument, but in the end went with the formerly-required arguments. The organizationDomain is not automatically set from the home page with this new usage style, as that only happened in the constructor and not in the setter. It could be set if the organizationDomain has not been explicitly set. However, the organizationDomain is not passed to QCoreApplication as I assumed it would be - it that intentional? Deprecate the catalog name stuff from KAboutData This is pretty useless - the translation catalog has to be set before KAboutData is constructed in order to translate its arguments. Diffs - src/lib/kaboutdata.h cff1e3f67e33657fdd265a82166ef2a04cbcc3d1 src/lib/kaboutdata.cpp ce64a13aaa89bb4bc077f05e5f8e175d6a441ead Diff: https://git.reviewboard.kde.org/r/117275/diff/ Testing --- Builds, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
On April 12, 2014, 10:11 a.m., Alex Merry wrote: Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves? That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO). Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit? David Faure wrote: Interesting idea, but yeah, this is rather rarely used metadata, so hacking the central method for it makes me uneasy in terms of performance and maintenance (there are 4 methods: set, add, add, and merge). It looks like the only non-core ioslave to implement this is sftp (unless there's one lurking outside kio-extras, formerly kde-runtime, that implements it). My only concern would be what happens if the app sets the new metadata, and the slave only reads the old metadata. Would that ever result in corrupted data (eg: [segment1][segment1][segment2] instead of [segment1][segment2]), or would it just result in extra network traffic? - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55490 --- On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
On April 12, 2014, 10:11 a.m., Alex Merry wrote: Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves? That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO). Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit? David Faure wrote: Interesting idea, but yeah, this is rather rarely used metadata, so hacking the central method for it makes me uneasy in terms of performance and maintenance (there are 4 methods: set, add, add, and merge). Alex Merry wrote: It looks like the only non-core ioslave to implement this is sftp (unless there's one lurking outside kio-extras, formerly kde-runtime, that implements it). My only concern would be what happens if the app sets the new metadata, and the slave only reads the old metadata. Would that ever result in corrupted data (eg: [segment1][segment1][segment2] instead of [segment1][segment2]), or would it just result in extra network traffic? Or is it reasonable to assume we can port all ioslaves that exist, so this will never be an issue? - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55490 --- On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
On April 12, 2014, 10:11 a.m., Alex Merry wrote: Would it not make sense to put the compatibility stuff in KIO::Job::addMetaData, rather than the slaves? That way it should maintain compatibility on both the application and slave side (for slaves shipped outside KIO). Although I guess setMetaData dn mergeMetaData would need the same compat hacks... would that be too much of a performance/maintenance hit? David Faure wrote: Interesting idea, but yeah, this is rather rarely used metadata, so hacking the central method for it makes me uneasy in terms of performance and maintenance (there are 4 methods: set, add, add, and merge). Alex Merry wrote: It looks like the only non-core ioslave to implement this is sftp (unless there's one lurking outside kio-extras, formerly kde-runtime, that implements it). My only concern would be what happens if the app sets the new metadata, and the slave only reads the old metadata. Would that ever result in corrupted data (eg: [segment1][segment1][segment2] instead of [segment1][segment2]), or would it just result in extra network traffic? Alex Merry wrote: Or is it reasonable to assume we can port all ioslaves that exist, so this will never be an issue? When resuming a download in FileCopyJob, there's some negotiation with the slave (SlaveBase::canResume), so no bug other than extra network traffic. When an app requests a range directly ... it has to know that the slave supports it. And yeah, I'm confident we can port all the ioslaves that support it (I'm not surprised that only sftp is left). So all this compat stuff was really just to be on the safe side, but I don't expect it to be ever useful. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55490 --- On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55496 --- Ship it! OK, I'm convinced. - Alex Merry On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review55497 --- This is my preferred solution, and is hopefully only a temporary one. However, I know David Faure doesn't like it, and (I assume) would rather have a generic LIBEXEC variable. My view is that libexec should be used for stuff that's really internal to a piece of software (like a framework), and so a libexec env var shouldn't be necessary (except maybe for relocatability?), but the current situation with drkonqi should hopefully be a temporary one (until 5.1 or something), and so a specific var for unusual situations is reasonable. However, given that an objection has already been raised by the maintainer, I'm not willing to give it a ship-it without his agreement. - Alex Merry On April 9, 2014, 8:47 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated April 9, 2014, 8:47 a.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review55498 --- src/kcrash.cpp https://git.reviewboard.kde.org/r/117016/#comment38614 This should happen even if the env var is used. - Alex Merry On April 9, 2014, 8:47 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated April 9, 2014, 8:47 a.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/#review55499 --- This review has been submitted with commit bec5d7e98f8ad5420e8398c27dc832681b7f706d by David Faure to branch master. - Commit Hook On April 12, 2014, 9:55 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 9:55 a.m.) Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117508: KIO metadata: resume - range-start, resume_until - range-end.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117508/ --- (Updated April 12, 2014, 10:51 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Alex Merry. Repository: kio Description --- KIO metadata: resume - range-start, resume_until - range-end. This is much more self-explanatory to people wanting to request a byte range, unrelated to anything like resuming an interrupted download. Diffs - docs/metadata.txt b2422f9c816f53d5cec9fbdc0e899329cdb26f30 src/core/filecopyjob.cpp 7bce804eb516f882bfc53af207245e847a27ad8d src/core/scheduler.cpp f9bc1482b2b8e66b5880f5875567cd485a5b4a5c src/core/slavebase.h 7417c5e798d843641886fbea62f330524fd12481 src/ioslaves/file/file.cpp a642a524c3022ce7f039f90d5bc1f577c88631dc src/ioslaves/ftp/ftp.cpp 79f6144264c03f506309037ed6e8ce429f6c30f0 src/ioslaves/http/http.cpp de1a1ddde544229689bd22cd69491a46b8c0dddb Diff: https://git.reviewboard.kde.org/r/117508/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117511: Add class for finding the kde4 config and apps home dirs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117320: Update the kbuildsycoca5 man page
On April 5, 2014, 8:59 p.m., David Faure wrote: docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook, line 39 https://git.reviewboard.kde.org/r/117320/diff/1/?file=262293#file262293line39 Users don't know KService... better talk about the desktop file system configuration cache. (in other news I started work to get rid of kbuildsycoca completely, but that will take a bit longer) Alex Merry wrote: Users also won't be running this unless someone tells them to. And desktop file system configuration cache suggests it's more general than it is. How about KService desktop file system configuation cache? The desktop file part is more useful than the vague system configuration cache, but it still links it to the KService framework for those that know what it is. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/#review55039 --- On April 1, 2014, 11:32 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/ --- (Updated April 1, 2014, 11:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Update the kbuildsycoca5 man page Diffs - docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook dc39386b36c102e8f043b9bd6e9b571c9460ef25 Diff: https://git.reviewboard.kde.org/r/117320/diff/ Testing --- Built and visually inspected the man page. 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 117320: Update the kbuildsycoca5 man page
On April 5, 2014, 8:59 p.m., David Faure wrote: docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook, line 280 https://git.reviewboard.kde.org/r/117320/diff/1/?file=262293#file262293line280 LOL, that was optimistic :) Alex Merry wrote: That was copied verbatim from the old file. I know (hence was) On April 5, 2014, 8:59 p.m., David Faure wrote: docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook, line 39 https://git.reviewboard.kde.org/r/117320/diff/1/?file=262293#file262293line39 Users don't know KService... better talk about the desktop file system configuration cache. (in other news I started work to get rid of kbuildsycoca completely, but that will take a bit longer) Alex Merry wrote: Users also won't be running this unless someone tells them to. And desktop file system configuration cache suggests it's more general than it is. Alex Merry wrote: How about KService desktop file system configuation cache? The desktop file part is more useful than the vague system configuration cache, but it still links it to the KService framework for those that know what it is. Yes, desktop file is useful, we agree on that :) Add KService if you want, let's call that a compromise :) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/#review55039 --- On April 1, 2014, 11:32 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/ --- (Updated April 1, 2014, 11:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Update the kbuildsycoca5 man page Diffs - docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook dc39386b36c102e8f043b9bd6e9b571c9460ef25 Diff: https://git.reviewboard.kde.org/r/117320/diff/ Testing --- Built and visually inspected the man page. 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 117511: Add class for finding the kde4 config and apps home dirs.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 --- I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right? IMHO this would fit best in an explicit porting framework src/lib/util/kdelibs4migration.cpp https://git.reviewboard.kde.org/r/117511/#comment38618 initialize d to nullptr? - Kevin Krammer On April 12, 2014, 11:01 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 12, 2014, 11:01 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117320: Update the kbuildsycoca5 man page
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/#review55505 --- This review has been submitted with commit cec317d944ffb29c7d8c4b866e62a38c2dc7e79c by Alex Merry to branch master. - Commit Hook On April 1, 2014, 11:32 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/ --- (Updated April 1, 2014, 11:32 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Update the kbuildsycoca5 man page Diffs - docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook dc39386b36c102e8f043b9bd6e9b571c9460ef25 Diff: https://git.reviewboard.kde.org/r/117320/diff/ Testing --- Built and visually inspected the man page. 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 117320: Update the kbuildsycoca5 man page
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117320/ --- (Updated April 12, 2014, 11:17 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Update the kbuildsycoca5 man page Diffs - docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook dc39386b36c102e8f043b9bd6e9b571c9460ef25 Diff: https://git.reviewboard.kde.org/r/117320/diff/ Testing --- Built and visually inspected the man page. 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 117511: Add class for finding the kde4 config and apps home dirs.
On April 12, 2014, 11:12 a.m., Kevin Krammer wrote: I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right? IMHO this would fit best in an explicit porting framework I don't want to put this in kdelibs4support because apps are supposed to port away from that and stop linking to it (thus avoiding I link to everything), while they are supposed to keep the migration code for quite some time (not everyone will upgrade to 5.0 right away). I don't think it makes sense to create yet another framework for one class. We are going crazy already with the number of frameworks and the small size of some of them. So this leaves kcoreaddons, unless you have a better suggestion. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 --- On April 12, 2014, 11:01 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/ --- (Updated April 12, 2014, 11:01 a.m.) Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. Repository: kcoreaddons Description --- Add class for finding the kde4 config and apps home dirs. To help applications migrating to the kf5/qt5 directories. Diffs - autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac autotests/kdelibs4migrationtest.cpp PRE-CREATION src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 src/lib/util/kdelibs4migration.h PRE-CREATION src/lib/util/kdelibs4migration.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117511/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
APIDox for Plasma Framework
Hi, I just realized that we're not generating the API documentation for Plasma Framework here [1]. Maybe it would be worth adding? Aleix [1] http://api.kde.org/frameworks-api/frameworks5-apidocs/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: APIDox for Plasma Framework
On 12/04/14 12:48, Aleix Pol wrote: Hi, I just realized that we're not generating the API documentation for Plasma Framework here [1]. Maybe it would be worth adding? I think it currently just grabs everything in /frameworks on project.kde.org. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KPluginLoader move
Just a heads up that I'm planning to move KPluginLoader, KPluginFactory and kexportplugin.h from KService to KCoreAddons this weekend, as previously discussed (it's SC, as it will involve putting KCoreAddons into the link interface of KService). I have an open review request for KPluginLoader in KService, but I'll just discard it and re-open it in KCoreAddons. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Monday 07 April 2014 21:20:19 Ben Cooksley wrote: On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote: Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. I would put it in a separate repo just to make sure distributions do not add plasma-workspace as a dependency of kglobalaccel (which will mean that application developers will run away from the dependency). What about kglobalaccel-runtime ? Frameworks has gone well overkill with the desire to split everything into separated repositories. Such a repository makes no sense. If this is such a problem, then kglobalaccel (the framework) should gain backends for Windows, Mac, Other DE, etc. integration and kglobalacceld is merely the implementation used in a Plasma workspace. But kglobalacceld is probably the correct implementation for gnome, lxqt, xfce, and all others on the X11 platform, isn't it? It's not related to the DE, only to X11. So making it (kglobalacceld, the X11 backend) part of Plasma excludes these other DEs for good. Martin's comment indicates that with wayland the functionality would become part of the DE though but that's another backend. I would make it part of the kglobalaccel framework, and only compiled on X11. The dependencies can certainly be trimmed down, I just removed some unnecessary ones. We're left with KF5::GlobalAccel KF5::I18n KF5::WindowSystem # KKeyServer KF5::DBusAddons # KDBusService KF5::CoreAddons # KAboutData KF5::ConfigCore KF5::Crash where I18n and CoreAddons could be removed too. -- 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
Re: Postfixing .po that come from Qt::tr() with a _qt.po
El Divendres, 11 d'abril de 2014, a les 01:36:12, Aurélien Gâteau va escriure: 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? Seems about right, yes :) Cheers, Albert Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117475: kmimeassociationstest: remove kde4- prefix from desktop file names
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117475/ --- (Updated April 12, 2014, 6:39 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- kmimeassociationstest: remove kde4- prefix from desktop file names The code path this tested no longer exists. Diffs - autotests/kmimeassociationstest.cpp d7b3ac29ca7292c0250286b241f20891c988bab6 Diff: https://git.reviewboard.kde.org/r/117475/diff/ Testing --- Test still passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117330: Update documentation not found docbook
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117330/ --- (Updated April 12, 2014, 6:41 p.m.) Review request for KDE Frameworks, David Faure and Luigi Toscano. Repository: kio Description --- Update documentation not found docbook Diffs - docs/kioslave/help/documentationnotfound/index.docbook 3e576bd302a9b6709d1c102b1aa2c9e60da98898 Diff: https://git.reviewboard.kde.org/r/117330/diff/ Testing --- Builds and installs, although I can't get khelpcenter to display it (tried `khelpcenter help:blah`, but that just displays the string There is no documentation available for /blah.). 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 117330: Update documentation not found docbook
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/#review55538
---
Builds and installs, although I can't get khelpcenter to display it (tried
`khelpcenter help:blah`,
but that just displays the string There is no documentation available for
/blah.).
Of course khelpcenter help:blah will not displays this docbook, because
in frameworks this is installed in ${HTML_INSTALL_DIR}/en SUBDIR
kioslave/help/documentationnotfound
wheras the kio help expects this docbook in
${HTML_INSTALL_DIR}/${CURRENT_LANG}/ SUBDIR khelpcenter/documentationnotfound
like in kde4.
- Burkhard Lück
On April 12, 2014, 6:41 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/
---
(Updated April 12, 2014, 6:41 p.m.)
Review request for KDE Frameworks, David Faure and Luigi Toscano.
Repository: kio
Description
---
Update documentation not found docbook
Diffs
-
docs/kioslave/help/documentationnotfound/index.docbook
3e576bd302a9b6709d1c102b1aa2c9e60da98898
Diff: https://git.reviewboard.kde.org/r/117330/diff/
Testing
---
Builds and installs, although I can't get khelpcenter to display it (tried
`khelpcenter help:blah`, but that just displays the string There is no
documentation available for /blah.).
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 117475: kmimeassociationstest: remove kde4- prefix from desktop file names
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117475/#review55539 --- We might not install such desktop files anymore, but I don't understand the code path this tested no longer exists? Recently clarifications to the desktop entry spec define more precisely what a desktop file id is, and it can look like vendor-filename.desktop if the file is vendor/filename.desktop on disk, so I'd rather we keep making sure this works. - David Faure On April 12, 2014, 6:39 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117475/ --- (Updated April 12, 2014, 6:39 p.m.) Review request for KDE Frameworks and David Faure. Repository: kservice Description --- kmimeassociationstest: remove kde4- prefix from desktop file names The code path this tested no longer exists. Diffs - autotests/kmimeassociationstest.cpp d7b3ac29ca7292c0250286b241f20891c988bab6 Diff: https://git.reviewboard.kde.org/r/117475/diff/ Testing --- Test still passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117330: Update documentation not found docbook
On April 12, 2014, 9:30 p.m., Burkhard Lück wrote:
Builds and installs, although I can't get khelpcenter to display it
(tried `khelpcenter help:blah`,
but that just displays the string There is no documentation available
for /blah.).
Of course khelpcenter help:blah will not displays this docbook, because
in frameworks this is installed in ${HTML_INSTALL_DIR}/en SUBDIR
kioslave/help/documentationnotfound
wheras the kio help expects this docbook in
${HTML_INSTALL_DIR}/${CURRENT_LANG}/ SUBDIR
khelpcenter/documentationnotfound
like in kde4.
The kio help expects it in kioslave/help, kio was patched as well.
It does not work maybe because of the missing common/ directory, which is not
installed right now? (working on it)
Even with that directory I can just see the correct title, but blank pages are
always displayed in my khelpcenter (issues with the khtmlpart maybe, but this
is for other RRs).
Anyway, does kioclient cat help:... works (after you copy the common/ directory
in the right place)?
- Luigi
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/#review55538
---
On April 12, 2014, 8:41 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/
---
(Updated April 12, 2014, 8:41 p.m.)
Review request for KDE Frameworks, David Faure and Luigi Toscano.
Repository: kio
Description
---
Update documentation not found docbook
Diffs
-
docs/kioslave/help/documentationnotfound/index.docbook
3e576bd302a9b6709d1c102b1aa2c9e60da98898
Diff: https://git.reviewboard.kde.org/r/117330/diff/
Testing
---
Builds and installs, although I can't get khelpcenter to display it (tried
`khelpcenter help:blah`, but that just displays the string There is no
documentation available for /blah.).
Thanks,
Alex Merry
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117529: Remove unused GNU entities
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117529/ --- Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- Those entities are never used directly (I didn't found other references); they are used/included throught only the lang/entities/underlicense.docbook snippets. Diffs - src/customization/af/catalog.xml de8a50c src/customization/bg/catalog.xml 1bbab79 src/customization/ca/catalog.xml 9b41c14 src/customization/cs/catalog.xml c5ddc3a src/customization/da/catalog.xml 6358696 src/customization/de/catalog.xml dba1e24 src/customization/el/catalog.xml 6897809 src/customization/en-GB/catalog.xml 18a464e src/customization/en/catalog.xml ccdbd54 src/customization/eo/catalog.xml 91d4352 src/customization/es/catalog.xml d86d3a7 src/customization/et/catalog.xml 7cc53bb src/customization/fi/catalog.xml 2a8ae66 src/customization/fo/catalog.xml 8bc6007 src/customization/fr/catalog.xml 0960717 src/customization/gl/catalog 2f58034 src/customization/gl/catalog.xml 7ca90c3 src/customization/he/catalog.xml 0b1dfa5 src/customization/hu/catalog.xml c987e3d src/customization/id/catalog.xml 005f17c src/customization/it/catalog.xml 25f9c7a src/customization/ja/catalog.xml 5dfb22d src/customization/ko/catalog.xml 04f43b8 src/customization/lt/catalog.xml ba5e6dd src/customization/nds/catalog.xml 854792e src/customization/nl/catalog.xml 59f4631 src/customization/nn/catalog.xml e6d8bbb src/customization/no/catalog.xml 2403083 src/customization/pl/catalog.xml 05bb0b3 src/customization/pt-BR/catalog.xml dd0921e src/customization/pt/catalog.xml da2b40c src/customization/ro/catalog.xml fb8a0e9 src/customization/ru/catalog.xml 1093312 src/customization/sk/catalog.xml 44d13b4 src/customization/sl/catalog.xml 817bc22 src/customization/sq/catalog.xml 72a91de src/customization/sr/catalog.xml 5bc3a37 src/customization/sr@ijekavian/catalog.xml 9f15dac src/customization/sr@ijekavianlatin/catalog.xml ec19392 src/customization/sr@latin/catalog.xml d055287 src/customization/sv/catalog.xml 8808a79 src/customization/th/catalog.xml ccdbd54 src/customization/tr/catalog.xml dcc05b8 src/customization/uk/catalog.xml 7a4cded src/customization/wa/catalog.xml b58efd9 src/customization/xh/catalog.xml 37428a3 src/customization/xx/catalog.xml 15179c6 src/customization/zh-CN/catalog.xml 9f4556a src/customization/zh-TW/catalog.xml bac0327 Diff: https://git.reviewboard.kde.org/r/117529/diff/ Testing --- Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
