Re: Review Request 119410: Document KDED dependency.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119410/#review62923 --- Ship it! Yes, KIO needs kded for favicons, cached passwords, proxy handling, cookies, and the one mentionned in the description is about keeping a global list of open windows in kded, iirc for session cookies. - David Faure On July 22, 2014, 3:47 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119410/ --- (Updated July 22, 2014, 3:47 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- It looks like org.kde.kded5 is called via dbus in a few places, for example in src/widgets/jobuidelegate.cpp. If this is the case, it should be documented so we know to ensure it's available. Diffs - metainfo.yaml 102380eca8c77a34f4ab5c687a51952168b34225 Diff: https://git.reviewboard.kde.org/r/119410/diff/ Testing --- 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 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) happens only from this patch? - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119409: framework part of the applet alternatives shooser
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119409/ --- (Updated July 23, 2014, 9:18 a.m.) Review request for KDE Frameworks and Plasma. Changes --- Now exposes a signal in containment, just as the configure action Repository: plasma-framework Description --- this is the little part in plasma-framework for the applet alternatives chooser. works together the branch mart/alternativesConfig of plasma-workspace and plsma-desktop. for how it looks and why, see the vdg forum thread: https://forum.kde.org/viewtopic.php?f=285t=122067p=315919#p315919 still possible problems: * the branch in framework is kinda screwed, too many merges, is probably better to push this diff as a single commit * I'm not sure about using a new desktop file entry X-Plasma-Provides, *maybe* Categories could be enough, but it may produce many false positives as well Diffs (updated) - src/plasma/applet.cpp 0afb4a7 src/plasma/containment.h 968b3e2 src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 src/plasma/private/applet_p.cpp 92b12ac src/scriptengines/qml/plasmoid/containmentinterface.cpp 457f898 Diff: https://git.reviewboard.kde.org/r/119409/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119410: Document KDED dependency.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119410/ --- (Updated July 23, 2014, 9:50 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kio Description --- It looks like org.kde.kded5 is called via dbus in a few places, for example in src/widgets/jobuidelegate.cpp. If this is the case, it should be documented so we know to ensure it's available. Diffs - metainfo.yaml 102380eca8c77a34f4ab5c687a51952168b34225 Diff: https://git.reviewboard.kde.org/r/119410/diff/ Testing --- 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 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing ok, so either kwindowsystem not notifying or a wrong response to the signal - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119409: framework part of the applet alternatives shooser
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119409/ --- (Updated July 23, 2014, 10:31 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- this is the little part in plasma-framework for the applet alternatives chooser. works together the branch mart/alternativesConfig of plasma-workspace and plsma-desktop. for how it looks and why, see the vdg forum thread: https://forum.kde.org/viewtopic.php?f=285t=122067p=315919#p315919 still possible problems: * the branch in framework is kinda screwed, too many merges, is probably better to push this diff as a single commit * I'm not sure about using a new desktop file entry X-Plasma-Provides, *maybe* Categories could be enough, but it may produce many false positives as well Diffs - src/plasma/applet.cpp 0afb4a7 src/plasma/containment.h 968b3e2 src/plasma/data/servicetypes/plasma-applet.desktop b75c3d6 src/plasma/private/applet_p.cpp 92b12ac src/scriptengines/qml/plasmoid/containmentinterface.cpp 457f898 Diff: https://git.reviewboard.kde.org/r/119409/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDELibs4Support fails to install on Windows if DocBookXML4 absent
On Wednesday 23 of July 2014 00:27:18 Nicolás Alvarez wrote: Hello, Currently KDELibs4Support fails to install on Windows. It gives the following error: CMake Error at src/cmake_install.cmake:264 (file): file RELATIVE_PATH must be passed a full path to the file: searched_dir-NOTFOUND Call Stack (most recent call first): cmake_install.cmake:115 (include) The problem is in src/CMakeLists.txt:653. It tries to use DocBookXML4_DTD_DIR unconditionally, even though DocBookXML4 is an optional package so it may not be found (and it is in fact not present in the current Windows setup). DocBook support is not optional; in fact you already have DocBook 4.5, otherwise KDocTools is not going to work. kdelibs4support requires the older DocBook 4.2 stuff. Just fui, there is another potential problem (only for the DTD from kdelibs4support): the full path to docbook stuff is injected in kdex.dtd, which leads to problem if the path contains a space (reported during testing on MacOSX). See: http://lists.kde.org/?l=kde-frameworks-develm=140498199122919w=2 http://lists.kde.org/?l=kde-frameworks-develm=140580707819842w=2 As this is handled by cmake, I wonder if there is a better way for encoding characters which are not valid for URIs using it, apart from specifying a list of characters that needs to be replaced (space - %20 etc). Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing Marco Martin wrote: ok, so either kwindowsystem not notifying or a wrong response to the signal The cause seems to be alphaMask() coming out wrong. I added a frameSvg-alphaMask().save(/tmp/mask.png); and the mask we're using (via .mask()) to send to KWindowSystem is broken and mostly translucent instead of being primarily black. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing Marco Martin wrote: ok, so either kwindowsystem not notifying or a wrong response to the signal David Edmundson wrote: The cause seems to be alphaMask() coming out wrong. I added a frameSvg-alphaMask().save(/tmp/mask.png); and the mask we're using (via .mask()) to send to KWindowSystem is broken and mostly translucent instead of being primarily black. ah, i see the theme doesn't have an element for the mask, for some version so it's using the normal frame as the mask as well, that's a bit less predictable. adding it in the theme, and let's see if it changes anything - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing Marco Martin wrote: ok, so either kwindowsystem not notifying or a wrong response to the signal David Edmundson wrote: The cause seems to be alphaMask() coming out wrong. I added a frameSvg-alphaMask().save(/tmp/mask.png); and the mask we're using (via .mask()) to send to KWindowSystem is broken and mostly translucent instead of being primarily black. Marco Martin wrote: ah, i see the theme doesn't have an element for the mask, for some version so it's using the normal frame as the mask as well, that's a bit less predictable. adding it in the theme, and let's see if it changes anything try it now, i added a dedicated black mask prefix to the dialog elements - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing Marco Martin wrote: ok, so either kwindowsystem not notifying or a wrong response to the signal David Edmundson wrote: The cause seems to be alphaMask() coming out wrong. I added a frameSvg-alphaMask().save(/tmp/mask.png); and the mask we're using (via .mask()) to send to KWindowSystem is broken and mostly translucent instead of being primarily black. Marco Martin wrote: ah, i see the theme doesn't have an element for the mask, for some version so it's using the normal frame as the mask as well, that's a bit less predictable. adding it in the theme, and let's see if it changes anything Marco Martin wrote: try it now, i added a dedicated black mask prefix to the dialog elements well that won't fix the root issue, just breeze. It seems there's a race and it builds the alphamask from the transparent components rather than the new opaque ones. I tried making sure dialog updates after framesvg has processed the textureChanged signal, but that's not quite enough. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
On July 22, 2014, 10:50 p.m., Eike Hein wrote: Two issues: - Existing Dialog instances don't get the corner mask applied correctly when switching from transparent to opague:  - Compiler warning: framesvgitem.cpp:119:10: warning: unused parameter ‘composeOverBorder’ [-Wunused-parameter] void updateTexture(const QSize size, const QString elementId, bool composeOverBorder) Marco Martin wrote: happens only from this patch? David Edmundson wrote: Seems to be reproducible in v5.0 in the following situation: start a scene i.e tests/dialog.qml enable compositing resize to something not in the cache disable compositing Marco Martin wrote: ok, so either kwindowsystem not notifying or a wrong response to the signal David Edmundson wrote: The cause seems to be alphaMask() coming out wrong. I added a frameSvg-alphaMask().save(/tmp/mask.png); and the mask we're using (via .mask()) to send to KWindowSystem is broken and mostly translucent instead of being primarily black. Marco Martin wrote: ah, i see the theme doesn't have an element for the mask, for some version so it's using the normal frame as the mask as well, that's a bit less predictable. adding it in the theme, and let's see if it changes anything Marco Martin wrote: try it now, i added a dedicated black mask prefix to the dialog elements David Edmundson wrote: well that won't fix the root issue, just breeze. It seems there's a race and it builds the alphamask from the transparent components rather than the new opaque ones. I tried making sure dialog updates after framesvg has processed the textureChanged signal, but that's not quite enough. hmm, in theory it should be correct just wether the new mask is taken after the repaintNeeded signal. will indagate on that - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/#review62911 --- On July 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 22, 2014, 2:24 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDELibs4Support fails to install on Windows if DocBookXML4 absent
El miércoles, 23 de julio de 2014, Luigi Toscano luigi.tosc...@tiscali.it escribió: On Wednesday 23 of July 2014 00:27:18 Nicolás Alvarez wrote: Hello, Currently KDELibs4Support fails to install on Windows. It gives the following error: CMake Error at src/cmake_install.cmake:264 (file): file RELATIVE_PATH must be passed a full path to the file: searched_dir-NOTFOUND Call Stack (most recent call first): cmake_install.cmake:115 (include) The problem is in src/CMakeLists.txt:653. It tries to use DocBookXML4_DTD_DIR unconditionally, even though DocBookXML4 is an optional package so it may not be found (and it is in fact not present in the current Windows setup). DocBook support is not optional; in fact you already have DocBook 4.5, otherwise KDocTools is not going to work. kdelibs4support requires the older DocBook 4.2 stuff. I know docbook4.5 is required for kdoctools. I meant docbook4.2 seems to be optional for kdelibs4support. If it's not intended to be optional, it should be marked as REQUIRED in CMake. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119406: Always take the painter based path for composeOverBorder
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119406/ --- (Updated July 23, 2014, 1:53 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Always take the painter based path for composeOverBorder We previously only supported compose-over-border when the centre was not set to tile. A recent change to the breeze theme put everything into tiling, even if some things used compose-over-border, which broke opaque widgets. Given that creating an opacityMask loads most of the image anyway, we can make use of the FrameSVG painter path and avoid any additional code complexity here. Diffs - src/declarativeimports/core/framesvgitem.cpp a5fe315 Diff: https://git.reviewboard.kde.org/r/119406/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119377: Add highlighting commands
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/ --- (Updated Juli 23, 2014, 5:08 nachm.) Review request for KDE Frameworks and Christoph Cullmann. Changes --- Rename the new files to “katehighlightingcmds”. Repository: ktexteditor Description --- Add the commands 'reload-highlighting' and 'edit-highlighting' to the developer console. This is a KF5 port of a review request I posted some weeks ago (https://git.reviewboard.kde.org/r/118616/). The highlighting definition for the highlighting currently in use gets opened when entering the command 'edit-highlighting', and the complete set of highlighting definition gets reloaded on entering 'reload-highlighting' (takes a second or two on my machine). I thought about a simple caching mechanism based on the mtime of the highlighting definitions, too, but it seems they only get loaded in KateSyntaxDocument::setIdentifier where there is no access to the respective KateHighlighting instance. Caching would require some kind of rewriting that code, then. If you think it’s worth it I could give it a try. Diffs (updated) - src/CMakeLists.txt 2ec52b25dddacdbedf16b908c36fd71f11a889ae src/syntax/katehighlight.h 5c34fb0c3747e72137484fa369a0804f87fb4c43 src/syntax/katehighlight.cpp 05b787cc9c16b2fa6c8ac82c7e809bb0ab8f5835 src/syntax/katehighlightingcmds.h PRE-CREATION src/syntax/katehighlightingcmds.cpp PRE-CREATION src/syntax/katesyntaxmanager.h 568154154149e7c649ec2c023c7e43d44ad07ea4 src/syntax/katesyntaxmanager.cpp ebc86f3835c5bf41e01ed9d0bf7f1f2bde65ca46 src/utils/kateglobal.cpp 5a1cc220e8800a0e4e9203432ea5ba5f72921c21 Diff: https://git.reviewboard.kde.org/r/119377/diff/ Testing --- Using the two new commands on my development machine yields the desired results. Thanks, Christoph Rüßler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119377: Add highlighting commands
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/#review62977 --- Ship it! Ship It! - Christoph Cullmann On July 23, 2014, 3:08 p.m., Christoph Rüßler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119377/ --- (Updated July 23, 2014, 3:08 p.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add the commands 'reload-highlighting' and 'edit-highlighting' to the developer console. This is a KF5 port of a review request I posted some weeks ago (https://git.reviewboard.kde.org/r/118616/). The highlighting definition for the highlighting currently in use gets opened when entering the command 'edit-highlighting', and the complete set of highlighting definition gets reloaded on entering 'reload-highlighting' (takes a second or two on my machine). I thought about a simple caching mechanism based on the mtime of the highlighting definitions, too, but it seems they only get loaded in KateSyntaxDocument::setIdentifier where there is no access to the respective KateHighlighting instance. Caching would require some kind of rewriting that code, then. If you think it’s worth it I could give it a try. Diffs - src/CMakeLists.txt 2ec52b25dddacdbedf16b908c36fd71f11a889ae src/syntax/katehighlight.h 5c34fb0c3747e72137484fa369a0804f87fb4c43 src/syntax/katehighlight.cpp 05b787cc9c16b2fa6c8ac82c7e809bb0ab8f5835 src/syntax/katehighlightingcmds.h PRE-CREATION src/syntax/katehighlightingcmds.cpp PRE-CREATION src/syntax/katesyntaxmanager.h 568154154149e7c649ec2c023c7e43d44ad07ea4 src/syntax/katesyntaxmanager.cpp ebc86f3835c5bf41e01ed9d0bf7f1f2bde65ca46 src/utils/kateglobal.cpp 5a1cc220e8800a0e4e9203432ea5ba5f72921c21 Diff: https://git.reviewboard.kde.org/r/119377/diff/ Testing --- Using the two new commands on my development machine yields the desired results. Thanks, Christoph Rüßler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119435: Replacing also kaction.h header include
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119435/
---
Review request for KDE Frameworks.
Repository: kde-dev-scripts
Description
---
Replacing also kaction.h header include
Diffs
-
kf5/convert-kaction.pl 0fa3f10cddd7f690edf5454a81bc5113d67abdcb
Diff: https://git.reviewboard.kde.org/r/119435/diff/
Testing
---
Sample commit using this script:
diff --git a/filters/exporter.h b/filters/exporter.h
index d5f14f1..8ef83d1 100644
--- a/filters/exporter.h
+++ b/filters/exporter.h
@@ -18,7 +18,7 @@
#ifndef KIG_FILTERS_EXPORTER_H
#define KIG_FILTERS_EXPORTER_H
-#include kaction.h
+#include QAction
#include vector
@@ -41,7 +41,7 @@ public:
};
class ExporterAction
- : public KAction
+ : public QAction
{
Q_OBJECT
Thanks,
David Narváez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Porting: Installing Icons
Hi, The information at [0] seems to indicate I just need to worry about renaming files to match the new categories (btw, is there a script for that?) but what I get from CMake Warning (dev) at /usr/share/ECM/modules/ECMInstallIcons.cmake:205 (message): ecm_install_icons() with no ICONS argument is deprecated Call Stack (most recent call first): icons/CMakeLists.txt:2 (ecm_install_icons) This warning is for project developers. Use -Wno-dev to suppress it. is that I need to update to # ecm_install_icons(ICONS icon [icon [...]] # DESTINATION icon_install_dir # [LANG l10n_code] # [THEME theme]) which seems to me like I need to explicitly list all icons in the dir, and # The given icons, whose names must match the pattern:: # # size-group-name.ext seems to indicate I need to rename all of the files to remove the theme from the prefix. Am I correct? Should I update the wiki with the complete oddyssey to a correct ecm_install_icions? David E. Narvaez [0] https://community.kde.org/Frameworks/Porting_Notes#Installing_Icons ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Porting: Installing Icons
On Wed, Jul 23, 2014 at 06:08:42PM -0400, David Narvaez wrote: This warning is for project developers. Use -Wno-dev to suppress it. is that I need to update to which seems to me like I need to explicitly list all icons in the dir, and Yes you are advised to use the new install function as it says # The given icons, whose names must match the pattern:: # # size-group-name.ext seems to indicate I need to rename all of the files to remove the theme from the prefix. Keep the theme name, preferably use hicolor for icons that are app specific. Am I correct? Should I update the wiki with the complete oddyssey to a correct ecm_install_icions? Maybe list it at https://techbase.kde.org/Development/ECM_SourceIncompatChanges Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Porting: Installing Icons
On Wed, Jul 23, 2014 at 6:20 PM, Jonathan Riddell j...@jriddell.org wrote: # The given icons, whose names must match the pattern:: # # size-group-name.ext seems to indicate I need to rename all of the files to remove the theme from the prefix. Keep the theme name, preferably use hicolor for icons that are app specific. According to the documentation, that now goes to the THEME option? Am I correct? Should I update the wiki with the complete oddyssey to a correct ecm_install_icions? Maybe list it at https://techbase.kde.org/Development/ECM_SourceIncompatChanges Will do. David E. Narvaez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Porting: Installing Icons
On Wed, Jul 23, 2014 at 06:23:32PM -0400, David Narvaez wrote: On Wed, Jul 23, 2014 at 6:20 PM, Jonathan Riddell j...@jriddell.org wrote: # The given icons, whose names must match the pattern:: # # size-group-name.ext seems to indicate I need to rename all of the files to remove the theme from the prefix. Keep the theme name, preferably use hicolor for icons that are app specific. According to the documentation, that now goes to the THEME option? Well spotted, I missed that. Sure update the wiki docs. Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119444: Replacing also kicon.h header include
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119444/
---
Review request for KDE Frameworks.
Repository: kde-dev-scripts
Description
---
Replacing also kicon.h header include
Diffs
-
kf5/convert-kicon.pl bb4b76945f4c75c342f12401fc80a4cadbef03dd
Diff: https://git.reviewboard.kde.org/r/119444/diff/
Testing
---
Sample diff with this script
diff --git a/filters/exporter.cc b/filters/exporter.cc
index 2cbecc6..8218d3f 100644
--- a/filters/exporter.cc
+++ b/filters/exporter.cc
@@ -35,7 +35,7 @@
#include kactionmenu.h
#include kactioncollection.h
-#include kicon.h
+#include QIcon
#include kimageio.h
#include klocale.h
#include kmessagebox.h
@@ -48,7 +48,7 @@ ExporterAction::ExporterAction( const KigPart* doc,
KigWidget* w,
{
QString iconstr = exp-menuIcon();
if ( !iconstr.isEmpty() )
-setIcon( KIcon( iconstr, const_castKigPart*( doc )-iconLoader() ) );
+setIcon( QIcon::fromTheme( iconstr, const_castKigPart*( doc
)-iconLoader() ) );
connect( this, SIGNAL( triggered() ), this, SLOT( slotActivated() ) );
if(parent)
parent-addAction(action, this );
@@ -156,7 +156,7 @@ void KigExportManager::addMenuAction( const KigPart* doc,
KigWidget* w,
KActionCollection* coll )
{
KActionMenu* m = new KActionMenu( i18n( Export To ), w );
- m-setIcon( KIcon( document-export, const_castKigPart*( doc
)-iconLoader() ) );
+ m-setIcon( QIcon::fromTheme( document-export, const_castKigPart*( doc
)-iconLoader() ) );
for ( uint i = 0; i mexporters.size(); ++i )
m-addAction( new ExporterAction( doc, w, coll, mexporters[i] ) );
if(coll)
Thanks,
David Narváez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119446: Add a simple test for meinproc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119446/ --- Review request for Documentation, KDE Frameworks and kdelibs. Repository: kdelibs Description --- The summary says it all. Simple meinproc call with the example template. I propose this change for KDE/4.14 too, and it will be forward-ported to KDocTools/KF5. Diffs - kdoctools/CMakeLists.txt 4dc6d8a kdoctools/tests/CMakeLists.txt PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119446/diff/ Testing --- Compilation of kdelibs and few modules with documentation. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119447: meinproc: check both result of parsing and validation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119447/ --- Review request for Documentation, KDE Frameworks and kdelibs. Repository: kdelibs Description --- For some historical reasons, both results were not checked. On one side, a parsing error could lead to a failure in one of the subsequent call (doc is NULL), but a validation error could pass unnoticed if not by checking the logs (hint: it happened recently with a libxml2 regression). I propose this change for KDE/4.14 too, and it will be forward-ported to KDocTools/KF5. Diffs - kdoctools/xslt.cpp 4d64de4 Diff: https://git.reviewboard.kde.org/r/119447/diff/ Testing --- Compilation of kdelibs and few modules with documentation. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119447: meinproc: check both result of parsing and validation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119447/#review63024 --- +1, makes sense to me, I don't see a drawback to further checking :) - Aleix Pol Gonzalez On July 24, 2014, 12:10 a.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119447/ --- (Updated July 24, 2014, 12:10 a.m.) Review request for Documentation, KDE Frameworks and kdelibs. Repository: kdelibs Description --- For some historical reasons, both results were not checked. On one side, a parsing error could lead to a failure in one of the subsequent call (doc is NULL), but a validation error could pass unnoticed if not by checking the logs (hint: it happened recently with a libxml2 regression). I propose this change for KDE/4.14 too, and it will be forward-ported to KDocTools/KF5. Diffs - kdoctools/xslt.cpp 4d64de4 Diff: https://git.reviewboard.kde.org/r/119447/diff/ Testing --- Compilation of kdelibs and few modules with documentation. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
