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/ --- (Updated Nov. 24, 2014, 9:09 a.m.) Review request for KDE Frameworks, kwin and Plasma. Changes --- added bug Bugs: 337798 https://bugs.kde.org/show_bug.cgi?id=337798 Repository: kwindowsystem Description (updated) --- 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 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 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
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
