Re: Review Request 122793: Fix KUrlNavigator with high DPI pixmaps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122793/ --- (Updated March 9, 2015, 11:32 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- Ported to QStyle::drawItemPixmap rather than fix the existing code to manually center align an icon in a rectangle as it does the same thing for us properly. Diffs - src/filewidgets/kurlnavigatorplacesselector.cpp 45d7f5a src/filewidgets/kurlnavigatortogglebutton.cpp 0c5f421 Diff: https://git.reviewboard.kde.org/r/122793/diff/ Testing --- Ran new test app with QT_DEVICE_PIXEL_RATIO=2 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 122792: Add test app for showing KUrlNavigator
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122792/ --- (Updated March 9, 2015, 11:32 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- Add test app for showing KUrlNavigator Diffs - tests/CMakeLists.txt bf81120 tests/kencodingfiledialogtest_gui.cpp 6463709 Diff: https://git.reviewboard.kde.org/r/122792/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 122779: Make KFileItemDelegate handle non default devicePixelRatio in animations
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122779/ --- (Updated March 9, 2015, 11:32 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- KIO::CachedRendering creates new pixmaps that hold transitional states in animation, these pixmap sizes need to be in device pixels. Diffs - src/widgets/delegateanimationhandler.cpp 16035ca src/widgets/delegateanimationhandler_p.h 292364f src/widgets/kfileitemdelegate.cpp 90bce37 Diff: https://git.reviewboard.kde.org/r/122779/diff/ Testing --- Ran systemsettings with Qt::AA_UseHighDpiPixmaps and QT_DEVICE_PIXEL_RATIO=2 hovering over the main view no longer makes the icon blocky. 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 122576: Introduce KMoreTools
On March 7, 2015, 9:04 a.m., David Faure wrote: KService is basically ksycoca. One day I hope we can move away from that, which means all of kservice could then be deprecated. So it still makes sense to *use* kservice where looking up desktop files is needed (it's our current implementation of that) but KMT itself isn't part of the ksycoca technology, it should be higher up in the stack. One idea would be to put it in KNewStuff. It's the same kind of thing, viewed from far away: offering the user to install more stuff. Regarding the lookup if an application is installed or not. Currently this is done by looking if the desktop file is installed. With respect to [Dolphin (frameworks branch) doesn’t find filelight](https://bugs.kde.org/show_bug.cgi?id=344614) and that you said it is better to move away from ksyscoca, I wonder how stable the detection of desktop files currently is? Is it maybe better to detect if the executable exists which is specified at the desktop file's Exec line? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/#review77147 --- On March 1, 2015, 2:28 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/ --- (Updated March 1, 2015, 2:28 p.m.) Review request for KDE Frameworks, Dominik Haumann and Emmanuel Pescosta. Repository: kservice Description --- Usage examples see https://git.reviewboard.kde.org/r/122352/ and https://git.reviewboard.kde.org/r/122374/ Description see class comments on KMoreTools and https://community.kde.org/Scratchpad/KMoreToolsFramework If KMoreTools is considered useful it needs a home. I placed it in KService for now. Diffs - CMakeLists.txt 34ce792652415100c9a5f877f0516781eb4aec17 src/CMakeLists.txt 35154a597f55313847b8140962c0e2a4cf1c15a2 src/kmoretools/kmoretools.h PRE-CREATION src/kmoretools/kmoretools.cpp PRE-CREATION src/kmoretools/kmoretools_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION tests/CMakeLists.txt cbb5ece6a3265612fa4640426b7025de8f0dc78e tests/kmoretools/1/a.desktop PRE-CREATION tests/kmoretools/1/b.desktop PRE-CREATION tests/kmoretools/1/c.desktop PRE-CREATION tests/kmoretools/2/kate.desktop PRE-CREATION tests/kmoretools/2/kate.png PRE-CREATION tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION tests/kmoretools/kmoretoolstest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122576/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122576: Introduce KMoreTools
On March 7, 2015, 9:04 a.m., David Faure wrote: KService is basically ksycoca. One day I hope we can move away from that, which means all of kservice could then be deprecated. So it still makes sense to *use* kservice where looking up desktop files is needed (it's our current implementation of that) but KMT itself isn't part of the ksycoca technology, it should be higher up in the stack. One idea would be to put it in KNewStuff. It's the same kind of thing, viewed from far away: offering the user to install more stuff. Gregor Mi wrote: Regarding the lookup if an application is installed or not. Currently this is done by looking if the desktop file is installed. With respect to [Dolphin (frameworks branch) doesn’t find filelight](https://bugs.kde.org/show_bug.cgi?id=344614) and that you said it is better to move away from ksyscoca, I wonder how stable the detection of desktop files currently is? Is it maybe better to detect if the executable exists which is specified at the desktop file's Exec line? You misunderstood me. Right now the recommended solution *is* KService and ksycoca. It is supposed to work, and works for many cases. I didn't have time to look into this specific bug report, but unit tests pass and many people run a plasma 2 desktop based on KService and ksycoca. I'm just saying that in the long term I want to be able to replace this technology with something else, but that's just long-term architectural thinking. For now, use it and debug it ;-) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/#review77147 --- On March 1, 2015, 2:28 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/ --- (Updated March 1, 2015, 2:28 p.m.) Review request for KDE Frameworks, Dominik Haumann and Emmanuel Pescosta. Repository: kservice Description --- Usage examples see https://git.reviewboard.kde.org/r/122352/ and https://git.reviewboard.kde.org/r/122374/ Description see class comments on KMoreTools and https://community.kde.org/Scratchpad/KMoreToolsFramework If KMoreTools is considered useful it needs a home. I placed it in KService for now. Diffs - CMakeLists.txt 34ce792652415100c9a5f877f0516781eb4aec17 src/CMakeLists.txt 35154a597f55313847b8140962c0e2a4cf1c15a2 src/kmoretools/kmoretools.h PRE-CREATION src/kmoretools/kmoretools.cpp PRE-CREATION src/kmoretools/kmoretools_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION tests/CMakeLists.txt cbb5ece6a3265612fa4640426b7025de8f0dc78e tests/kmoretools/1/a.desktop PRE-CREATION tests/kmoretools/1/b.desktop PRE-CREATION tests/kmoretools/1/c.desktop PRE-CREATION tests/kmoretools/2/kate.desktop PRE-CREATION tests/kmoretools/2/kate.png PRE-CREATION tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION tests/kmoretools/kmoretoolstest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122576/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122875: Fix KIconEngine::paint to handle different devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. 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 122875: Fix KIconEngine::paint to handle different devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77222 --- Hi, this fixes the pixelation issues in the Kate document list (thought the project plugin tree view is still pixelated, guess need to take a look at the Kate code for that myself ;=) - Christoph Cullmann On March 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated March 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. 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 122875: Fix KIconEngine::paint to handle different devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77223 --- makes no sense to me, you are getting a rect to paint on and painting outside of it. what even warrants that there will be space on the qpainter? should the size increase be done in upper levels? - Albert Astals Cid On mar. 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated mar. 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. 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 122576: Introduce KMoreTools
On March 7, 2015, 9:04 a.m., David Faure wrote: KService is basically ksycoca. One day I hope we can move away from that, which means all of kservice could then be deprecated. So it still makes sense to *use* kservice where looking up desktop files is needed (it's our current implementation of that) but KMT itself isn't part of the ksycoca technology, it should be higher up in the stack. One idea would be to put it in KNewStuff. It's the same kind of thing, viewed from far away: offering the user to install more stuff. Gregor Mi wrote: Regarding the lookup if an application is installed or not. Currently this is done by looking if the desktop file is installed. With respect to [Dolphin (frameworks branch) doesn’t find filelight](https://bugs.kde.org/show_bug.cgi?id=344614) and that you said it is better to move away from ksyscoca, I wonder how stable the detection of desktop files currently is? Is it maybe better to detect if the executable exists which is specified at the desktop file's Exec line? David Faure wrote: You misunderstood me. Right now the recommended solution *is* KService and ksycoca. It is supposed to work, and works for many cases. I didn't have time to look into this specific bug report, but unit tests pass and many people run a plasma 2 desktop based on KService and ksycoca. I'm just saying that in the long term I want to be able to replace this technology with something else, but that's just long-term architectural thinking. For now, use it and debug it ;-) Ok. So there is no way around the debugging part. ;-) - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/#review77147 --- On March 1, 2015, 2:28 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122576/ --- (Updated March 1, 2015, 2:28 p.m.) Review request for KDE Frameworks, Dominik Haumann and Emmanuel Pescosta. Repository: kservice Description --- Usage examples see https://git.reviewboard.kde.org/r/122352/ and https://git.reviewboard.kde.org/r/122374/ Description see class comments on KMoreTools and https://community.kde.org/Scratchpad/KMoreToolsFramework If KMoreTools is considered useful it needs a home. I placed it in KService for now. Diffs - CMakeLists.txt 34ce792652415100c9a5f877f0516781eb4aec17 src/CMakeLists.txt 35154a597f55313847b8140962c0e2a4cf1c15a2 src/kmoretools/kmoretools.h PRE-CREATION src/kmoretools/kmoretools.cpp PRE-CREATION src/kmoretools/kmoretools_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION tests/CMakeLists.txt cbb5ece6a3265612fa4640426b7025de8f0dc78e tests/kmoretools/1/a.desktop PRE-CREATION tests/kmoretools/1/b.desktop PRE-CREATION tests/kmoretools/1/c.desktop PRE-CREATION tests/kmoretools/2/kate.desktop PRE-CREATION tests/kmoretools/2/kate.png PRE-CREATION tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION tests/kmoretools/kmoretoolstest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122576/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122876: Delay notifications a bit on Plasma startup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122876/#review77226 --- Can't we use the same mechanism as when the screen is locked? (We do that, right? show the notifications after going out of lock). Having a timer is kind of hacky... - Aleix Pol Gonzalez On March 9, 2015, 8:03 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122876/ --- (Updated March 9, 2015, 8:03 p.m.) Review request for KDE Frameworks and Eike Hein. Bugs: 344903 https://bugs.kde.org/show_bug.cgi?id=344903 Repository: knotifications Description --- Currently when something is started right after login and spawns a notification, an ugly popup (KPassivePopup fallback) will appear over the splash screen as the org.freedesktop.Notifications service is not ready yet. This patch delays the notifications by max 25 seconds if and only if KDE_FULL_SESSION is set and there's no Plasma (org.kde.plasmashell) running. If the org.freedesktop.Notifications does not appear within those 25 seconds, the notifications will be put on screen using KPassivePopup. Ideally this should also check if ksmserver is in the starting phase, but I haven't found a way to check for that. Suggestions welcome. Diffs - src/notifybypopup.h 416c533 src/notifybypopup.cpp 316ff2b Diff: https://git.reviewboard.kde.org/r/122876/diff/ Testing --- Plasma not running, emitted KNotification, nothing, started Plasma, notifications appeared when Plasma loaded. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122875: Fix KIconEngine::paint to handle different devicePixelRatios
On March 9, 2015, 6:26 p.m., Albert Astals Cid wrote: makes no sense to me, you are getting a rect to paint on and painting outside of it. what even warrants that there will be space on the qpainter? should the size increase be done in upper levels? It's not painting outside it, the first argument is the target area, the pixmap is scaled to fit. Which is actually what's happening before this patch, scaling it upwards making it look blocky with a high QT_DEVICE_PIXEL_RATIO. In this case I'm making sure what I'm painting does match the painter. We know the painter's target is rect user pixels big. Which means in reality it is rect * devicePixelRatio real device pixels big. To draw a clean icon, we need the pixmaps with a matching size in device pixels, not a matching size in user pixels. Normally this does happen in an upper level. QIcon::pixmap() does this resizing, but QIcon::paint which calls this cannot. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77223 --- On March 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated March 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. 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 122875: Fix KIconEngine::paint to handle different devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77228 --- src/kiconengine.cpp https://git.reviewboard.kde.org/r/122875/#comment53034 Please use spaces around binary '*' operator. - Christoph Feck On March 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated March 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122876: Delay notifications a bit on Plasma startup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122876/ --- Review request for KDE Frameworks and Eike Hein. Bugs: 344903 https://bugs.kde.org/show_bug.cgi?id=344903 Repository: knotifications Description --- Currently when something is started right after login and spawns a notification, an ugly popup (KPassivePopup fallback) will appear over the splash screen as the org.freedesktop.Notifications service is not ready yet. This patch delays the notifications by max 25 seconds if and only if KDE_FULL_SESSION is set and there's no Plasma (org.kde.plasmashell) running. If the org.freedesktop.Notifications does not appear within those 25 seconds, the notifications will be put on screen using KPassivePopup. Ideally this should also check if ksmserver is in the starting phase, but I haven't found a way to check for that. Suggestions welcome. Diffs - src/notifybypopup.h 416c533 src/notifybypopup.cpp 316ff2b Diff: https://git.reviewboard.kde.org/r/122876/diff/ Testing --- Plasma not running, emitted KNotification, nothing, started Plasma, notifications appeared when Plasma loaded. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122876: Delay notifications a bit on Plasma startup
On March 9, 2015, 8:32 p.m., Aleix Pol Gonzalez wrote: Can't we use the same mechanism as when the screen is locked? (We do that, right? show the notifications after going out of lock). Having a timer is kind of hacky... I'm not aware of us doing that (and we don't, I've just tested). However, when Plasma starts, the timer is stopped and the queue processed right away. If Plasma will not start, it's the same as DBus timeout... - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122876/#review77226 --- On March 9, 2015, 8:03 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122876/ --- (Updated March 9, 2015, 8:03 p.m.) Review request for KDE Frameworks and Eike Hein. Bugs: 344903 https://bugs.kde.org/show_bug.cgi?id=344903 Repository: knotifications Description --- Currently when something is started right after login and spawns a notification, an ugly popup (KPassivePopup fallback) will appear over the splash screen as the org.freedesktop.Notifications service is not ready yet. This patch delays the notifications by max 25 seconds if and only if KDE_FULL_SESSION is set and there's no Plasma (org.kde.plasmashell) running. If the org.freedesktop.Notifications does not appear within those 25 seconds, the notifications will be put on screen using KPassivePopup. Ideally this should also check if ksmserver is in the starting phase, but I haven't found a way to check for that. Suggestions welcome. Diffs - src/notifybypopup.h 416c533 src/notifybypopup.cpp 316ff2b Diff: https://git.reviewboard.kde.org/r/122876/diff/ Testing --- Plasma not running, emitted KNotification, nothing, started Plasma, notifications appeared when Plasma loaded. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122875: Fix KIconEngine::paint to handle different devicePixelRatios
On mar. 9, 2015, 6:26 p.m., Albert Astals Cid wrote: makes no sense to me, you are getting a rect to paint on and painting outside of it. what even warrants that there will be space on the qpainter? should the size increase be done in upper levels? David Edmundson wrote: It's not painting outside it, the first argument is the target area, the pixmap is scaled to fit. Which is actually what's happening before this patch, scaling it upwards making it look blocky with a high QT_DEVICE_PIXEL_RATIO. In this case I'm making sure what I'm painting does match the painter. We know the painter's target is rect user pixels big. Which means in reality it is rect * devicePixelRatio real device pixels big. To draw a clean icon, we need the pixmaps with a matching size in device pixels, not a matching size in user pixels. Normally this does happen in an upper level. QIcon::pixmap() does this resizing, but QIcon::paint which calls this cannot. Ok, i have no idea about this, so i guess this is a ±0 from my side - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/#review77223 --- On mar. 9, 2015, 5:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122875/ --- (Updated mar. 9, 2015, 5:54 p.m.) Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This now matches the behaviour of QPixmapIconEngine::paint Diffs - src/kiconengine.cpp 6dff533 Diff: https://git.reviewboard.kde.org/r/122875/diff/ Testing --- Opened configure toolbars in konversation with QT_DEVICE_PIXEL_RATIO=2 QStyledItemDelegate calls QIcon::paint which ends up going through this code with our QPA. 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 122864: Added event() version that takes StandardEvent eventId and QString iconName
On mar. 9, 2015, 11:20 a.m., Martin Klapetek wrote: Ship It! Martin Klapetek wrote: Actually wait, StandardEvents should have standard icons, why would you need to change them? They don't have a standard, default icon: you have to specify it and as of now the only way you have for it is with a QPixmap. - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/#review77205 --- On mar. 9, 2015, 6:02 a.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/ --- (Updated mar. 9, 2015, 6:02 a.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: knotifications Description --- This allows to use icon names instead of QPixmaps when using StandardEvents instead of app-defined events. Diffs - src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 src/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 Diff: https://git.reviewboard.kde.org/r/122864/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName
On March 9, 2015, 11:20 a.m., Martin Klapetek wrote: Ship It! Actually wait, StandardEvents should have standard icons, why would you need to change them? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/#review77205 --- On March 9, 2015, 6:02 a.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/ --- (Updated March 9, 2015, 6:02 a.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: knotifications Description --- This allows to use icon names instead of QPixmaps when using StandardEvents instead of app-defined events. Diffs - src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 src/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 Diff: https://git.reviewboard.kde.org/r/122864/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/#review77205 --- Ship it! Ship It! - Martin Klapetek On March 9, 2015, 6:02 a.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/ --- (Updated March 9, 2015, 6:02 a.m.) Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: knotifications Description --- This allows to use icon names instead of QPixmaps when using StandardEvents instead of app-defined events. Diffs - src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 src/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 Diff: https://git.reviewboard.kde.org/r/122864/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
