> 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
