[Breeze] [Bug 341155] application-vnd.oasis.opendocument.chart.svg doesn't look like a chart
https://bugs.kde.org/show_bug.cgi?id=341155 --- Comment #1 from Jarosław Staniek stan...@kde.org --- Created attachment 89663 -- https://bugs.kde.org/attachment.cgi?id=89663action=edit Screenshot -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 341155] New: application-vnd.oasis.opendocument.chart.svg doesn't look like a chart
https://bugs.kde.org/show_bug.cgi?id=341155 Bug ID: 341155 Summary: application-vnd.oasis.opendocument.chart.svg doesn't look like a chart Product: Breeze Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-devel@kde.org Reporter: stan...@kde.org mimetypes/file-types/application-vnd.oasis.opendocument.chart.svg and mimetypes/file-types-small/application-vnd.oasis.opendocument.chart.svg do not look like a chart but rather like a sheet. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/ --- Review request for KDE Frameworks, kwin and Plasma. Repository: kwindowsystem Description --- KStartupInfo::createNewStartupId is supposed to return a new id with a properly setup user timestamp. But if QX11Info::appUserTime returns 0 this was included in the id and cannot be considered a properly setup user timestamp. An app user time of 0 is the case for klauncher. If an application uses this timestamp of 0 passed from the startup notification it causes problems with passing focus to it from KWin. The application sets the timestamp in the _NET_WM_USER_TIME property and the value 0 has the special meaning of requesting to not be initially mapped. KWin honors that and doesn't focus the window. An application is not supposed to interpret a 0 time stamp passed through the startup notification as a special value to get the current time. It is totally fine to expect that it gets a proper value passed. Thus one cannot blame applications for not interpreting this value accordingly. An example for an application passing the 0 to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5 session through e.g. the launcher results in KWin not passing focus to it and instead demands attention. This is clearly wrong and not intended. The solution in this change is to get the current timestamp from the X server in case the appUserTime is 0. This fixes the described problem with Firefox: it now gets properly focused on starting through a launcher. Diffs - autotests/kstartupinfo_unittest.cpp f4b607d2a21da7dcf32434c00b2bdeeaf401ee65 src/kstartupinfo.cpp 03418fce1a154ea388d0f65665dc0c9724a5623a Diff: https://git.reviewboard.kde.org/r/121197/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121198: Drop incorrect warnings when using KXMessages without QX11Info
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121198/ --- Review request for KDE Frameworks, kwin and Plasma. Bugs: 340310 https://bugs.kde.org/show_bug.cgi?id=340310 Repository: kwindowsystem Description --- The idea was to not perform the action if QX11Info reports that its not the xcb plugin. But this check is not correct as those methods are not going through QX11Info at all. In addition they pass in either an xcb connection or XLib display which is totally fine and needed for example if we want Wayland applications interact with the X11 world. Also it causes problems for e.g. kdeinit which is not a Q*Application and thus does not have a QX11Info. At the same time fix an incorrect usage of QX11Info::connection where an xcb_connection_t* is already passed in to the method. BUG: 340310 Diffs - src/kxmessages.cpp 2e625d29c4fd4a5056d792f565d53dea5e6529fd Diff: https://git.reviewboard.kde.org/r/121198/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 341082] actions/scalable/show-offline.svgz icon is practically invisible
https://bugs.kde.org/show_bug.cgi?id=341082 David Edmundson k...@davidedmundson.co.uk changed: What|Removed |Added Component|general |Icons Assignee|plasma-devel@kde.org|unassigned-b...@kde.org -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 340147] Folder icon is black on black with Breeze-dark plasma theme
https://bugs.kde.org/show_bug.cgi?id=340147 David Edmundson k...@davidedmundson.co.uk changed: What|Removed |Added Component|general |Icons CC||k...@davidedmundson.co.uk Assignee|plasma-devel@kde.org|unassigned-b...@kde.org -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 341155] application-vnd.oasis.opendocument.chart.svg doesn't look like a chart
https://bugs.kde.org/show_bug.cgi?id=341155 David Edmundson k...@davidedmundson.co.uk changed: What|Removed |Added Component|general |Icons CC||k...@davidedmundson.co.uk Assignee|plasma-devel@kde.org|unassigned-b...@kde.org -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/#review70739 --- src/kstartupinfo.cpp https://git.reviewboard.kde.org/r/121197/#comment49475 Should this not rather be ::getTimestamp() unconditionally? This is supposed to be a hint when the application was triggered, not when there was the last interaction in the calling client. ::appUserTime() might be any random value in the past, thus pollute the FSP heuristics. - Thomas Lübking On Nov. 21, 2014, 10:44 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/ --- (Updated Nov. 21, 2014, 10:44 vorm.) Review request for KDE Frameworks, kwin and Plasma. Repository: kwindowsystem Description --- KStartupInfo::createNewStartupId is supposed to return a new id with a properly setup user timestamp. But if QX11Info::appUserTime returns 0 this was included in the id and cannot be considered a properly setup user timestamp. An app user time of 0 is the case for klauncher. If an application uses this timestamp of 0 passed from the startup notification it causes problems with passing focus to it from KWin. The application sets the timestamp in the _NET_WM_USER_TIME property and the value 0 has the special meaning of requesting to not be initially mapped. KWin honors that and doesn't focus the window. An application is not supposed to interpret a 0 time stamp passed through the startup notification as a special value to get the current time. It is totally fine to expect that it gets a proper value passed. Thus one cannot blame applications for not interpreting this value accordingly. An example for an application passing the 0 to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5 session through e.g. the launcher results in KWin not passing focus to it and instead demands attention. This is clearly wrong and not intended. The solution in this change is to get the current timestamp from the X server in case the appUserTime is 0. This fixes the described problem with Firefox: it now gets properly focused on starting through a launcher. Diffs - autotests/kstartupinfo_unittest.cpp f4b607d2a21da7dcf32434c00b2bdeeaf401ee65 src/kstartupinfo.cpp 03418fce1a154ea388d0f65665dc0c9724a5623a Diff: https://git.reviewboard.kde.org/r/121197/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121198: Drop incorrect warnings when using KXMessages without QX11Info
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121198/#review70740 --- Ship it! Ship It! - Thomas Lübking On Nov. 21, 2014, 11:04 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121198/ --- (Updated Nov. 21, 2014, 11:04 vorm.) Review request for KDE Frameworks, kwin and Plasma. Bugs: 340310 https://bugs.kde.org/show_bug.cgi?id=340310 Repository: kwindowsystem Description --- The idea was to not perform the action if QX11Info reports that its not the xcb plugin. But this check is not correct as those methods are not going through QX11Info at all. In addition they pass in either an xcb connection or XLib display which is totally fine and needed for example if we want Wayland applications interact with the X11 world. Also it causes problems for e.g. kdeinit which is not a Q*Application and thus does not have a QX11Info. At the same time fix an incorrect usage of QX11Info::connection where an xcb_connection_t* is already passed in to the method. BUG: 340310 Diffs - src/kxmessages.cpp 2e625d29c4fd4a5056d792f565d53dea5e6529fd Diff: https://git.reviewboard.kde.org/r/121198/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/ --- Review request for Plasma. Bugs: 340140 https://bugs.kde.org/show_bug.cgi?id=340140 Repository: krunner Description --- One can also uses a decimal point in a calculator. Diffs - autotests/runnercontexttest.cpp ba5f6a1 src/runnercontext.cpp 2d6177d Diff: https://git.reviewboard.kde.org/r/121201/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0
On Nov. 21, 2014, 4:21 nachm., Thomas Lübking wrote: src/kstartupinfo.cpp, line 1010 https://git.reviewboard.kde.org/r/121197/diff/1/?file=329330#file329330line1010 Should this not rather be ::getTimestamp() unconditionally? This is supposed to be a hint when the application was triggered, not when there was the last interaction in the calling client. ::appUserTime() might be any random value in the past, thus pollute the FSP heuristics. you have a point. I thought the current usage assumed that e.g. when Krunner starts an application that it creates the ASN after the event which triggered it. The event contains a timestamp and Qt should(TM) update the app user time accordingly. From reading the code that is currently not the case (I checked in Kickoff), but could easily be changed to be correct and is something I wanted to look into. It would be the correct timestamp in that case and doesn't trigger another roundtrip to X during starting an application. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/#review70739 --- On Nov. 21, 2014, 11:44 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/ --- (Updated Nov. 21, 2014, 11:44 vorm.) Review request for KDE Frameworks, kwin and Plasma. Repository: kwindowsystem Description --- KStartupInfo::createNewStartupId is supposed to return a new id with a properly setup user timestamp. But if QX11Info::appUserTime returns 0 this was included in the id and cannot be considered a properly setup user timestamp. An app user time of 0 is the case for klauncher. If an application uses this timestamp of 0 passed from the startup notification it causes problems with passing focus to it from KWin. The application sets the timestamp in the _NET_WM_USER_TIME property and the value 0 has the special meaning of requesting to not be initially mapped. KWin honors that and doesn't focus the window. An application is not supposed to interpret a 0 time stamp passed through the startup notification as a special value to get the current time. It is totally fine to expect that it gets a proper value passed. Thus one cannot blame applications for not interpreting this value accordingly. An example for an application passing the 0 to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5 session through e.g. the launcher results in KWin not passing focus to it and instead demands attention. This is clearly wrong and not intended. The solution in this change is to get the current timestamp from the X server in case the appUserTime is 0. This fixes the described problem with Firefox: it now gets properly focused on starting through a launcher. Diffs - autotests/kstartupinfo_unittest.cpp f4b607d2a21da7dcf32434c00b2bdeeaf401ee65 src/kstartupinfo.cpp 03418fce1a154ea388d0f65665dc0c9724a5623a Diff: https://git.reviewboard.kde.org/r/121197/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is still unstable: plasma-desktop_stable_qt5 #7
See http://build.kde.org/job/plasma-desktop_stable_qt5/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/#review70752 --- src/runnercontext.cpp https://git.reviewboard.kde.org/r/121201/#comment49483 It should possibly be using the new QUrl::fromUserInput()... http://doc-snapshot.qt-project.org/qt5-5.4/qurl.html#fromUserInput-2 - Aleix Pol Gonzalez On Nov. 21, 2014, 6:10 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/ --- (Updated Nov. 21, 2014, 6:10 p.m.) Review request for Plasma. Bugs: 340140 https://bugs.kde.org/show_bug.cgi?id=340140 Repository: krunner Description --- One can also uses a decimal point in a calculator. Diffs - autotests/runnercontexttest.cpp ba5f6a1 src/runnercontext.cpp 2d6177d Diff: https://git.reviewboard.kde.org/r/121201/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation
On Nov. 22, 2014, 12:24 a.m., Aleix Pol Gonzalez wrote: src/runnercontext.cpp, line 200 https://git.reviewboard.kde.org/r/121201/diff/1/?file=329397#file329397line200 It should possibly be using the new QUrl::fromUserInput()... http://doc-snapshot.qt-project.org/qt5-5.4/qurl.html#fromUserInput-2 Umm it is introduced in Qt 5.4, so question is can krunner depend upon 5.4 being framework? - Bhushan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/#review70752 --- On Nov. 21, 2014, 11:40 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/ --- (Updated Nov. 21, 2014, 11:40 p.m.) Review request for Plasma. Bugs: 340140 https://bugs.kde.org/show_bug.cgi?id=340140 Repository: krunner Description --- One can also uses a decimal point in a calculator. Diffs - autotests/runnercontexttest.cpp ba5f6a1 src/runnercontext.cpp 2d6177d Diff: https://git.reviewboard.kde.org/r/121201/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121198: Drop incorrect warnings when using KXMessages without QX11Info
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121198/ --- (Updated Nov. 22, 2014, 7:18 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kwin and Plasma. Bugs: 340310 https://bugs.kde.org/show_bug.cgi?id=340310 Repository: kwindowsystem Description --- The idea was to not perform the action if QX11Info reports that its not the xcb plugin. But this check is not correct as those methods are not going through QX11Info at all. In addition they pass in either an xcb connection or XLib display which is totally fine and needed for example if we want Wayland applications interact with the X11 world. Also it causes problems for e.g. kdeinit which is not a Q*Application and thus does not have a QX11Info. At the same time fix an incorrect usage of QX11Info::connection where an xcb_connection_t* is already passed in to the method. BUG: 340310 Diffs - src/kxmessages.cpp 2e625d29c4fd4a5056d792f565d53dea5e6529fd Diff: https://git.reviewboard.kde.org/r/121198/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121197: KStartupInfo: use QX11Info::getTimestamp if appUserTime is 0
On Nov. 21, 2014, 4:21 nachm., Thomas Lübking wrote: src/kstartupinfo.cpp, line 1010 https://git.reviewboard.kde.org/r/121197/diff/1/?file=329330#file329330line1010 Should this not rather be ::getTimestamp() unconditionally? This is supposed to be a hint when the application was triggered, not when there was the last interaction in the calling client. ::appUserTime() might be any random value in the past, thus pollute the FSP heuristics. Martin Gräßlin wrote: you have a point. I thought the current usage assumed that e.g. when Krunner starts an application that it creates the ASN after the event which triggered it. The event contains a timestamp and Qt should(TM) update the app user time accordingly. From reading the code that is currently not the case (I checked in Kickoff), but could easily be changed to be correct and is something I wanted to look into. It would be the correct timestamp in that case and doesn't trigger another roundtrip to X during starting an application. additional idea: changing createNewStartupId() to createNewStartupId(quint32 timestamp = 0) It would allow users having the up to date timestamp to pass it in and in all other cases to just use the one from getTimestamp. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/#review70739 --- On Nov. 21, 2014, 11:44 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121197/ --- (Updated Nov. 21, 2014, 11:44 vorm.) Review request for KDE Frameworks, kwin and Plasma. Repository: kwindowsystem Description --- KStartupInfo::createNewStartupId is supposed to return a new id with a properly setup user timestamp. But if QX11Info::appUserTime returns 0 this was included in the id and cannot be considered a properly setup user timestamp. An app user time of 0 is the case for klauncher. If an application uses this timestamp of 0 passed from the startup notification it causes problems with passing focus to it from KWin. The application sets the timestamp in the _NET_WM_USER_TIME property and the value 0 has the special meaning of requesting to not be initially mapped. KWin honors that and doesn't focus the window. An application is not supposed to interpret a 0 time stamp passed through the startup notification as a special value to get the current time. It is totally fine to expect that it gets a proper value passed. Thus one cannot blame applications for not interpreting this value accordingly. An example for an application passing the 0 to the _NET_WM_USER_TIME is Firefox. Starting Firefox in a Plasma 5 session through e.g. the launcher results in KWin not passing focus to it and instead demands attention. This is clearly wrong and not intended. The solution in this change is to get the current timestamp from the X server in case the appUserTime is 0. This fixes the described problem with Firefox: it now gets properly focused on starting through a launcher. Diffs - autotests/kstartupinfo_unittest.cpp f4b607d2a21da7dcf32434c00b2bdeeaf401ee65 src/kstartupinfo.cpp 03418fce1a154ea388d0f65665dc0c9724a5623a Diff: https://git.reviewboard.kde.org/r/121197/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
